[OTR-dev] Achieving non-non-repudiation in another protocol.

Gregory Maxwell gmaxwell at gmail.com
Tue Aug 26 22:39:57 EDT 2008


Hopefully the this brief non-libotr discussion is not too far off-topic.

I'm getting close to releasing a real-time low latency audio
conferencing tool (suitable for real-time music collaboration and the
like).

The system provides automatic, transparent, and always on encryption
since I believe that I'm ethically obligated to include that as an
author of a protocol that will be used across the internet. Due to the
application requirements existing crypto layers like OTR do not suit
my needs.

It would be desirable if the anti-MITM functionality of my application
did not also introduce non-repudiation, which is undesirable for this
application.  So I'd like the essential non-non-repudiation behavior
of OTR.  I think I've achieved that, but I'd like a quick sanity
check.

Some of the features of OTR, such as the ability to make validly
decoding blind forgeries are not realistic in my application because
of the use of compression (Nor are blind bitflips all that useful
against audio in any case), so I'm performing my non-non-repudiation
in a manner fairly different from libotr.

I won't be providing a complete and accurate description of the
cryptographic protocol here, since I'm only trying to verify that what
I'm doing will achieve non-non-repudiation.

Definitions:
DHp1  = Client 1's ephemeral EC Diffie-Hellman public key
DHp2  = Client 2's ephemeral EC Diffie-Hellman public key
M1      = Random value generated by client 1 for message auth
M2      = Random value generated by client 2 for message auth
N1       = Random value generated by client 1 as a nonce
N2       = Random value generated by client 2 as a nonce
S1()     = Signing with Client1's private key.
S2()     = Signing with Client2's private key.
H()       = some cryptographic hash function

Client 1 sends   DHp1 || N1 || MAC(M1,DHp1) ->  Client 2
then
Client 2 sends  DHp2 || N2 || MAC(M2,DHp2) -> Client 1
then
Client 1 sends M1 || S1(H(M1||N2)) -> Client 2
then
Client 2 sends M2 || S2(H(M2||N1)) -> Client 1

With reasonable assumptions that M1, M2, N1, N2 are large and randomly
selected:

Client 1 and 2 can now verify that the DH public values are
authenticated by M1 and M2. And that M1 and M2 were authenticated by
the public keys so no MITM is possible. Replay isn't possible against
client 1 or client 2 because the signatures depend on a nonce
controlled by the other client.

After the final exchange either client (or any eavesdropper) could
create a new stream are re-use the Mn and Nn values from this exchange
to make a forged stream that appears to be signed by Client1, Client2,
or both.

Does this appear correct?



More information about the OTR-dev mailing list