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.
In section 4 (sign message) at the end:
> 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.
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.
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.
> it seems moot to use the HMAC of a shared key for signing messages
It’s because you want to be able to publish that signing key later, so you can deny anything signed with it came from you since anybody could use it to sign anything.
Also, though perhaps with minor practical benefit, during the period when the signing key is still secret it is used to assure the message is as-intended. This strong assurance is needed since a malleable encryption is used (to later enhance deniability).
Appreciated, though I think I may have been nerd sniped as it's the kind of thread that begs to be pulled.:)
I'm interpreting the HMAC is supposed to be proof you are in posession of the shared secret, and anyone else with that shared secret can verify the signature.
In this message/signnature denial case, you are only one of many people who could be in posession of the HMAC signing key in some post-hoc disclosure of this (symmetric) signing key that obfuscates the identity of the original party.
This means, a) the recipient doesn't know whether the signature is from their counterparty because that HMAC signing secret is only loosely/deniably secret, and b) without a counter (another low entropy shared secret or a ratchet), there is no way of knowing whether the signed message you recieve is the "first," one derived from your shared secret.
This is just HN comments and I haven't done a deep dive on the protocol, but I'd wonder if the anonymity (in isolation) isn't as cryptographically strong as the message encryption. I'm pretty sure OTR got a lot of scrutiny, but even in some commercial protocols with a lot of scrutiny, I've seen some agreement to not emphasize certain trade offs in their final specificaitons.
This is assuming that being able to show a traffic analysis and prove non-deniability of the parties and messages would be a break of OTR. I'm sure it's the best we have, it's just when your threat model is the attention of an adversary with bulk interception capabilities, using a protocol that lights up like a tracer round on the network, and then while message secrecy is sufficient, when you are protecting recipient identities from said adversary, you are effectively depending on the anonymity provided by a kind of stateless, high-traffic dead drop.
Not disagreeing about the use of this HMAC, but the cryptographic integrity of the anonymity guarantee of the protocol is super interesting to think about. It suggests OTR may be a solution to what is effectively direct anonymous attestation, which if it is, amazing, but if it isn't, the conversation about its limits would be a fun beers thing.
> This means, a) the recipient doesn't know whether the signature is from their counterparty because that HMAC signing secret is only loosely/deniably secret, and b) without a counter (another low entropy shared secret or a ratchet), there is no way of knowing whether the signed message you recieve is the "first," one derived from your shared secret.
The HMAC signing key is not publicised until _after_ the recipient first/immediately verifies the signature. (This is practical for chat applications like OTR and Signal, but it would leave a much much wider window open if you tried to implement it for a much lies synchronous communication channel like email.)
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 (https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html)
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).
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.
Meanwhile OTRv4 does introduce the idea of offline conversation initialisation (https://github.com/otrv4/otrv4/blob/master/otrv4.md#offline-...), 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? https://github.com/otrv4 seems fairly dead :/)
Off the record was specifically intended to be just that: an online discussion with no evidence of what was said or even that it took place. Forcing both parties to be online at the same time is consistent with that. When the discussion is over then it is done and gone.
The protocol used by Signal Messenger adds on the pre-key stuff as sort of a bag on the side to enable asynchronous messaging. It's basically a place to dump a bunch of keys that will later be forgotten as part of a forward secrecy scheme. So stuff sticks around until the recipient goes online and sees the messages. Then the keys are forgotten. At some point the client has to dump in some more keys to keep up the stock.
Also, as I understand it OTRv4 intentionally does not target multi-device scenarios so it seems unlikely to gain any wider adoption for the kind of use cases XMPP and Matrix target, where being able to see your chats on other devices is considered a feature and not a security issue.
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.
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”
This was so bad that we then switched to just PGP mails (which had its own drawbacks, but at least worked).
I am not there anymore, I think they switched to just using Slack now. But they could Signal.
I'm not sure on the exact timeline, but E2EE has been mentioned in references to the protocol going back as far as 2015.
However, because of a lack of cross-signing support, it was disabled by default for a long time. The protocol and UX improvements to allow multi-client multi-receiver end-to-end-encrypted messages came in about a year or two ago, which precluded the need for every user to verify every device of every other user they're talking to. The default flow is to verify each of your devices yourself, and others verify against your key only once. However, it's technically not required to cross-sign your keys, so it's perfectly possible to force others to verify each device of yours if you want to enforce some extra security. Not very practical, though.
So: protocol wise, encryption has been in there for a while, but client support and ease of use were major constraints. Modern cross-signing support (and uptake of encrypted messages by alternative clients) have helped a lot in actual adoption of the encryption abilities the protocol already had.
And while OTR always caused more problems and frustrations than it solved, OMEMO just works for me — even in a multi-sevice setup. After OMEMO became available in the XMPP clients that I use, I never looked back to OTR.
OMEMO is based on ideas from the protocol used by Signal Messenger. Signal Messenger is based on ideas from OTR. Learning about OTR is the easiest way to understand the basic concepts behind the others because everyone just refers to the OTR writeup either explicitly or implicitly . So this new writeup is still potentially valuable.
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.
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)
The majority of SSL implementations do not support perfect forward secrecy in any form. The bare SSL standard itself has no room for it. You need at least TLS 1.3 to get any shot at PFS -- and then again most SSL standards allow for negotiation of at least slightly older protocols.
Plain SSL is also broken by NAT transversal. There's a chat protocol that does do something very similar to what you're asking: Ricochet Refresh. Ricochet Refresh spawns a Tor hidden service and provides an API via it and no text logging. Tor's transit mechanism always has confidentiality, authenticity, deniability, and perfect forward secrecy. https://www.ricochetrefresh.net/
Unfortunately there are no mobile clients for this.
OTR is designed to make proving authenticity of someone intercepting the message impossible: holding the message transcript means you hold all the data necessary to fake the whole thing - no one can go "look these are all signed by X's key which proves they sent them".
I don't think it's deniable. The server has an identity key (which resides in its certificate) that it uses to sign its response to the client Hello message. Though I guess if you make certificates short-lived and published the privkeys it might be close to OTR
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?
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?
The signing key gets published right after the recipient verifies the message with it. Also, the signing key is derived from the encryption key, so you always know the former if you know the latter.
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.
Signal (since TextSecure v2) doesn't have to publish any signing key, because it uses a variant of OTR where messages are even more forgeable - you can forge complete transcripts with another person even when you haven't messaged them at all.
I think that in the Signal case, anyone can generate forged messages in some sense. OTR pretty much only allowed your correspondent to do that.
I personally don't think it matters as I consider deniability though a false claim of a forgery pretty much bogus to start with. I would actually prefer that messages from me could not be forged by anyone. I don't feel the need to have off the record discussions and chances are will never have that need.
In section 4 (sign message) at the end:
> 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.
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.
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.