6 ms·

On the properties page, what does he mean by deniability? > The recipient of a Noise box can authenticate the sender, but cannot produce digitally-signed evide

On the properties page, what does he mean by deniability? > The recipient of a Noise box can authenticate the sender, but cannot produce digitally-signed evidence binding the sender to anything. This seems contradictory -- how can a recipient prove that the expected sender was the one who sent the box, without having binding evidence?

pfortuny 12y ago
Think of DH key agreement, for example (although this is not precise). Once the agreement has been reached you might "verify" the sender by asking him the key (if he knows it, he is the sender) but you cannot create any binding "signed" certification that he is the sender (knowing a secret you already know is not a signature, you might have faked the communication).
twic 12y ago
The way this is done in the OTR protocol and friends is that the information is signed, and the recipient is given enough information to verify the signature, but also to forge the signature. Given that the recipient knows that they did not forge the signature, they can infer that the signature is legitimate. Given that a third party, to whom we fear the recipient might reveal the message, cannot know that the recipient did not forge the signature, they cannot infer that the signature is legitimate. It's possible that i have misunderstood the OTR protocol, or Mr Perrin's claim about Noise boxes. As a result, please do not infer that the above explanation is definitely correct!
- timmclean 12y ago
  Thanks, this makes sense.
- makomk 12y ago
  This appears to be essentially how Noise works too. The sender creates a shared MAC key using ECDH in a way that allows the receiver to obtain it and confirm it came from the genuine sender (assuming the proposed protocol works as intended). That shared MAC key is then used to authenticate the ciphertext. Since only the sender and receipient can obtain that key, the receipient can verify the message is signed so long as they know their private key isn't compromised, but they can't prove it to anyone else because they have all the information needed to fake a valid message of their choice.

pfortuny 12y ago

Think of DH key agreement, for example (although this is not precise). Once the agreement has been reached you might "verify" the sender by asking him the key (if he knows it, he is the sender) but you cannot create any binding "signed" certification that he is the sender (knowing a secret you already know is not a signature, you might have faked the communication).

twic 12y ago

The way this is done in the OTR protocol and friends is that the information is signed, and the recipient is given enough information to verify the signature, but also to forge the signature. Given that the recipient knows that they did not forge the signature, they can infer that the signature is legitimate. Given that a third party, to whom we fear the recipient might reveal the message, cannot know that the recipient did not forge the signature, they cannot infer that the signature is legitimate. It's possible that i have misunderstood the OTR protocol, or Mr Perrin's claim about Noise boxes. As a result, please do not infer that the above explanation is definitely correct!

timmclean 12y ago
Thanks, this makes sense.
makomk 12y ago
This appears to be essentially how Noise works too. The sender creates a shared MAC key using ECDH in a way that allows the receiver to obtain it and confirm it came from the genuine sender (assuming the proposed protocol works as intended). That shared MAC key is then used to authenticate the ciphertext. Since only the sender and receipient can obtain that key, the receipient can verify the message is signed so long as they know their private key isn't compromised, but they can't prove it to anyone else because they have all the information needed to fake a valid message of their choice.