I read this, and then got lost in the rest of his blog. A very fine description of security protocols and their designs. Seems like the most fun conversations to have. Highly recommend.<p>In section 4 (sign message) at the end:<p>> Using the hash of their encryption key as their signing key is convenient, since it removes the need for Alice and Bob to perform another key-exchange dance. It also provides a subtle contribution towards deniability that we will discuss later.<p>This stuck out for me, as without additional diversification (CMAC, or KDF that just creates another key mgmt problem), it seems moot to use the HMAC of a shared key for signing messages, as if you know the protocol, you know what you have to compromise the shared secret to generate that, and without additional entropy, it seems like a complication without a net increase in security. I may have misread, but I'd wonder if it was superfluous.<p>Edit: thought it through, it's elegant because it's being used as a slightly diversified signature, not that I'm at a level to critique their work, but appears my pen lept from its scabbard.
I may have missed something here, but the write-up seems to be missing the main problem with OTR, which is that both parties need to be online at the same time to do the key-exchange to set up the session - at least in OTRv3 (<a href="https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html" rel="nofollow">https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html</a>)<p>This is why the Double Ratchet Algorithm was created (back in 2013!) where you prepublish a pool of one-time-keys which can be used to establish sessions without you having to be online - as well as defining how to ratchet the message keys forwards both by new DH exchanges and simple hash ratchets (hence the name Double Ratchet).<p>OTRv3 has the sole advantage that you can trivially tunnel it over any existing synchronous transport (e.g. an IRC DM), given it doesn't have the concept of setting up sessions asynchronously. However, this is a bit of a moot point these days, given modern messaging systems like Matrix, XMPP and Signal natively support the Double Ratchet via Olm, OMEMO & libsignalprotocol respectively - so OTRv3 really is a bit of a historical curiosity at this point.<p>Meanwhile OTRv4 does introduce the idea of offline conversation initialisation (<a href="https://github.com/otrv4/otrv4/blob/master/otrv4.md#offline-conversation-initialization" rel="nofollow">https://github.com/otrv4/otrv4/blob/master/otrv4.md#offline-...</a>), but it doesn't seem to have got much traction, relative to the fairly ubiquitous Double Ratchet. (Has anyone seen it in the wild? It looks like coy.im might speak it? <a href="https://github.com/otrv4" rel="nofollow">https://github.com/otrv4</a> seems fairly dead :/)<p>Finally, lots of E2EE research is going into efficient shared ratchets for group communication rather than 1:1 sessions - such as MLS (<a href="https://datatracker.ietf.org/wg/mls/about/" rel="nofollow">https://datatracker.ietf.org/wg/mls/about/</a>), DMLS (<a href="https://matrix.uhoreg.ca/mls/decentralised.html" rel="nofollow">https://matrix.uhoreg.ca/mls/decentralised.html</a>) and DCGKA (<a href="https://www.cylab.cmu.edu/news/2021/11/23-group-messaging.html" rel="nofollow">https://www.cylab.cmu.edu/news/2021/11/23-group-messaging.ht...</a>).
That’s a blast from the past for me!<p>Some years ago, in 2014 or so, at a small startup I was in, we tried to make all communication encrypted. So we had as an official communication channel just Jabber and OTR. (Note, it was before Slack existed.) We did not have official client, everyone could use their own one.<p>It was a nightmare. No 2 clients were really compatible, and the various failure states were not properly implemented, so we routinely could not read each other messages and felt back to plaintext and “I cannot read what you said? please reply back here”<p>This was so bad that we then switched to just PGP mails (which had its own drawbacks, but at least worked).<p>I am not there anymore, I think they switched to just using Slack now. But they could Signal.
OMEMO is an alternative encryption extension for XMPP. <a href="https://en.wikipedia.org/wiki/OMEMO?wprov=sfti1" rel="nofollow">https://en.wikipedia.org/wiki/OMEMO?wprov=sfti1</a>
I was reading this and I realized that under the stated conditions (two parties who trust each other during conversation; later on attacker gets full access), there is a more practical solution: SSL-secured chat with no logging.<p>It is not as neat cryptographically-wise, and it does not work with offline message exchange, but I think that for a lot of common cases, it has the same guarantees (confidentiality, authenticity, deniability, forward secrecy)<p>Or am I missing something?
I'm confused about what the benefit of a malleable cipher is if you still have a HMAC. Is it just for Alice or Bob to be able to say "that's our ciphertext but not our symmetric key"? But in that case the HMAC would also need to be forged, right? If Eve publishes the ciphertext and the legitimate plaintext and the legitimate key, wouldn't Alice and Bob have to say "that's a forged HMAC" with a malleable cipher versus "all of that is forged" with a non-malleable cipher? How is the former more deniable?<p>Unless the point is that Eve isn't trying to expose the messages so much as be certain they are produced by Alice and Bob? But in that case, how would Eve have gotten a fourth party's forgery in the first place?
I note that there is an OTRv4 in progress:<p><a href="https://bugs.otr.im/otrv4/otrv4" rel="nofollow">https://bugs.otr.im/otrv4/otrv4</a>
Question for anyone who knows. What is the method by which the old signing keys are published? I've done a few google searches and haven't found any pages of used signing keys for Signal. I know that the fact that if someone can decrypt the message then they could have created and signed the message leads to the deniability, but they were very specific about publishing the signing keys.