Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

When I'm generating a private key with openssl, it writes the curve's parameters, and the actual private key:

❯ openssl ecparam  -name secp256k1 -genkey

Note that the parameters does not contain real data, just reference to the standard used:

❯ openssl ecparam  -name secp256k1 | openssl asn1parse
    0:d=0  hl=2 l=   5 prim: OBJECT            :secp256k1

However when I look at the private key, I can see that it contains the curve type used! Look at the line starting with 41:d

❯ openssl ecparam  -name secp256k1 -genkey -noout | openssl asn1parse
    0:d=0  hl=2 l= 116 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :01
    5:d=1  hl=2 l=  32 prim: OCTET STRING      [HEX DUMP]:872F67D0B852C6FE9BD1F5B93AF54B7555D21267200DA2F8ED735729BF32730A
   39:d=1  hl=2 l=   7 cons: cont [ 0 ]        
   41:d=2  hl=2 l=   5 prim: OBJECT            :secp256k1
   48:d=1  hl=2 l=  68 cons: cont [ 1 ]        
   50:d=2  hl=2 l=  66 prim: BIT STRING

Is there a reason I need the EC parameters? Why does it produce them by default?

(The only reason I can think of needing those EC parameters, are to use them as an input when generating a private key, but aren't you better off give their name in the command line?)

share|improve this question
up vote 3 down vote accepted

It is a quirk of OpenSSL. The ecparam command is meant for handling EC parameters -- namely, the definition of a curve to play on -- and allows the generation of a private key as a secondary feature. You can use the -noout command-line argument to suppress the production of the encoded EC parameters themselves:

$ openssl ecparam -name secp256k1 -genkey -noout

Also, the existence of an "EC parameters" stand-alone structure is justified by the fact that the private key encoding could lack the information; see RFC 5915 which gives the following ASN.1 type:

ECPrivateKey ::= SEQUENCE {
  version        INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
  privateKey     OCTET STRING,
  parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
  publicKey  [1] BIT STRING OPTIONAL

where the parameters and publicKey fields are duly marked as "optional".

As for the internal representation of the parameters (either stand-alone or as part of the private key structure), the use of a simple OID is rather normal. Generating your own elliptic curve is substantially harder than producing new DSA parameters; also, sticking to a few standard curves makes implementation of EC cryptography both easier and faster. Therefore, most implementations out there are restricted to a few standard curves, often the P-256 and P-384 from NIST (actually from SEC, then "annexed" by NIST). Implementations which support all 15 standard NIST curves are a rarity; implementations which support "arbitrary" curves (where the full curve values are encoded in the parameters structure) are mythical (I never stumbled on one, although I got close to writing one at some point).

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.