算法本身有没有问题(也许我根本不应该使用它)?
非 EC DSA 正在消亡。
我推测真正做到这一点的是原始规范 (FIPS 186-1) 将密钥限制为 1024 位,将算法限制为 SHA-1。 2009 年,该算法在 FIPS 186-3 中得到更新,以支持稍大的密钥和 SHA-2 哈希。 FIPS 186-1(和 FIPS 186-2)DSA 签名只需要数据和私钥(验证只需要数据、签名和公钥),FIPS 186-3 签名还需要哈希算法作为输入...所以 API 并不完全兼容。
Windows CAPI(两个 Windows 加密平台中较旧的一个)忽略了 FIPS 186-3 更新,Apple 的 Security.framework 也是如此。 Windows CNG 和 OpenSSL 都支持“新 DSA”。 Apple 无法处理使用“新 DSA”签名的证书(甚至可能不使用“DSA 经典”,我忘记了),并且 Windows 不支持证书链中的“新 DSA”,仅支持“DSA 经典”。
因此,DSA 证书通常仅限于 FIPS 186-1/186-2 限制,这意味着 SHA-1(现在对任何人都不利)和 1024 位密钥(按照今天的计算太小了)。如果您知道自己正在通过 OpenSSL 进行验证,则可以使用更好的 DSA 密钥。
DSA 在签名验证方面通常也比 RSA 慢得多。
在 80 位安全级别,在我的一个随机 VM 上使用 OpenSSL 的速度工具(输出稍作修改以用于演示目的,按 verify/s 降序排序):
sign verify sign/s verify/s
rsa 1024 bits 0.000301s 0.000018s 3326.3 56419.7
dsa 1024 bits 0.000309s 0.000236s 3236.2 4240.5
ecdsa 160 bits (secp160r1) 0.0005s 0.0004s 1984.6 2385.7
112 位安全性
sign verify sign/s verify/s
rsa 2048 bits 0.002030s 0.000062s 492.6 16062.4
ecdsa 224 bits (nistp224) 0.0001s 0.0002s 9020.6 4252.2
dsa 2048 bits 0.000885s 0.000802s 1129.4 1247.3
128 位安全性
sign verify sign/s verify/s
rsa 3072 bits 0.006935s 0.000135s 144.2 7401.6
ecdsa 256 bits (nistp256) 0.0001s 0.0002s 16901.5 5344.7
ecdsa 256 bits (brainpoolP256t1) 0.0010s 0.0008s 980.1 1262.5
ecdsa 256 bits (brainpoolP256r1) 0.0010s 0.0008s 1012.9 1209.5
dsa 3072 bits (not in test suite)
192 位安全性
sign verify sign/s verify/s
rsa 7680 bits 0.122805s 0.000820s 8.1 1220.2
ecdsa 384 bits (nistp384) 0.0024s 0.0018s 416.1 571.2
ecdsa 384 bits (brainpoolP384t1) 0.0024s 0.0018s 410.0 545.1
ecdsa 384 bits (brainpoolP384r1) 0.0025s 0.0019s 407.4 540.1
dsa 7680 bits (beyond FIPS 186-3 DSA maximum of 3072 bits)
256 位安全性
sign verify sign/s verify/s
ecdsa 521 bits (nistp521) 0.0006s 0.0012s 1563.1 841.3
ecdsa 512 bits (brainpoolP512t1) 0.0038s 0.0027s 265.2 369.1
ecdsa 512 bits (brainpoolP512r1) 0.0038s 0.0028s 262.4 360.5
rsa 15360 bits 0.783846s 0.003190s 1.3 313.5
dsa 15360 bits (beyond FIPS 186-3 DSA maximum of 3072 bits)
我只能在 CertificateRequest 调用中使用 RSA 和 ECDsa。没有包含 DSA 的原因有哪些?
来自original feature proposal的线程:
基于来自 Windows 的新数据(以及它们缺乏对 FIPS 186-3 DSA 证书的支持),我将提取 DSA 类型的构造函数并将 DSA 保留为“高级用户”场景(自定义 X509SignatureGenerator 类等)
所以,它被删除主要是因为 DSA 正在消亡。
还是我在 API 中遗漏了什么?
API 允许提供自定义签名生成器。在 CertificateRequest 的测试中,它用 DSAX509SignatureGenerator 证明了这一点
X509SignatureGenerator dsaGen = new DSAX509SignatureGenerator(dsaCsp);
// Use SHA-1 because that's all DSACryptoServiceProvider understands.
HashAlgorithmName hashAlgorithm = HashAlgorithmName.SHA1;
CertificateRequest request = new CertificateRequest(
new X500DistinguishedName($"CN={KeyName}-{provType}"),
dsaGen.PublicKey,
hashAlgorithm);
DateTimeOffset now = DateTimeOffset.UtcNow;
using (X509Certificate2 cert = request.Create(request.SubjectName, dsaGen, now, now.AddDays(1), new byte[1]))
using (X509Certificate2 certWithPrivateKey = cert.CopyWithPrivateKey(dsaCsp))
using (DSA dsa = certWithPrivateKey.GetDSAPrivateKey())
{
byte[] signature = dsa.SignData(Array.Empty<byte>(), hashAlgorithm);
Assert.True(dsaCsp.VerifyData(Array.Empty<byte>(), signature, hashAlgorithm));
}
(来自https://github.com/dotnet/runtime/blob/4f9ae42d861fcb4be2fcd5d3d55d5f227d30e723/src/libraries/System.Security.Cryptography.X509Certificates/tests/CertificateCreation/PrivateKeyAssociationTests.cs#L276-L295的sn-p)