JCA design for RFC 7748
Adam Petcher
adam.petcher at oracle.com
Fri Aug 18 19:26:18 UTC 2017
On 8/17/2017 1:44 PM, Michael StJohns wrote:
> See inline.
>
> On 8/17/2017 11:19 AM, Adam Petcher wrote:
>
>>
>> Specifically, these standards have properties related to byte arrays
>> like: "The Curve25519 function was carefully designed to allow all
>> 32-byte strings as Diffie-Hellman public keys."[1]
>
> This statement is actually a problem. Valid keys are in the range of
> 1 to p-1 for the field (with some additional pruning). 32 byte
> strings (or 256 bit integers) do not map 1-1 into that space. E.g.
> there are some actual canonical keys where multiple (at least 2) 32
> byte strings map to them. (See the pruning and clamping algorithms).
> The NIST private key generation for EC private keys mitigates this
> bias by either (a) repeatedly generating random keys until you get one
> in the range or (b) generating a key stream with extra (64) bits and
> reducing that mod p of the curve.
If you are concerned about the distribution of private keys in these
standards, then you may want to raise your concerns on the CFRG mailing
list (cfrg at irtf.org). I don't have this concern, so I think we should
implement the RFC as written.
>
>>
>> RFC 8032 private keys: These are definitely bit strings, and modeling
>> them as integers doesn't make much sense. The only thing that is ever
>> done with these private keys is that they are used as input to a hash
>> function.
>
> Again - no. The actual private key is what you get after stage 3 of
> section 5.1.5. E.g. generate a random string of 32 bytes. Hash it to
> help with the bad random generators (*sheesh*), Interpret the hash
> after pruning as a little endian integer.
I'm not sure I understand what you are suggesting. For Ed25519, the
initial 32-byte secret is hashed to produce 64 bytes. The first 32 bytes
are pruned, interpreted as an integer, and used to produce the public
key. The second 32 bytes are also used in the signing operation and
contribute to a deterministic nonce. See RFC 8032, section 5.1.6, step
1. Are you suggesting that we should represent all 64 bytes as an integer?
More information about the security-dev
mailing list