[elvisloops]

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.

[SAI_Peregrinus]

The static symmetric key is fundamentally different from an ephemeral asymmetric key. We've no indication that symmetric encryption is vulnerable to "store now, decrypt later" attacks when used with a sufficiently long key, which Signal has. Non-post-quantum asymmertic cryptography is vulnerable to "store now, decrypt later" attacks, which is why forward secrecy is needed.

The backups feature doesn't open up any new vulnerability that didn't inherently exist in sending messages to someone else you might not fully trust. One person in a group chat can also take pictures of their phone's screen & upload your messages to the public.

[tptacek]

I think they're making a point that is broader than PQ and a more general complaint about Signal's direction.

[cma]

Images can be modified, won't these essentially be signed as verifiably coming from the sender, or is cryptographic proof of that thrown away in what they store?

[jt2190]

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]

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.

[Spooky23]

I think you’re right.

But practically, it probably has more risk as people bypassing employer or legal controls think it’s “secure”. So they have conversations that they wouldn’t have.

[heavyset_go]

It's a technological one when the feature is offered to laymen for their convenience.

[abdullahkhalids]

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]

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.

[varenc]

You also have no way of knowing when someone you're chatting with screenshots your messages and uploads them to Imgur.

I jest, and Signal's support for backups do really increase exposure to this risk, but just trying to say its a matter of degree not a fundamentally new change. People that have been using sigtop[0] to backup their Signal messages to plaintext also create the same exposure risk.

[0] https://github.com/tbvdm/sigtop

[ragona]

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]

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.