我正在尝试了解OpenSL存储私人ECDSA密钥的格式。据说它在 rfc 5915 ecprivatekey格式（首先是 secg，请参阅c.4 ）：
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
非常适合：
” EGXGLPS6MXFEJFSWFT4K7GGONCUXCEU-eylj4r0xqJlgWSTG18H5JJ1RFTLE8UTDI8UTDI8F84BMZEUGASAATGA“ rel =“ nofollow noreferrer” /a>。）
不合适的是突出显示的 publicKey 数据结构。它包含66个字节，带有领先的0x00字节。根据标准“ publicKeke包含与有关私钥相关的椭圆曲线公共密钥。公共密钥的格式在[RFC5480]的第2.2节中指定：
The first octet of the OCTET STRING indicates whether the key is
compressed or uncompressed. The uncompressed form is indicated
by 0x04 and the compressed form is indicated by either 0x02 or
0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if
any other value is included in the first octet.
因此，明确禁止了领先的0x00。 /strong>。该场的其余部分再次完全拟合：0x04表示未压缩和NIST P-256（“ Prime256v1”）使用256位Galois场，因此曲线可以在两个32byte坐标中表达，从而填充了其余的64bytes。因此，一个领先的零字节，一个无压缩的字节和两个32个字节坐标构成了66个字节ASN.1位字符串有效载荷。
问题是：为什么引导零字节存在？
供参考的私钥文件内容：
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIJmBX3aXvprsnhd7SPOETKLnYQRH2S9ZLH7nEbGysQXroAoGCCqGSM49
AwEHoUQDQgAEHODZEGxGLpS6MxFEJFswFT4K7gGONCuXceu+eyLj4r0xqjLGWsTG
18H5Jj1RfTlE8UTdI8F84bmZeugASAaTGA==
-----END EC PRIVATE KEY-----
I'm trying to understand the format in which OpenSSL stores private ECDSA keys. Supposedly it is in RFC 5915 ECPrivateKey format (which apparently was first defined by SECG, see C.4):
ECPrivateKey ::= SEQUENCE {
version INTEGER { ecPrivkeyVer1(1) } (ecPrivkeyVer1),
privateKey OCTET STRING,
parameters [0] ECParameters {{ NamedCurve }} OPTIONAL,
publicKey [1] BIT STRING OPTIONAL
}
Which fits very well:
(Also online here.)
What does not fit is the highlighted publicKey data structure. It contains 66 bytes with a leading 0x00 byte. According to the standard "publicKey contains the elliptic curve public key associated with the private key in question. The format of the public key is specified in Section 2.2 of [RFC5480]" which says:
The first octet of the OCTET STRING indicates whether the key is
compressed or uncompressed. The uncompressed form is indicated
by 0x04 and the compressed form is indicated by either 0x02 or
0x03 (see 2.3.3 in [SEC1]). The public key MUST be rejected if
any other value is included in the first octet.
Thus the leading 0x00 is explicitly forbidden. The rest of the field fits perfectly again: 0x04 indicates uncompressed and NIST P-256 ("prime256v1") uses a 256bit Galois field, so a curve point can be expressed in two 32byte coordinates and thus fills the remaining 64bytes. So one leading zero byte, one no-compression-used byte and two 32 byte coordinates make up the 66 byte ASN.1 BIT STRING payload.
The question is: Why is the leading zero byte present?
The private key file content for reference:
-----BEGIN EC PRIVATE KEY-----
MHcCAQEEIJmBX3aXvprsnhd7SPOETKLnYQRH2S9ZLH7nEbGysQXroAoGCCqGSM49
AwEHoUQDQgAEHODZEGxGLpS6MxFEJFswFT4K7gGONCuXceu+eyLj4r0xqjLGWsTG
18H5Jj1RfTlE8UTdI8F84bmZeugASAaTGA==
-----END EC PRIVATE KEY-----
发布评论