Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Off-the-Record Messaging

robertheaton.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Off-the-Record Messaging

#31

Post by upofadown »

digianarchist wrote: post #21

OMEMO is an alternative encryption extension for XMPP. https://en.wikipedia.org/wiki/OMEMO?wprov=sfti1

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.

The ideas:

* Forward secrecy for messaging.

* Deniability through forgeablility.

Re: Off-the-Record Messaging

#32

Post by upofadown »

Arathorn wrote: post #28

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 establ…

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.

Re: Off-the-Record Messaging

#33

Post by jeroenhd »

shp0ngle wrote: post #30
seniorivn wrote: post #25

Earlier quoted context omitted.

there is more reliable open source decentralized alternative to jabber matrix.org

Didn’t matrix add e2e just recently?

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.

Re: Off-the-Record Messaging

#34

Post by Arathorn »

shp0ngle wrote: post #30
seniorivn wrote: post #25

Earlier quoted context omitted.

there is more reliable open source decentralized alternative to jabber matrix.org

Didn’t matrix add e2e just recently?

we added e2ee in beta in nov 2016 (https://matrix.org/blog/2016/11/21/matrixs-olm-end-to-end-en...) and exited beta and enabled it by default in may 2020: https://matrix.org/blog/2020/05/06/cross-signing-and-end-to-...

Re: Off-the-Record Messaging

#35

Post by upofadown »

elrac1 wrote: post #24

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.

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.

Re: Off-the-Record Messaging

#36

Post by motohagiography »

bigiain wrote: post #23
motohagiography wrote: post #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 contribu…

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

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.

Re: Off-the-Record Messaging

#37

Post by Lt_Riza_Hawkeye »

theamk wrote: 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…

You'll really only get authenticity if you've exchanged certificates in some offline manner first, and eschew the whole CA infrastructure

Re: Off-the-Record Messaging

#38

Post by frumiousirc »

bigiain wrote: post #23
motohagiography wrote: post #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 contribu…

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

Re: Off-the-Record Messaging

#39

Post by bigiain »

motohagiography wrote: post #36
bigiain wrote: post #23

Earlier quoted context omitted.

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

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

Post reply on HN