3

I'm writing an application where both encryption/decryption and signing/verification are needed, and I choose X25519 as a key agreement algorithm which will produce a key for encryption, and ECDSA to sign messages.

Key generation: I generate a curve25519 private key from a mnemonic (so I have kind of a random 32 bytes private key).

Now I have 32 bytes array, I want to use this array byte array for both encryption and signing, the problem that I have is, for X25519 i need to apply key clamping for this private key to be valid which looks like this:

privateKey[0] &= 248;    // unset the 3 least significant bits
privateKey[31] &= 127   // unset the most significant bit
privateKey[31] |= 64      // set the second most significant bit

But for ECDSA, the key needs to be in the range $[1, N]$, where N (for curve25519) is equal to $2^{252}$ + a small factor, and so I need to convert my 32 bytes array to a number that fits in this range.

I have a few questions:

  • Why doesn't the X25519 private key need to fit in the range $[1, N]$?
  • Also why is it not important to apply the key clamping function used in X25519 to the key used for ECDSA?
Maarten Bodewes
  • 96,351
  • 14
  • 169
  • 323
jjd
  • 33
  • 4

1 Answers1

3

Why doesn't the X25519 private key need to fit in the range $[1,N]$?

By unsetting the most significant bit and the three least significant bits, you limit the key to effectively only 252 bits. When you say $N$ is $2^{252}$ + a small factor, you are talking about the order of the subgroup used by x25519, not the full order of the curve group. This subgroup has index (or cofactor) 8. Unsetting the three lower bits forces the secret to be a multiple of 8, meaning it will lie in this large prime-order subgroup.

Also why is it not important to apply the key clamping function used in X25519 to the key used for ECDSA?

To the best of my knowledge, Curve25519 is not used for ECDSA. Did you mean EdDSA (specifically, ed25519)?

meshcollider
  • 1,603
  • 1
  • 11
  • 15