UWP ECDSP 签名 [英] UWP ECDSP Signature
问题描述
我想用这个代码做一个 ECDSA 签名:
I want to make a ECDSA signature with this code :
AsymmetricKeyAlgorithmProvider objAsymmAlgProv = AsymmetricKeyAlgorithmProvider.OpenAlgorithm(AsymmetricAlgorithmNames.EcdsaSha256);
CryptographicKey keypair = objAsymmAlgProv.CreateKeyPairWithCurveName(EccCurveNames.SecP256r1);
BinaryStringEncoding encoding = BinaryStringEncoding.Utf8;
buffMsg = CryptographicBuffer.ConvertStringToBinary("Test Message", encoding);
IBuffer buffSIG = CryptographicEngine.Sign(keypair, buffMsg);
byte [] SignByteArray = buffSIG.ToArray();
bool res = CryptographicEngine.VerifySignature(keypair, buffMsg, buffSIG);
VerifySignature
总是返回 true,这没问题.
VerifySignature
always returns true and this is ok.
但是我在签名方面遇到了一些问题.
But I have some problems with signature.
为什么签名的长度 (SignByteArray
) 是固定的?(0x40 字节).
Why is length of signature ( SignByteArray
) fixed? (0x40 byte).
为什么 SignByteArray [0]
和 SignByteArray [2]
值不正确?(我认为它们应该是 0x30 和 0x02)
And Why are SignByteArray [0]
and SignByteArray [2]
values incorrect? (I think they should be 0x30 and 0x02)
我期待像 https://kjur.github.io/jsrsasign/示例 ecdsa.html
推荐答案
ECDSA 规范的结论是确定 (r
, s
) 对是签名.它没有做的是指出应该如何写下来.
The ECDSA specification concludes with a determination that the pair (r
, s
) are the signature. What it neglects to do is indicate how one should write them down.
Windows 和 .NET 使用 IEEE (P)1363 格式,即 big-endian r
concat big-endian s
.r
和 s
具有相同的大小(由密钥大小决定),因此签名的长度总是偶数,而 r 是前半部分.
Windows and .NET use the IEEE (P)1363 format, which is big-endian r
concat big-endian s
. r
and s
have the same size (determined by the key size), so the signature is always even in length and r is the first half.
OpenSSL 使用 ASN.1/DER 编码,即 SEQUENCE(INTEGER(r), INTEGER(s)).DER 编码可以一直下降到 6 个字节(30 04 02 00 02 00
,在退化的 r=0, s=0 中)并且平均比 IEEE 大 6 个字节形式.它编码为 30 [长度,一个或多个字节] 02 [长度,一个或多个字节] [可选填充 00] [没有前导 00 的大端 r] 02 [长度,一个或多个字节] [可选padding 00] [没有前导 00 的 big-endian s]
.
OpenSSL uses an ASN.1/DER encoding, which is SEQUENCE(INTEGER(r), INTEGER(s)). The DER encoding can go all the way down to 6 bytes (30 04 02 00 02 00
, in the degenerate r=0, s=0) and is, on average, 6 bytes bigger than the IEEE form. It encodes as 30 [length, one or more bytes] 02 [length, one or more bytes] [optional padding 00] [big-endian r with no leading 00s] 02 [length, one or more bytes] [optional padding 00] [big-endian s with no leading 00s]
.
DER 形式过于依赖数据而无法具体描述,因此示例应该会有所帮助.假设我们在 32 位字段中使用曲线并生成 (r=1016, s=2289644760).
The DER form is too data dependant to specifically describe, so an example should help. Assuming we're using a curve in a 32-bit field and we generate (r=1016, s=2289644760).
IEEE 1363:
// r
00 00 03 F8
// s
88 79 34 D8
德:
SEQUENCE(INTEGER(1016), INTEGER(2289644760))
// Encode r
// 1016 => 0x3F8 => 03 F8 (length 02)
SEQUENCE(
02 02
03 F8,
INTEGER(2289644760))
// Encode s
// 2289644760 => 0x887934D8 => 88 79 34 D8
// But since the high bit is set this is a negative number (-2005322536),
// and s is defined to be positive. So insert a 00 to ensure the high bit is clear.
// => 00 88 79 34 D8 (length 05)
SEQUENCE(
02 02
03 F8
02 05
00 88 79 34 D8)
// And encode the sequence, whose payload length we can now count as 11 (0B)
30 0B
02 02
03 F8
02 05
00 88 79 34 D8
所以 Windows/.NET 发出 00 00 03 F8 88 79 34 D8
,而 OpenSSL 发出 30 0B 02 02 03 F8 02 05 00 88 79 34 D8
.但他们都只是在说 (r, s) = (1016, 2289644760)
.
So Windows/.NET emit 00 00 03 F8 88 79 34 D8
, and OpenSSL emits 30 0B 02 02 03 F8 02 05 00 88 79 34 D8
. But they're both just saying (r, s) = (1016, 2289644760)
.
(旁白:您观察到 DER 编码中的签名 [2] == 0x02 对于您正在使用的大小密钥是正确的,但在大约 496 位密钥时,序列长度在统计上可能需要超过一个字节;因此对于 P-521 密钥,它很可能以 03 81 88 02
开头,88
字节具有可变性)
(Aside: Your observation that signature[2] == 0x02 in the DER encoding is correct for the size key you're working with, but at around a 496-bit key the SEQUENCE length becomes statistically likely to require more than one byte; so for a P-521 key it's most likely that it starts as 03 81 88 02
, with variability in the 88
byte)
这篇关于UWP ECDSP 签名的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!