Thus spake George Kadianakis (desnacked@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...
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?