[OTR-dev] Simplifying deniability

Paul Wouters paul at cypherpunks.ca
Wed Jul 31 04:37:02 EDT 2013


On Tue, 30 Jul 2013, Trevor Perrin wrote:

[Note that I'm not a cryptographer, just a protocol implementer...]

>> No. It simply means Alice got an automated reply from Bob's machine.
>
> With what Moxie specified, a full transcript doesn't even mean that much.

I don't understand this. Either Alice gets some kind of answer from Bob
or his machine, or not. I don't see how the protocol implementation
matters for this.

>> Bob could be 6000km away without internet connectivity. This is very
>> different from giving a "digital signature" that requires Bob to use
>> a passphrase or pin to create it (eg PGP)
>
> But it's also different from an implicitly authenticated, all-DH key
> agreement.  Such a key agreement does not create 3rd-party verifiable
> digital signatures *at all*.  Thus full transcripts can be forged more
> easily, without interacting with Bob.

Again, I am not a cryptographer, but I wouldn't say "make easier" is a
very compelling reason to change the crypto (neither is "DSA is hard",
one should be using standard and verified crypto libraries)

>>> I'm not sure what publishing MAC keys adds.
>>
>> Repudiation. While I'm not sure there is legal value in that, it does
>> provide it. If the NSA says "this proves Alice said X", you can say
>> "The NSA could have create that message themselves, it is not proof
>> without reasonable doubt".
>
> When the NSA says "this", what is the "this"?  If they are pointing to
> a full transcript from one party to a conversation that shows all
> plaintext / ciphertext / secrets, then they will have the MAC keys
> regardless of whether they were published.
>
> Could you elaborate on your scenario, and explain how publication of
> MAC keys helps?

As I said, I think there is low value in revealing the MAC. It will mostly
depend on the judge. The difference is subtle. It's the difference between
"the police had access to the house and could have planted drugs in the
suspect's house" and "we don't know how the drugs ended up in the house,
but the police could have planted it if they used a locksmith to plant
drugs there". Neither argument will be very convincing on its own,
police tends to not do these things and it is still more likely the
suspect actually placed the drugs in their own house. But if the police
behaviour is under investigation, then this difference might lead to
a more reasonable doubt of the ease of which the police could have
done things.

When someone sniffs all traffic, they basically have the keys to easilly
create forgeries with the libotr command line tools available to
everyone. If the mac keys were not leaked, it needs more then just a
network sniffer - one needs access to one of the two end point machines.

While Peter and I are specifying the OTR protocol as an IETF draft, it
is pretty important that _cryptographers_ (not protocol designers) look
at this new tripple DiffieHellman variant, and whether it does indeed
have a significant advantage. Aside from the previously mentioned
reasons ("DSA is hard" and something with MAC forgability that is still
not clear to me) the other argument was message size. With fragmentation
supported in OTR, and only the SMS network being stuck to such small 140
character limit, I find this argument not very appealing either.
(especially with SMS usage sharply decreasing in both usage and price)

Paul



More information about the OTR-dev mailing list