web-dev-qa-db-ja.com

opensslが秘密鍵の生成時にECパラメーターを書き込むのはなぜですか?

opensslを使用して秘密キーを生成すると、曲線のパラメーターと実際の秘密キーが書き込まれます。

❯ openssl ecparam  -name secp256k1 -genkey
-----BEGIN EC PARAMETERS-----
BgUrgQQACg==
-----END EC PARAMETERS-----
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIKYV1xoz6smkpdMksfgI8/3465V02UZdaKj4JSH30bBhoAcGBSuBBAAK
oUQDQgAEO1O+/xRGEVJgBEAOQorBveXPTQS3c7MA+9R+HEMP7TkscI9FONPclcRb
5sXZJjYHNYWhvxuXdGl8QrFVRIVBYg==
-----END EC PRIVATE KEY-----

パラメータには実際のデータは含まれず、使用されている標準への参照のみであることに注意してください。

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

ただし、秘密キーを見ると、使用されている曲線の種類が含まれていることがわかります。 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

ECパラメーターが必要な理由はありますか?デフォルトでそれらを生成するのはなぜですか?

(私がそれらのECパラメーターが必要だと考えることができる唯一の理由は、秘密鍵を生成するときにそれらを入力として使用することですが、コマンドラインでそれらの名前を指定した方がいいですか?)

10

これはOpenSSLの癖です。 ecparamコマンドは、ECパラメーター(つまり、再生する曲線の定義)を処理するためのもので、2次機能として秘密鍵を生成できます。 -nooutエンコードされたECパラメーター自体の生成を抑制するコマンドライン引数:

$ openssl ecparam -name secp256k1 -genkey -noout
-----BEGIN EC PRIVATE KEY-----
MHQCAQEEIHyx/m9I6/ZbvqN5XJ/fZSM6P7PIuvNDnWdp8STjlGqQoAcGBSuBBAAK
oUQDQgAEVGRwTHlFRgxmhnJNO4Vfdojmg2pni44U4SMFEziNM8YVhd62UzwB5L0+
n8EXsvTIv5Uj7COQd/1cTsdL9kin4w==
-----END EC PRIVATE KEY-----

また、「ECパラメーター」のスタンドアロン構造の存在は、秘密鍵のエンコードが情報を欠く可能性があるという事実によって正当化されます。 RFC 5915 を参照してください。これにより、次のASN.1タイプが提供されます。

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

parametersおよびpublicKeyフィールドは、「オプション」として正式にマークされています。

パラメータの内部表現(スタンドアロンまたは秘密キー構造の一部として)の場合、単純なOIDの使用はかなり正常です。独自の楕円曲線の生成はかなり困難です。新しいDSAパラメータを作成するよりも、いくつかの標準曲線に固執することで、EC暗号化の実装がより簡単かつ高速になります。したがって、そこにあるほとんどの実装は、いくつかの標準曲線に制限され、多くの場合、P-256およびP-384 [〜#〜] nist [〜#〜] (実際にはSECから、その後NISTによって「追加」)。15の標準NIST曲線すべてをサポートする実装は珍しいです。「任意」の曲線をサポートする実装(ここで完全な曲線の値は、parameters構造でエンコードされます)神話的です(ある時点で1つに書き始めたものの、私はつまずきませんでした)。

9
Thomas Pornin