[tor-dev] [tor-reports] George's status report: November 2012

[Mike Perry]

Thus spake George Kadianakis (desnacked at riseup.net):

> Hi,
> 
> - Started researching and developing obfs3, an improved version of the
>   obfs2 pluggable transport. The proposed protocol currently looks
>   like this:
>   https://gitweb.torproject.org/user/asn/pyobfsproxy.git/blob/refs/heads/obfs3:/doc/obfs3-protocol-spec.txt
> 
>   The current implementation uses curve25519 to do ECDH, but
>   curve25519 public keys don't look random enough on the wire and we
>   will probably need to use a curve similar to the one that Telex
>   uses.
> 
>   Ian, Philipp and Roger helped a lot with this.

Holy crap. In what way are the public keys in curve25519 "not random
enough"?

I don't really know anything of substance about ECC (especially ECC
curve choice), but if the public keys are distributed unevenly over the
keyspace, isn't this a hint of something extremely bad?

At the very least, it sounds like it hints at reduced strength of the
curve: non-uniformity over a 256bit keyspace means it takes less than
256 bits to describe the keypair mapping, which should mean a technique
exists with less than 2^128 operations for solving the ECDLP (as
compared to using Shanks or rho collisions, etc).

Did you write this up anywhere? I see the XXX for the "FAQ" entry in
your spec...

Also, to help reduce my ignorance: Does anyone know if ECC curves are
usually tested for key distribution uniformity?


-- 
Mike Perry
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.torproject.org/pipermail/tor-dev/attachments/20121203/99ba1502/attachment.pgp>