# Can I use any number as an ECC key?

I've been looking into elliptic curve cryptography, and have been trying to understand how I can and can't use it. Note that this is a hobby project and I am not making my own crypto systems for anything serious.

I am attempting to create an elliptic curve key pair that is dependent on outputs from other cryptographic functions. As far as I understand it, an key in ECC is based on a single point on the curve, as opposed to RSA which uses a pair of primes.

Does this mean that I can use random bits (or hash outputs) of the correct length as the private key of a curve such as Curve25519?

I've struggled to find information on this topic, but I do know that the soon-to-be released system SQRL (https://www.grc.com/sqrl/crypto.htm, "SQRL's underlying crypto technology") mentions using such a system. If I haven't understood it right, how is this working?

• Please don't ever link to GRC. That is a snake oil website of the worst kind. Note also that SQRL has been fatally broken. See here and here. Mar 16 '18 at 6:35
• Thanks for bringing that to my attention, I wasn't aware of the problems with GRC. I guess I should be more careful and do my research! Mar 16 '18 at 18:59

You have to specify a particular cryptosystem for a particular answer. Generally, in an elliptic-curve-based cryptosystem, a secret key involves a scalar, which is an integer within the range of the number of points in a group on the curve, possibly subject to some constraints, and chosen uniformly at random from all possibilities. It's OK if you get that by hashing a secret of sufficient entropy, and shoehorning it into the right range.

In the Diffie–Hellman function X25519, a secret key is traditionally an arbitrary string of 256 bits, with some bits masked so that the Curve25519 scalar is a uniform random choice of a multiple of 8 between $2^{254}$ and $2^{255}$ for a couple of reasons: [1], [2].

In the signature scheme Ed25519, there are a few different forms of secret key for different applications and performance constraints. For compatibility reasons, the same masking is often done on the bits that get interpreted as an edwards25519 scalar, though there are other issues too in more exotic applications.

In ECDH and ECDSA over prime-order curve groups such as NIST P-256 or secp256k1, a secret key is usually the canonical encoding of any positive integer below the order of the group which is necessarily also the order of the standard base point. Mostly ECDSA is done over curve groups with prime order and no concern for twist security (e.g., the largest prime factor of the order of the quadratic twist in NIST P-224 has only 118 bits, well within the realm of ECDLP feasibility), unlike X25519 and Ed25519 which work in a curve group of cofactor 8 whose quadratic twist has cofactor 4.