[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.

[immibis]

These things can still be used as evidence. The process used by the police of a rogue country (or any other adversary) isn't a cryptographer's highly technical wet dream or nightmare. They simply look at the screen of your phone saying you sent or received a message, and as far as the adversary is concerned, that proves you sent or received it. Even if you didn't. (Actually, they use Cellebrite and just trust whatever the Cellebrite analyzer outputs, which is basically what your screen would have said)

I've yet to see a protocol that lets you convincingly insert fake messages into both sides of your own chat history, especially in a way that isn't detectable by say, sqlite rowid order, but that would be an interesting idea for where to take this sort of thing.

[jfyi]

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.

[C4K3]

At the very least they should have excluded any chats with disappearing messages enabled from being included in backups.

With disappearing messages off it was already reasonable to assume that a compromise of a counterparty's phone would result in exposure of all previous messages, so enabling backups wouldn't expose you to new risk.

That would cater to those who want to keep their chat history forever without exposing those with disappearing messages enabled to new risk.

[elvisloops]

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.

[jfyi]

I think you missed the point entirely. You can't have security without thinking about it. You can have vague sense of security, which is the theater you are talking about.

Show me a company anywhere that can provide security without user thought and deliberate action. It's a fantasy to believe anything you don't have to think about isn't theater. Hell, if you aren't thinking about it, you're one of the actors in that theater.

[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.

[jonathanstrange]

AFAIK, it has the same security as before. Perfect forward secrecy means that if someone starts recording encrypted messages in transit and two years later obtains an encryption key, they cannot use that key to decrypt the messages they recorded earlier (because of re-keying).

On the other hand, if an adversary captures one of the group participants' phone and breaks device security, and the chat was recorded on that device, then they can access all recorded chats. By the same token, no cryptography can protect against a malicious group participant who records messages.

In the same scenario, cloud backups seem to merely imply that the same adversary can obtain the cloud backup key and therefore decipher the cloud backups if they get their hands on it. They won't need that, however, since the group chat history is already stored on the device. If no chats were recorded on the device at all the situation would be different.

[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.

[Ajedi32]

Disappearing messages were never a real thing in the first place. You can have a gentleman's agreement that the person you send your message to will delete it after reading it, there's no way to guarantee anything beyond that.

(Fair point though that probably "disappearing" messages shouldn't be included in backups since that obviously prevents them from being deleted. Idk if Signal implements that or not.)

[tptacek]

Disappearing messages are an opsec feature for trusted counterparties, not a cryptographic feature. They are very much a real thing.

[ragona]

> encrypts it with a static key

What type of static key? If it's just a big symmetric key that isn't derived from an asymmetric handshake of some type then no, that's not our current understanding of the PQ threat model.

[tptacek]

Part of the premise of FS/PCS is that "shit happens" to compromise keys even if the underlying cryptography is strong, so if you want a coherent end-to-end FS/PCS story, the claim would be that you need to be ratcheting everywhere.

[ragona]

Definitely, but when we're running around sprinkling PQ algorithms all over the place, it's on top of the asymmetric bits, not replacing the "boring" stuff like your symmetrically encrypted backups. Shit certainly does happen, especially where key management is involved, but I'm not sure I agree that offering an encrypted backup feature is necessarily undoing the FS/PCS story.

edit: Well, let me argue with myself for a moment. I don't think offering an encrypted backup feature undoes the PQ story. But FS/PCS is weakened, sure, since we're talking about all types of shit happening, not just currently known (or strongly theorized) attacks.

[tptacek]

I think they point they're making doesn't have much to do with PQ.