[OTR-dev] OTR, keyservers, MITM, etc.

chris-tuchs at hushmail.com chris-tuchs at hushmail.com
Mon Aug 10 20:52:43 EDT 2009


Naturally after posting I see ways to improve the protocol.  I
want to limit the DOS problem to only those who know Alice and
Bob are trying to use OTR on protocol P.  So I change the
definition to

<N, E, M, R>

Where N is HASH1(user1-name | protocol | user2-name); E is an
encryption of HASH2(key1-fingerprint | key2-fingerprint) under a
key determined by HASH3(user-name1 | protocol | user-name2); M
is a HMAC of E using key determined by HASH4(user-name1 |
protocol | user-name2) and a hashing function HASH5; R is a
nonce as before.  HASH1, HASH2, HASH3, HASH4, and HASH5 are
hashing functions derived from a suitable function such as
SHA256.

This allows Alice, Bob, and the hypothetical MITM to test if a
post has a valid HMAC for E and that E is the encryption of the
hash of the key fingerprints.  Since no information about the
HMAC key is revealed in N, eavesdroppers who can only see traffic
to the keyservers are unlikely to be able to generate well
formed posts in a timely enough manner to deny service to Alice
and Bob.

A little bit more concrete design details:

HASHT(x)  = High 180 bits of SHA256(x)
HASHK(x)  = High 128 bits of SHA256(x)
HASH1(x)  = HASHT("User names" | x | "HASH1")
HASH2(x)  = HASHT("Fingerprints" | x | "HASH2")
HASH3(x)  = HASHK("Encryption key" | x | "HASH3")
HASH4(x)  = HASHK("HMAC key" | x | "HASH4")
HASH5(x)  = SHA256(x)
HMAC(k,x) = High 180 bits of HMAC-SHA256(k,x)
E(k,x) = AES in counter mode with 128 bit key K, initial count 0
R = a 24 bit number

The keyservers are http servers which respond to urls like
http://host.tld/otrkey?v1&N=<b64>&E=<b64>&M=<b64>&R=<b64>

with lines like
N=<b64>&E=<b64>&M=<b64>&R=<b64>
N=<b64>&E=<b64>&M=<b64>&R=<b64>
N=<b64>&E=<b64>&M=<b64>&R=<b64>

Where <b64> is a URL safe variant of a base 64 encoded number.
And it's the reason I picked 168 bits and 24 bits above since
they are evenly divisible by 24, which is the base 64
"blocksize", and thus eliminates the need for any padding
algorithm.

Chris

Postscript: Please tell me someone has already done this better,
let me use their protocol.





More information about the OTR-dev mailing list