UWP ECDSP 签名 [英] UWP ECDSP Signature

查看:19
本文介绍了UWP ECDSP 签名的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我想用这个代码做一个 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.rs 具有相同的大小(由密钥大小决定),因此签名的长度总是偶数,而 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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆