Readit News logoReadit News
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
abdullahkhalids · 3 months ago
The security problem that a messaging app like Signal solves is NOT: Allow a person to secure their communication against eavesdroppers.

It solves the problem: How can a group of people (two or more people) securely communicate with each other.

The group has to mutually decide their risk profile, and then decide which features of the application to use. And each person in the group has to decide whether they can trust others in the group to follow the agreed upon opsec. Signal cannot solve these social problems.

elvisloops · 3 months ago
Historically as long as everything remained "in the app," it was secure. It's an easy assumption to make and communicate to others. Now it's more complicated: there are things that people can unwittingly do "in the app" that make it less secure.
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
jfyi · 3 months ago
Those are the breaks though when catering to a large audience with wildly differing threat models. Do you throw away users that are looking for a vague sense of security so they run off somewhere else less secure because you lack some feature?

If you are just looking for "secure(TM)[X]", you are making a mistake somewhere anyway.

If your life or livelihood depends on it, you learn what the impact of every choice is and you painstakingly keep to your opsec.

Somewhere between the two user action becomes a necessity. You need to judge where that point is for you and take responsibility for it because nobody else can guarantee it.

elvisloops · 3 months ago
The history of Signal has been to provide the security properties we're talking about without users having to think about it or understand. To suddenly remove forward secrecy is a very big change, and it isn't one that they seem to have acknowledged or documented. Like this blog post: they are making an announcement that they have a "post-quantum ratchet," when they have effectively removed the ratchet. It's theater.
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
tptacek · 3 months ago
I think they point they're making doesn't have much to do with PQ.
elvisloops · 3 months ago
Yes, if Signal has effectively removed ratcheting and forward secrecy from the logical "encryption protocol" by encrypting all messages (even disappearing messages) with a single static key that never changes for your lifetime and sending them to the cloud, then all this talk about "post-quantum ratchets" is theater. There are no ratchets.
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
uv-depression · 3 months ago
Do you also think it's "strange" that they're introducing that (optional!) feature while also storing all the messages on your device? The cloud backup is strictly more secure than that on-device database. Their blog post on the subject also explicitly says it won't include disappearing messages that disappear within 24 hours.
elvisloops · 3 months ago
It's not optional because you don't know whether the people you are communicating with have it enabled. One person in a group chat with the feature enabled undoes the forward secrecy for everyone in the group chat.

A cloud backup eliminates any forward secrecy. It used to be that in Signal, when you have a message on your device and it is deleted (or a disappearing message disappears), then it is truly gone and can never be recovered. Now with backups, since the key that was used to encrypt it to the cloud remains on your device, it can be recovered even after the message is deleted or disappears.

The only way to "truly" opt-out is to, as you say, set a disappearing message timer for <24 hours.

elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
ragona · 3 months ago
I don't think that's quite right. PQ attacks focus on the "trapdoor" functions in asymmetric cryptography, _not_ the symmetric encryption that happens after key negotiation. The current concern is that a future attacker could unwrap the symmetric key, not directly attack the symmetric encryption that is used for something like backups.

(Note: I didn't actually dig into the backup implementation, but my guess is that it's more of a KDF -> symmetric design, rather than the sorts of asymmetric negotiation you'd find in multi-party messaging.)

elvisloops · 3 months ago
If the app takes your disappearing message, encrypts it with a static key that never changes and is never deleted, and uploads it to the cloud, then the message is never truly "disappearing." A "post compromise" event will allow the attacker to decrypt that ciphertext at any point in the future. All of this ratcheting is undone by backups.
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
jt2190 · 3 months ago
This is no different than if recipient of the secure message shares the message in plaintext. The problem is a discipline problem not a technology one, and the solution is the same in both cases.
elvisloops · 3 months ago
There's a difference between what Signal does in the app and a manual action a user performs outside of the app. It is not realistic to expect that people will see a feature Signal has built for them in the app and understand the underlying implications to "post compromise security" and "forward secrecy" that it may have.

The expectation is that what happens inside Signal is secure, and the features Signal provides are secure. If the idea is that nobody is going to enable this feature, then why build it? If the idea is that many people are going to enable this feature, then this entire cryptographic protocol is meaningless.

elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
uv-depression · 3 months ago
That backup system presumably uses symmetric encryption, which is not nearly as vulnerable to quantum-accelerated attacks.
elvisloops · 3 months ago
Yes, but you don't need a complicated ratcheting protocol if you've eliminated forward secrecy in other ways. This post is about "post compromise security," but there is already no post-compromise security after the cloud backups feature
elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
tptacek · 3 months ago
Sure.

In the standard practical analysis of quantum threats to cryptography, your adversary is "harvesting and then decrypting". Everybody agrees that no adversary can perform quantum cryptography today, but we agree (to agree) that they'll plausibly be able to at some point in the future. If you assume Signal is carrying messages that have to be kept secret many years into the future, you have to assume your adversary is just stockpiling Signal ciphertexts in a warehouse somewhere waiting so that 15 or 20 years from now they can decrypt them.

That's why you want PQ key agreement today: to protect against a future capability targeting a record of the past. (It's also why you don't care as much about PQ signatures, because we agree no adversary can time travel back and MITM, say, a TLS signature verification).

To understand the importance of a PQ ratchet, add one more capability to the adversary. In addition to holding on to ciphertexts for 15-20 years, assume they will eventually compromise a device, or find an implementation-specific flaw in cryptography code that they can exploit to extract key material. This is a very realistic threat model; in fact, it's of much more practical importance than the collapse of an entire cryptographic primitive.

You defend against that threat model with "forward secrecy" and "post-compromise security". You continually update your key, so the compromise of any one key doesn't allow an attacker to retrospectively decrypt, or to encrypt future messages.

For those defenses to hold against a "harvest and decrypt" attacker, the "ratchet" mechanism you use to keep re-keying your session also needs to be PQ secure. If it isn't, attackers will target the ratchet instead of the messages, and your system will lose its forward and post-compromise secrecy.

elvisloops · 3 months ago
I think this used to be true. Now one problem is that a Signal message goes through this whole forward secrecy protocol, but the receiving device has some probability of uploading it to the cloud with a static key that never changes.

You don't have to enable the Signal backups feature, but you have no way of knowing whether the recipient of your messages has. One person in a group chat with that enabled will undo all of the forward secrecy you're describing.

elvisloops commented on Signal Protocol and Post-Quantum Ratchets   signal.org/blog/spqr/... · Posted by u/pluto_modadic
elvisloops · 3 months ago
Strange that they are posting about the "signal ratchet" when they just removed it by launching cloud backups that use a static key? Since those cloud backups include disappearing messages, that feature completely undoes all of the forward secrecy in this protocol.
elvisloops commented on Signal Secure Backups   signal.org/blog/introduci... · Posted by u/keyboardJones
codethief · 3 months ago
Hi @greysonp

> Once you’ve enabled secure backups, your device will automatically create a fresh secure backup archive every day, replacing the previous day’s archive.

So IIUC backups will not be incremental and I will have to re-upload my 15 GB backup archive every day? Why is that? What's the security risk here? (Obviously I'm not suggesting encrypting & uploading each message & media file individually but splitting things up into same-sized chunks, like e.g. borgbackup does.)

> At the core of secure backups is a 64-character recovery key that is generated on your device. This key is yours and yours alone; it is never shared with Signal’s servers. This key is different from your Signal PIN, which serves different purposes.

Both recovery key and Signal PIN seem to serve the exact same purpose, though, namely restoring data (conversations, contacts, account, …)? Why not unify them?

elvisloops · 3 months ago
Giving people a 64-character key also feels uncharacteristically crude for Signal. It's not realistic to hand people 64 characters and tell them to “store this securely.” Most people will screenshot it, and those screenshots will end up in unencrypted cloud backups.

That's less of a problem when the backups are local, because access to the local backups implies access to the device, but if the backups are in the cloud with no forward secrecy, this seems like a huge security backslide for Signal.

u/elvisloops

KarmaCake day20May 22, 2013
About
carnivore
View Original