Re: [GNUnet-developers] key exchanges [updated, resend]

[Christian Grothoff]

On 08/27/2015 12:13 AM, Jeff Burdges wrote:
> 
> 
> Just a brief summery thus far : 
> 
> We've a complicated four round key exchange described two messages ago
> (Tuesday) in which Alice signs the xor of a message hash with a special
> collaborative random number. 

No, we disagreed that XORing the message is not OK. You need to add a
"random" point offset during signing where both Alice and Bob ensure
randomness by having Alice commit to the hash of a value and Bob adding
an XOR to that. Alice then reveals her commitment when returning the
signature in step 2.

I'm a bit lost in all of your posts, did you ever write up that version
"properly"?

> We hoped that pairing that with the modified ECDSA from three messages
> ago (Monday) would give a system that's both deniable and resistant to
> Dominic's wildcard attack.  

Right, i still think that's the case.

> 
> I found a limited attack on that combined scheme : 
> 
> Eve wishes to prove Alice initiated a specific key exchange.  Eve
> somehow compromises Alice's z and (r,s) from the key exchange session,
> say by performing an MITM attack after compromising Bob's private key.

Doesn't work, she'd have to have gotten Bob's ephemeral key from the KX
as well. As Bob destroys that after the KX (and possible ratcheting),
the answer is that you're considering Eve being really a Mallory posing
as Bob during the KX.  As you also assume that Mallory has Bob's private
key, all you say is that Mallory being in possession of Bob's secret AND
being an active adversary with control over the network can pretend to
be Bob and find out that it was Alice who wanted to talk to Bob. That's
not the wildcard attack or anything any scheme could prevent.

> And Eve later compromise Alice's private key.  
> 
> Eve examines the (r,s) sent by Alice.  As Eve knows d_A she can solve
> for the random scalar k in  s = k^{-1} (z + r d_A) mod n  to deduce the
> random point (x_1,y_1) and find the collaborative random value x, thus
> voiding Alice's deniability.

Compromising Alice's key later without having the ECDSA-signature
modification point information from the KX is useless, and this part was
secured with 3DH, not just Alice's key. Compromising Alice's private key
would allow you to recover Alice's commitment C:=H(x)
(assuming the offset point is off := x + y where y is chosen by Bob).
However, having C (or even x) without knowing y is again useless, and y
we can protect with 3DH. (only C in the first message is 2DH as we don't
have Bob's ephemeral yet).

Happy hacking!

Christian

signature.asc
Description: OpenPGP digital signature