Please review EdDSA API
Michael StJohns
mstjohns at comcast.net
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.
Mike
More information about the security-dev
mailing list