Nice try FBI.
Wouldn’t “NSA” or “CIA” be more appropriate here?
Well, if my pin is four numbers, that’ll make it so hard to crack. /s
If you’re using a 4 number PIN then that’s on you. The blog post I shared covers that explicitly: “However, there’s a limit to how slow things can get without affecting legitimate client performance, and some user-chosen passwords may be so weak that no feasible amount of “key-stretching” will prevent brute force attacks” and later, “However, it would allow an attacker with access to the service to run an “offline” brute force attack. Users with a BIP39 passphrase (as above) would be safe against such a brute force, but even with an expensive KDF like Argon2, users who prefer a more memorable passphrase might not be, depending on the amount of money the attacker wants to spend on the attack.”
If you can’t show hard evidence that everything is offline locally, no keys stored in the cloud, then it’s just not secure.
If you can’t share a reputable source backing up that claim, along with a definition of what “secure” means, then your claim that “it’s just not secure” isn’t worth the bits taken to store the text in your comment.
You haven’t even specified your threat model.
BTW, “keys” when talking about encryption is the keys used to encrypt and decrypt,
Are you being earnest here? First, even if we were just talking about encryption, the question of what’s being encrypted is relevant. Secondly, we weren’t just talking about encryption. Here’s your complete comment, for reference:
I have read that it is self hostable (but I haven’t digged into it) but as it’s not a federating service so not better than other alternative out there.
Also read that the keys are stored locally but also somehow stored in the cloud (??), which makes it all completely worthless if it is true.
That said, the three letter agencies can probably get in any android/apple phones if they want to, like I’m not forgetting the oh so convenient “bug” heartbleed…
Just so you know, “keys” are used for a number of purposes in Signal (and for software applications in general) and not all of those purposes involve encryption. Many keys are used for verification/authentication.
Assuming you were being earnest: I recommend that you take some courses on encryption and cybersecurity, because you have some clear misconceptions. Specifically, I recommend that you start with Cryptography I (by Stanford, hosted on Coursera. See also Stanford’s page for the course, which contains a link to the free textbook). Its follow-up, Crypto II, isn’t available on Coursera, but I believe that this 8 hour long Youtube video contains several of the lectures from it. Alternatively, Berkeley’s Zero Knowledge Proofs course would be a good follow-up, and basically everything (excepting the quizzes) appears to be freely available online.
it wouldn’t be very interesting to encrypt them, because now you have another set of keys you have to deal with.
The link I shared with you has 6 keys (stretched_key, auth_key, c1, c2, master_key, and application_key) in a single code block. By encrypting the master key (used to derive application keys such as the one that encrypts social graph information) with a user-derived, stretched key, Signal can offer an optional feature: the ability to recover that encrypted information if their device is lost, stolen, wiped, etc., though of course message history is out of scope.
Full disk encryption also uses multiple keys in a similar way. Take LUKS, for example. Your drive is encrypted with a master key. You derive the master key by decrypting one of the access keys using its corresponding pass phrase. (Source: section 4.3 in the LUKS1 On-Disk Format Specification (I don’t believe this basic behavior was changed in LUKS2).)
If a communication norm is just about other people’s preferences, why should they change? Who’s to say that other people’s preferences are more important than their own, particularly given that this particular preference is shared by millions of other people.
If inconsistent use of capitalization actually hinders understanding for some subset of their audience, then that’s a different story. My experience is that people are more likely to be annoyed than to actually have issues understanding all lowercase text. All caps text, on the other hand, is a different matter - and plenty of government and corporate entities are fine putting important text in all caps. But all caps text is a known accessibility issue. When I search for “all lowercase accessibility,” though, all I get is a bunch of results saying to not use all caps text for accessibility reasons.
If you have sources showing that all lowercase text is an accessibility concern, then you should share them. Heck, you should have led with that. But as it is, your argument ultimately boils down to “someone else should change what they do, that works for them, because it annoys me.”