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.
