Live data from Hacker News

Off-the-Record Messaging

robertheaton.com

1–10 of 39 posts

Re: Off-the-Record Messaging

#2
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)

Or am I missing something?

Re: Off-the-Record Messaging

#3
post #2

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, authenti…

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

Re: Off-the-Record Messaging

#4
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.

Re: Off-the-Record Messaging

#5
post #2

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, authenti…

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.

Re: Off-the-Record Messaging

#6
post #2

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, authenti…

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

Re: Off-the-Record Messaging

#8
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?

Post reply on HN