刚刚听到一个播客说小SSL的SSL密钥大小。
他们说，你应该尽可能地使用一把钥匙，而不是真的说应该避免使用哪种钥匙。
所以问题是有一个推荐的最小密钥大小？
较大的模数大小可以防御蛮力企图通过只有公钥的攻击者重build私钥。 更多的位是更多的变化来检查，但在实践中，即使“小”的密钥大小是很难尝试攻击。
至于具体的规模，一个512位的密钥在这一点上被认为是非常不安全的，因为他们已经被certificate在几个月的时间里有足够的计算资源是可以破解的。 1024位密钥仍然有些遥不可及，但是预计在未来5年内这些密钥会变得易碎（由拥有大量计算资源的人员）。 在量子计算机变得可行之前，2048位密钥可能是不可接触的，在这一点上，使用公钥密码系统的东西几乎都在窗外。
除了密钥对的直接安全性以外，用于签名的散列algorithm还存在其他弱点。 此时MD5被彻底打破，任何使用MD5签署证书的authentication机构都容易受到冲突攻击。 几年前，一个团队创build了一个stream氓证书颁发机构，这个证书颁发机构通过将其MD5哈希与其中一个受信任的根提供者签署的合法证书进行匹配来certificate这一点。
哦，还有其他方面的诸多问题，包括像SSL v2这样的不安全的实现，像重新协商攻击这样的规范的弱点，以及由于传统客户端在大多数Web服务器上仍然启用的弱密码。 所有这些方面都必须考虑到您的SSL安全考虑。
对于密钥大小，虽然; 没有理由不使用大的。 与使用更大的密钥相关的成本是微不足道的（额外的计算时间来validation证书）。
刚刚听到一个播客说小SSL的SSL密钥大小。
Ehmn，没有。 SSL（今天大概意味着TLS 1.0或更高版本 ）不会被打破。
已知RSA密钥交换 在使用较小密钥（768位或更低）时有缺陷 。 这通常通过增encryption钥大小来缓解。
所以问题是有一个推荐的最小密钥大小？
是。 NIST特刊800-57build议从2011年到2030年2048位（表4） 。 这篇博文提供了一个快速的概述 。
所以，如果你想要一个官方的build议，这是2048位。 但是想想你正在保护什么以及你的风险状况如何。 例如，如果您只是保护用户login状态（认为login到社交networking的用户，并且需要他的login保持安全，但所提供的实际信息是公开的），则可以使用1024位或1536位RSA关键也许是一个不错的select。 在Security.Stackexchange上查看关于密钥大小和CPU使用权衡的一些合格意见的讨论 – 在这里和这里 。
听起来是着名的Debian SSL Bug 。 虽然这个bug是Debian Specific，但据我所知，所有较小的密钥都是无用的。
我现在没有链接，但在我看来，至less有2048位的密钥大小。 对于一些额外的信息：当证书有md5作为散列algorithm的时候，很多工具都会中断 – 我之前碰到了这个问题，花了一段时间才弄清楚，因为证书和密钥本身是完全没问题的
我喜欢布鲁斯·施奈尔（Bruce Schneier）所说的：“密码学就是安全边际。 关键尺寸越大，安全裕度越大（性能越高）。 一个512位的密钥可能是好的 ，但可能不会很长。 正如沙恩·马登（Shane Madden）提到的那样，有充分的证据表明，在几个月内可以通过协同攻击来打破这种局面。 如果这对你来说足够安全，那么你不需要马上replace它们。 1024位密钥可能在旁边。
因此，如果您已经购买了使用这些密钥大小的数字证书，并且您没有保护重要的公司/核保密信息，那么短期内您可能就可以使用了，但是您将要购买未来更大密钥的SSL证书。 你有足够的安全余地吗？ 这是值得的性能打击？ 谁会攻击你的密码系统？ 一个小小的威胁分析是有利的A）确定你是否需要做一些正确的事情和B）覆盖你的屁股，以防发生什么事情。
在RSA密码系统中应该使用多大的密钥？
至于由增encryption钥大小（见问题3.1.2）造成的减速，模数长度加倍平均将公共密钥操作（encryption和签名validation）所需的时间增加四倍，并增加私钥操作（解密和签名）所花的时间缩短了八倍。
至于在真实世界中的性能损失将如何，这真的取决于您的应用程序和实现。 它可能会增加四分之一的时间，只有四分之一秒，也可能是四秒。 testing在这里很重要。
看起来在这一点上，NIST（ SP800-131A ）只考虑了2011年至2014年之后的RSA和DSA 2048密钥大小是可接受的，并且它们必须具有至less112位的安全强度。 有关更多信息，请参阅数字证书上的SP800-131A部分。
在我看来，这一切归结为：你的安全余量是512位密钥“小”，1024位密钥“不错”，2048位密钥“相当不错”。 做一些威胁分析，并决定你的组织的安全裕度需要多大，你保护的是什么types的数据，以及如果保护它的密码系统被破坏，你将会失去什么。 确保考虑现有的政策，以及您需要遵守的任何法律要求。