n
nearly 2p is nearly 2x n (n the number of points on the curve). So
therefore around half of the points you could start from are not on the
curve, there is no solution when you try to solve for y from the curve
equation. As you see in the harkin draft in that type of curve it is
because x^3+ax+b has no square root.
So you know about point compression? Basically you can almost recover a
point from the x-coord only because each point is (x,f(x)) but with one
caveat that because its a symmetric curve about the x-axis you also need to
say whether thats f(x) or -f(x). So people would send the x-coord and one
bit for the sign.
Its getting kind of complicated but it seems to me DJB ensures all 32 byte
encoded points are points by a kind of definitional trick that a point is
not the x-coord and sign bit, but the number x multiplied by a base point
(9,f(9)) which of course is a valid point because (9,f(9)) is a generator.
Its an equally valid encoding method and is probably faster.
However if you call (9,f(9))=G, you cant use DJB point encoding when you're
doing PAKE because well if password attempt pwd1 you get pwd1.G and then you
do some DH thing with it, send to the otherside they do Y=x.pwd1.G and send
back, thats bad because you can revise pwd1 to pwd2 by division:
pwd2.pwd1^-1.Y = pwd2.pwd1^-1.x.G=x.pwd2.G and then you can offline grind
the PAKE key exchange which is bad.
So for that you really need to start from x = H(password) and point
G=(x,f(x)) and that was what the hunt and peck algorithm in Harkins is
about. DJB has a solution for that too in his Elligator paper which is
constant time (as I recall worst case two tries) because he can use a
different method relating to the more flexible and and more efficient curves
he chose.
Is it just me or could we better replace NIST by DJB ? ;) He can do that EC
crypto, and do constant time coding (nacl), and non-hackable mail servers
(qmail), and worst-time databases (cdb). Most people in the world look like
rank amateurs or no-real-programming understanding niche-bound math geeks
compared to DJB!
Adam
>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>On 03/10/13 15:14, Adam Back wrote:
>> Well I think there are two issues:
>>
>> 1. if the public key is derived from a password (like a bitcoin
>> brainwallet), or as in EC based PAKE systems) then if the point
>> derived from your password isnt on the curve, then you know that
>> is not a candidate password, hence you can for free narrow the
>> password search. (Which particularly for PAKE systems weakens
>> their security).
>
>> 2. if the software doesnt properly validate that the point is on
>> the curve, and tries to do an operation involving a private key or
>> secret, anyway, it may leak some of the secret. DJB has some
>> slides saying he found some software does not check.
>
>Hmm, so perhaps the statement quoted above simply means "Curve25519
>contains its own key validation code, and will complain if the string
>you give it isn't a valid public key?"
>
>Cheers,
>Michael
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.10 (GNU/Linux)
>
>iQEcBAEBAgAGBQJSTZLlAAoJEBEET9GfxSfM4dMH/jo83Jse5V6DqnZwaIkNesLY
>AufH8+amkMALbO8Db7r/sG+cGXMy8sSRWqPTJ0jXd3z4ZAgKbx3aW2eBEmIU9i3Y
>K0jkABVJty3XyvPAspoCUwZ+Fh7brUSCRHQJt0MWMQADPdoXJUY+iobmCGgO4Qbk
>+npDlo3pTNeEofsvkEM3uSPofR88JXvMC1sYhGr4+GMsBt330vG2Zd278AlVTlOb
>fVpwEtlad5Fb58RfGidMb4n7BUKKmkPI3KJewpJEXfc8CMP1ITsmX8hTzIz0wakz
>ubjwDu7ENUMkZhfkt4qNpTLeWQBOFrrfUDe9qrlTY5GpbNfy295K/aWMvi65c6g=
>=sxPV
>-----END PGP SIGNATURE-----
From jamesd at echeque.com Thu Oct 3 14:21:21 2013
From: jamesd at echeque.com (James A. Donald)
Date: Fri, 04 Oct 2013 04:21:21 +1000
Subject: [cryptography] the spell is broken
In-Reply-To: <39166989-181F-482C-A8D0-9BF74E4FAFAE@gmail.com>
References: <524C3EA1.2090802@iang.org> <524C49F7.1030908@comcast.net>
<2714EE2F-EC14-4717-98F6-95FDA9551F20@gmail.com>