[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: [tor-dev] RFC on obfs3 pluggable transport



On Wed, Dec 12, 2012 at 11:14:08AM -0500, vmonmoonshine@xxxxxxxxx wrote:
> >The only issue with your trick, is that I'm not looking forward
> >implementing a custom DH key exchange in Python (especially the DH
> >parameter generation and public key validation parts).
> 
> From the conversation of Zack with Steven at the breakfast table at
> Hotel Cellai, I'm pretty sure that Stegotorus is using DH based on 
> elliptic curve and its twist protocol. So you can find an implementation
> of it there. Though I haven't looked at the crypto part of the code myself.
> 
> Also could you please refer me to the reference that proves that X or
> p-X is uniformly random. It seems to me that you are taking a quadratic
> residue to an even power, so you always get a bi-quadratic residue for
> X. Then if I'm the distinguisher who knows the public group, and I see that the
> bi-quadratic residues appears 1/2 times instead of 1/4 of the times then
> I can smell that something going on.

Z_p^* has order 2q, where q=(p-1)/2 is prime.  Since 2 is a quadratic
residue, both 2 and 4 generate all of the order-q subgroup of quadratic
residues (call the group Q), so X will be a uniform (up to
negligibility) element of Q.  Since -1 is a quadratic non-residue, X is
a quadratic residue if and only if p-X is not.  (For all 0 < X < p.)  So
the output (randomly X or p-X) will be a uniform element of Z_p^*, which
is negligibly different from a uniform 1536-bit string.

[There's no such thing as a "bi-quadratic residue" in this setting; all
quadratic residues in this group have one square root which is itself a
quadratic residue and one which is not.]

   - Ian
_______________________________________________
tor-dev mailing list
tor-dev@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev