DSACryptoServiceProvider 有什么问题？

Question

该文档明确建议不要使用DSACryptoServiceProvider

可以使用更新的非对称算法。考虑使用 RSACryptoServiceProvider 类而不是 DSACryptoServiceProvider 类。仅使用 DSACryptoServiceProvider 来兼容旧应用程序和数据。

DSA 出了什么问题？是否只是密钥大小 1024 和 SHA-1 哈希算法由于某种原因无法在此特定实现中进行交换，或者是否有一些普遍共识认为不应再使用 DSA？为什么？我猜离散对数问题还没有得到有效解决，是吗？

Answer 1

是否只是密钥大小 1024 和 SHA-1 哈希算法由于某种原因无法在此特定实现中进行交换有点。有两种名为 DSA（或 DSS，如果您愿意）的竞争算法。第一个在 FIPS 186-1 和 FIPS 186-2 中描述，适用于 512 到 1024 位的密钥，步长为 64 位，并且需要 SHA-1。第二种，在 FIPS 186-3 及更新版本中描述，适用于大小为 1024、2048 和 3072 位的密钥，具有“批准的哈希函数”（基本上意味着 SHA-2 函数）。DSACryptoServiceProvider 使用 Windows CAPI，它只支持旧版本的 DSA。DSACng 使用 Windows CNG，它支持两个版本。因此 DSACryptoServiceProvider 无法升级（在 .NET 中，因为 Windows 表示 CAPI 仅供维护且已弃用）。DSA 总体上已经失宠。它比 RSA 和 ECDSA 慢，它比 RSA 具有更多“完美或损坏”状态，并且其密钥生成比 RSA 和 ECDSA 慢几个数量级。Windows 已决定他们不会、也“不会”支持使用 FIPS 186-3 DSA 签名的 X.509 证书……加密库只为那些被迫有效使用它的人提供它。（Apple Security.framework 不允许生成 DSA 密钥，并且无法验证 FIPS 186-3 签名，并且 Apple 不提供 DSA 证书）。