On 7/25/2018 10:29 AM, Adam Petcher wrote:
2) Similar to X25519/X448, private keys are byte arrays, and public
keys coordinates. Though we can't get by with a single BigInteger
coordinate for EdDSA, so I am using the new EdPoint class to hold the
coordinates.
*sigh* Private keys are big integers. There's an associated parameter
used in signing that the implementation described in the RFC (*not a
standard please note*) generates from a common random byte array - that
byte array is NOT a (or the) private key.
E.g. Private key ::= OctetToInteger(Adjust(Left (HASH(random),
length))) and SigningValue ::= Right(HASH(random),length).
Instead, you can get the exact same result (deterministic signatures) -
and store a bog standard EC private key - by
PrivateKey ::= OctetToInteger(Adjust(random));
SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value may
be regenerated at any time and need not be stored in the ECPrivateKey class.
Adjust twiddles the bits in the byte array to make the byte array a
valid little-endian private key before encoding for this set of curves.
OctetToInteger turns that byte array into a BigInteger.
At this point in time, you've got the correct values to do your point
math using common libraries if you don't happen to have implemented
exactly what's in the RFC.
I know the above is a losing argument, but seriously, do we really need
two new groups of EC classes simply because someone wrote an RFC that
didn't consider existing representational structures?
Or will it be three or more?
Later, Mike
