3 ms·

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 t

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.

bigiain 5y ago
> 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.
- motohagiography 5y ago
  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.
  - bigiain 5y ago
    > 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.)
- frumiousirc 5y ago
  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).

bigiain 5y ago

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

motohagiography 5y ago
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.
- bigiain 5y ago
  > 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.)
frumiousirc 5y ago
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).