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)
Or am I missing something?
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.
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’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.
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 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 :/)
Finally, lots of E2EE research is going into efficient shared ratchets for group communication rather than 1:1 sessions - such as MLS (https://datatracker.ietf.org/wg/mls/about/), DMLS (https://matrix.uhoreg.ca/mls/decentralised.html) and DCGKA (https://www.cylab.cmu.edu/news/2021/11/23-group-messaging.ht...).
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.
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.
The ideas:
* Forward secrecy for messaging.
* Deniability through forgeablility.
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.
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?
