Thus spake George Kadianakis (desnacked@xxxxxxxxxx): > 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
Attachment:
signature.asc
Description: Digital signature
_______________________________________________ tor-dev mailing list tor-dev@xxxxxxxxxxxxxxxxxxxx https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev