Please review EdDSA API

[Michael StJohns]

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