3 ms·

FUD. There are several critical flaws in your analysis (disclaimer: I'm an enthusiast, not a cryptographer). > The ratchet protocol that that approach relies

FUD. There are several critical flaws in your analysis (disclaimer: I'm an enthusiast, not a cryptographer). > The ratchet protocol that that approach relies on requires both ends to be online at the same time. This is simply untrue, and in fact the very point of the ratchet is to support asynchronous messaging. The next ratchet's key material is sent alongside a message encrypted with the previous ratchet-derived shared key. > since the server has to be involved in allowing offline messages to work Sure, for some definition of "involved". But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted. If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers! [0]: https://signal.org/docs/specifications/doubleratchet https://signal.org/docs/specifications/doubleratchet

lmm 7y ago
> This is simply untrue, and in fact the very point of the ratchet is to support asynchronous messaging. The next ratchet's key material is sent alongside a message encrypted with the previous ratchet-derived shared key. Not true; the point of the ratchet was to allow "off the record" conversations where you would have forward secrecy, and also where the receiver would not have cryptographic proof of what you said after the conversation was ended. All of the nice security properties rely on you continuing to exchange messages regularly; it breaks down if one side sends too many messages without receiving a response from the other side, and as long as that time window is open there's a risk. In practice there's a complicated risk tradeoff around exactly how much async-ness is acceptable (both in terms of time and in terms of number of messages without a response), but any implementation will have a point at which it reverts to following protocol for sending the first message to a currently-offline user. > But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted. Maybe. It's not clear under what circumstances the server could trick the clients into treating it as a first interaction with this user, at which point the server is involved in the key exchange process - something that signal security analyses tend to brush under the carpet. > If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers! This is kind of a double standard though. Good practice for using PGP is to use regularly-rotated subkeys and destroy them once they're out of use, at which point you don't have a forward secrecy problem. Real-world PGP users mostly don't do this, but real-world Signal users mostly don't check security numbers either. (In contrast, real-world PGP users do check key fingerprints, in my experience, because the software defaults and the web of trust system nudge them in the right direction).

lmm 7y ago

> This is simply untrue, and in fact the very point of the ratchet is to support asynchronous messaging. The next ratchet's key material is sent alongside a message encrypted with the previous ratchet-derived shared key. Not true; the point of the ratchet was to allow "off the record" conversations where you would have forward secrecy, and also where the receiver would not have cryptographic proof of what you said after the conversation was ended. All of the nice security properties rely on you continuing to exchange messages regularly; it breaks down if one side sends too many messages without receiving a response from the other side, and as long as that time window is open there's a risk. In practice there's a complicated risk tradeoff around exactly how much async-ness is acceptable (both in terms of time and in terms of number of messages without a response), but any implementation will have a point at which it reverts to following protocol for sending the first message to a currently-offline user. > But the relay server in the Signal protocol absolutely does not need to be trusted for offline messages to work, they are end-to-end encrypted. Maybe. It's not clear under what circumstances the server could trick the clients into treating it as a first interaction with this user, at which point the server is involved in the key exchange process - something that signal security analyses tend to brush under the carpet. > If you don't bother to verify the security number, then you need to trust the identity server, but that's out of scope for the protocol. Verify your security numbers! This is kind of a double standard though. Good practice for using PGP is to use regularly-rotated subkeys and destroy them once they're out of use, at which point you don't have a forward secrecy problem. Real-world PGP users mostly don't do this, but real-world Signal users mostly don't check security numbers either. (In contrast, real-world PGP users do check key fingerprints, in my experience, because the software defaults and the web of trust system nudge them in the right direction).