Please review EdDSA API

[Michael StJohns]

On 7/25/2018 2:05 PM, Adam Petcher wrote:
> On 7/25/2018 11:24 AM, Michael StJohns wrote:
>
>>
>> *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));
>
> Did you mean PrivateKey ::= OctetToInteger(random)? Setting/clearing 
> bits here destroys information. If we don't prune here, then we can 
> reverse this operation later to get the byte array back to give to the 
> hash.

No - I meant what I wrote:

1) generate a private key from a random and store it as a big integer.  
E.g. generate a byte array of the appropriate length (32), twiddle the 
bits as described in step 2 of section 5.1.5 of RFC8032 and - 
interpreting that buffer as a little-endian encoding, save 's' (the 
secret scalar - aka - the actual private key) as a BigInteger.

That's the limit of what goes into the PrivateKey spec/interface.
2) When you do a signing, do SigningValue = 
HASH(IntegerToLittleEndianOctets(s)).
3) When done with signing, throw away the hash value - it doesn't need 
to be stored.

The *only* important characteristics of the signing value are a) it's 
confidential, and b) it's the same for each signature.  It could even be 
a random value generated and stored at the same time as the private key 
- but why?


>
>>
>> SigningValue ::= HASH (IntegerToOctet(PrivateKey)); // signing value 
>> may be regenerated at any time and need not be stored in the 
>> ECPrivateKey class.
>
> With the modification above, I agree that this would give the value 
> that can be split in half to produce the scalar value (after pruning 
> and interpreting as an integer) and the prefix that is used in signing.
>
> I think there may be some issues with this approach, but we need to 
> start by agreeing on what you are proposing. Can you confirm that my 
> understanding of your proposal is correct, or else clarify it for me?

What I'm trying to get to is make the java interfaces for EC private 
keys consistent regardless of which of the curve flavor you want to 
use.   In each and every case, looking behind the specified external 
representation, the scalar 's' can be represented as a BigInteger. 
Internal representation IN A SPECIFIC IMPLEMENTATION might use little 
endian internally, but that's irrelevant here for the purposes of java 
interfaces.    (At least in my opinion).

Later, Mike