Perché openssl scrive i parametri EC quando genera la chiave privata?

Question

Perché openssl scrive i parametri EC quando genera la chiave privata?

#1 da (6 voti)

7

Quando sto generando una chiave privata con openssl , scrive i parametri della curva e la chiave privata effettiva:

❯ 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-----

Si noti che i parametri non contengono dati reali, solo un riferimento allo standard utilizzato:

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

Tuttavia, quando guardo la chiave privata, posso vedere che contiene il tipo di curva usato! Guarda la riga che inizia con 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

C'è una ragione per cui ho bisogno dei parametri CE? Perché li produce di default?

(L'unica ragione per cui posso pensare di aver bisogno di quei parametri EC, è di usarli come input quando si genera una chiave privata, ma non è meglio dare il loro nome nella riga di comando?)

openssl ecc asn1

posta Elazar Leibovich 27.01.2013 - 23:00

fonte

1 risposta

Leggi altre domande sui tag openssl ecc asn1

UAC e servizi Windows Come usare NMap per portscan un SonicWall che blocca tutti i tentativi?

score 6 · Accepted Answer

È una stranezza di OpenSSL. Il comando ecparam è pensato per gestire i parametri EC, ovvero la definizione di una curva su cui giocare, e consente la generazione di una chiave privata come caratteristica secondaria. Puoi utilizzare l'argomento della riga di comando -noout per sopprimere la produzione dei parametri EC codificati stessi:

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

Inoltre, l'esistenza di una struttura autonoma di "parametri CE" è giustificata dal fatto che la codifica della chiave privata potrebbe mancare delle informazioni; vedi RFC 5915 che fornisce il seguente tipo di ASN.1:

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

dove i campi parameters e publicKey sono debitamente contrassegnati come "facoltativi".

Come per la rappresentazione interna dei parametri (stand-alone o come parte della struttura della chiave privata), l'uso di un OID semplice è piuttosto normale. Generare la propria curva ellittica è sostanzialmente più difficile rispetto alla produzione di nuovi parametri DSA; inoltre, attenersi a poche curve standard rende l'implementazione della crittografia CE sia più facile che più veloce. Pertanto, la maggior parte delle implementazioni disponibili sono limitate a poche curve standard, spesso P-256 e P-384 da NIST (in realtà da SEC, quindi" annessa "dal NIST). Le implementazioni che supportano tutte le 15 curve NIST standard sono una rarità; le implementazioni che supportano curve "arbitrarie" (dove i valori completi della curva sono codificati nella struttura dei parametri) sono mitiche (non mi sono mai imbattuto in una, anche se sono arrivato vicino a scriverne una ad un certo punto).