[OTR-dev] purpose of hash commitment in OTR authenticated key exchange

Stefan Schönleitner dev.c0debabe at gmail.com
Thu Mar 17 05:58:09 EDT 2011


Hi,

On Wed, Mar 16, 2011 at 10:29 PM, Ian Goldberg <ian at cypherpunks.ca> wrote:

>
> You've got it exactly right.  Indeed, at one point in the history of
> OTR, checking the "secure session id" (which was exactly a truncated
> hash of a few things including the session key) out of band was
> something users could explicitly do.
>
> But in general, it's good crypto hygiene to prevent one party in a key
> exchange from being able to control the particular value of the key that
> comes out.
>
>   - Ian
>


thank you for your fast response, it's good to know that I didn't miss
something in respect to the hash commitment.

Another question I have concerns the actual SIGMA authentication procedure:
1. Initially Alice derives the MAC keys a1, a2, b1, b2 and AES keys a3, b3
from the shared "master" secret s.

2. She then uses the key a1 to compute the MAC MA over the DH public keys
and her long-term public keys (we ignore the keyid engineering requirement
here).

3. In the next step she signs MA with her long-term sign key and the message
XA is constructed.

4. The message XA is encrypted and authenticated by computing a MAC tag over
the encrypted message with key a2.

While I understand the purpose of the key a2 (which is to authenticate
Alice's messages that are sent over an insecure channel), I'm not exactly
sure what the purpose of a1 is.
Wouldn't the exchange be the same if Alice used an unkeyed hash function
like SHA256 to sign the DH public keys and her long-term public key (i.e.
she would sign SHA256(g^x,g^y,v_A)) ?
Sure, the whole idea of SIGMA is to SIGn and MAc, but apart from that I do
not see the reason why in this case a MAC instead of a reguar unkeyed hash
function is used.
IMHO in this case it doesn't bring any additional security, right ?

cheers,
stefan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cypherpunks.ca/pipermail/otr-dev/attachments/20110317/92c9515a/attachment.html>


More information about the OTR-dev mailing list