Please review EdDSA API

[Adam Petcher]

On 7/26/2018 3:58 PM, Michael StJohns wrote:

> On 7/25/2018 2:05 PM, Adam Petcher wrote:
>>
>> 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.
>
Does this produce the same result as the signing function described in 
sections 3.2 and 3.3 of the RFC? If I do as you suggest, will the test 
vectors in Section 7 pass? It's not obvious to me that the signing 
procedure that you are proposing is the same function.