Please review EdDSA API

Michael StJohns mstjohns at
Thu Jul 26 21:05:27 UTC 2018

On 7/26/2018 4:24 PM, Adam Petcher wrote:
> 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.

Note that the signing value (e.g. prefix) is used as part of the 
formation of 'r' in signing, but is not recoverable from the 
signature.   s is calculated from whatever value of r you get and the 
two taken together (r,s) form the actual signature.   Note that 'prefix' 
could be a random value if you wanted non-deterministic signatures, but 
the inclusion of a fixed prefix value means that the same signature will 
be generated by the same private key over the same data.

The test vectors will not pass, because they are calling the byte array 
from which the private key and the signing value are derived as the 
private key.

However, each and every signature generated by the above approach (e.g. 
using a *real* private key and a signing value downstream derived from 
that private key) *will* verify, and each and every signature by that 
private key over the same data using the above approach will produce 
identical signatures.


More information about the security-dev mailing list