[OTR-dev] question regarding the AKE protocol
ian at cypherpunks.ca
Sun Jun 20 18:16:09 EDT 2010
On Fri, Jun 18, 2010 at 08:01:52PM +0200, Stefan Schoenleitner wrote:
> after reading the SIGMA and OTR papers I was wondering why 4 instead of
> only two MAC keys are needed for the protocol.
> In the protocol description in the third step, Bob derives the MAC
> keys m1 and m2 (among other keys not being relevant for my question).
> The MAC key m2 is used in an usual way to authenticate the encrypted packet.
> However, the key m1 is used to create a MAC over the ephemeral DH public
> keys (g^x, g^y), the longterm public key and the keyid.
> By looking at the libotr code, it can be seen that HMAC-SHA256 is used
> for the MAC.
> After that this MAC is signed with Bob's long term private key.
> Another look at the code reveals that for signing DSA with SHA256 is used.
> Thus, over the existing MAC hash (HMAC-SHA256) another hash (SHA256) is
> calculated in the process of signing.
> * Why is this form of "double hashing" necessary ?
> * Is it just because two keys (m1 and the private sign key) is better
> than just one (private sign key) ?
> * Why is this data (g^x, g^y, the longterm public key and the keyid) not
> just signed traditionally and the additional MAC can be omitted ?
The answer to all three questions lies in the SIGMA protocol. In SIGMA,
the important thing is that you *SIG*n something fresh (including a nonce
or the ephemeral DH keys or something), and *MA*C your own name. The
MAC proves to the other party that you actually were able to compute the
shared secret s, and by including that in the signature, you prove it's
really you. Otherwise, there are all sorts of subtle attacks.
There's not actually "double hashing" going on, though. The spec says:
This is the signature, using the private part of the key pubB, of
the 32-byte MB (which does not need to be hashed again to produce
Now, it turns out that's annoying, since a number of crypto libraries
will *automatically* hash your input for you, and you have to do all
sorts of nonsense to get it to skip the hash. So it may change in some
future version to actually double hashing, just for convenience.
More information about the OTR-dev