我目前正在更新SSL证书,并且正在考虑切换到椭圆曲线。 Per Bernstein和Lange,我知道不应使用某些曲线,但是在OpenSSL中选择正确的曲线时遇到了困难:

$ openssl ecparam -list_curves
  secp112r1 : SECG/WTLS curve over a 112 bit prime field
  secp112r2 : SECG curve over a 112 bit prime field
  secp128r1 : SECG curve over a 128 bit prime field
  secp128r2 : SECG curve over a 128 bit prime field
  secp160k1 : SECG curve over a 160 bit prime field
  secp160r1 : SECG curve over a 160 bit prime field
  secp160r2 : SECG/WTLS curve over a 160 bit prime field
  secp192k1 : SECG curve over a 192 bit prime field
  secp224k1 : SECG curve over a 224 bit prime field
  secp224r1 : NIST/SECG curve over a 224 bit prime field
  secp256k1 : SECG curve over a 256 bit prime field
  secp384r1 : NIST/SECG curve over a 384 bit prime field
  secp521r1 : NIST/SECG curve over a 521 bit prime field
  prime192v1: NIST/X9.62/SECG curve over a 192 bit prime field
  prime192v2: X9.62 curve over a 192 bit prime field
  prime192v3: X9.62 curve over a 192 bit prime field
  prime239v1: X9.62 curve over a 239 bit prime field
  prime239v2: X9.62 curve over a 239 bit prime field
  prime239v3: X9.62 curve over a 239 bit prime field
  prime256v1: X9.62/SECG curve over a 256 bit prime field
  sect113r1 : SECG curve over a 113 bit binary field
  sect113r2 : SECG curve over a 113 bit binary field
  sect131r1 : SECG/WTLS curve over a 131 bit binary field
  sect131r2 : SECG curve over a 131 bit binary field
  sect163k1 : NIST/SECG/WTLS curve over a 163 bit binary field
  sect163r1 : SECG curve over a 163 bit binary field
  sect163r2 : NIST/SECG curve over a 163 bit binary field
  sect193r1 : SECG curve over a 193 bit binary field
  sect193r2 : SECG curve over a 193 bit binary field
  sect233k1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect233r1 : NIST/SECG/WTLS curve over a 233 bit binary field
  sect239k1 : SECG curve over a 239 bit binary field
  sect283k1 : NIST/SECG curve over a 283 bit binary field
  sect283r1 : NIST/SECG curve over a 283 bit binary field
  sect409k1 : NIST/SECG curve over a 409 bit binary field
  sect409r1 : NIST/SECG curve over a 409 bit binary field
  sect571k1 : NIST/SECG curve over a 571 bit binary field
  sect571r1 : NIST/SECG curve over a 571 bit binary field
  c2pnb163v1: X9.62 curve over a 163 bit binary field
  c2pnb163v2: X9.62 curve over a 163 bit binary field
  c2pnb163v3: X9.62 curve over a 163 bit binary field
  c2pnb176v1: X9.62 curve over a 176 bit binary field
  c2tnb191v1: X9.62 curve over a 191 bit binary field
  c2tnb191v2: X9.62 curve over a 191 bit binary field
  c2tnb191v3: X9.62 curve over a 191 bit binary field
  c2pnb208w1: X9.62 curve over a 208 bit binary field
  c2tnb239v1: X9.62 curve over a 239 bit binary field
  c2tnb239v2: X9.62 curve over a 239 bit binary field
  c2tnb239v3: X9.62 curve over a 239 bit binary field
  c2pnb272w1: X9.62 curve over a 272 bit binary field
  c2pnb304w1: X9.62 curve over a 304 bit binary field
  c2tnb359v1: X9.62 curve over a 359 bit binary field
  c2pnb368w1: X9.62 curve over a 368 bit binary field
  c2tnb431r1: X9.62 curve over a 431 bit binary field
  wap-wsg-idm-ecid-wtls1: WTLS curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls3: NIST/SECG/WTLS curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls4: SECG curve over a 113 bit binary field
  wap-wsg-idm-ecid-wtls5: X9.62 curve over a 163 bit binary field
  wap-wsg-idm-ecid-wtls6: SECG/WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls7: SECG/WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls8: WTLS curve over a 112 bit prime field
  wap-wsg-idm-ecid-wtls9: WTLS curve over a 160 bit prime field
  wap-wsg-idm-ecid-wtls10: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls11: NIST/SECG/WTLS curve over a 233 bit binary field
  wap-wsg-idm-ecid-wtls12: WTLS curvs over a 224 bit prime field
  Oakley-EC2N-3:
        IPSec/IKE/Oakley curve #3 over a 155 bit binary field.
        Not suitable for ECDSA.
        Questionable extension field!
  Oakley-EC2N-4:
        IPSec/IKE/Oakley curve #4 over a 185 bit binary field.
        Not suitable for ECDSA.
        Questionable extension field!


一种密码学家可以指出吗?对我来说,哪些曲线仍然被认为是安全的?

评论

NIST曲线是否不算冒险,因为据说NSA对这些有一些输入/影响?

您可以使用更大的素数生成自己的曲线,并将其与未修改的客户一起使用吗?我想如果您选择正确且足够大的素数,那将是最安全的。超过1024位(没有多余的东西)。您甚至可以使用与rsa相同大小的素数(例如4k或8k)吗?生成曲线显然会花费很长时间,但强行使用它会很困难+我怀疑有人为它们预先计算了值。

没有。人们以前认为让双方就曲线的参数达成一致,然后对由这些参数定义的自定义曲线执行操作是一个好主意。目前CFRG认为这是个坏主意。过度杀伤也是一个坏主意-人们在智能卡等上执行加密。生成指定大小的安全曲线的过程很复杂,专家只需执行几次即可。这就是Curve25519和Curve448的定义方式。软件可能会使用特定于这些曲线的汇编代码来获得边通道安全的快速实现。

#1 楼

您可能误解了Bernstein和Lange的建议(不可否认,他们的演讲带有令人恐惧的红色“ False”标签,有点令人误解)。它们的意思不是说某些曲线本质上是不安全的,而是某些曲线的安全实现要比其他曲线更容易(例如,关于库行为,当遇到某些可能是有效曲线点编码的东西时,却并非如此) )。

您真正想要的是一条曲线,使得:


您将私钥(您的SSL服务器)委托的软件已正确实施并且不会泄露有关您的私钥的详细信息;
将实现互操作性。

对于SSL服务器证书,“椭圆曲线”证书将仅与数字签名一起使用(ECDSA算法) 。服务器将仅对自己生成的消息进行签名;在任何情况下,ECDSA中涉及曲线的唯一“私有”操作是将常规基点(硬编码,因为它是曲线定义的一部分,因此是正确的)乘以服务器生成的随机值。因此,在您的用例中,不存在专用于所使用曲线的私钥泄漏风险。如果您的SSL实施不佳,那么对于所有曲线(而不只是其中的某些曲线)都将不佳。

“互操作性”表示,如果SSL客户端实际上可以连接到服务器,则您可能会更喜欢它。否则,拥有SSL服务器将毫无意义。这大大简化了这个问题:在实践中,普通客户仅支持两条曲线,即所谓的NSA Suite B中指定的曲线:它们是NIST曲线P-256和P-384(在OpenSSL中,它们被指定为分别是“ prime256v1”和“ secp384r1”)。如果您使用其他曲线,则某些广泛使用的Web浏览器(例如Internet Explorer,Firefox等)将无法与您的服务器通信。

使用P-256可以最大程度地减少麻烦。如果您认为使用256位曲线(可以使用384位曲线)会威胁到成年男子,请使用P-384:这会增加您的计算和网络成本(CPU的成本大约是3倍,一些额外的网络上的十个字节),但实际上这可以忽略不计(在使用SSL的Web服务器中,沉重的成本是“ Web”,而不是“ SSL”)。

评论


我的男子气概确实在受到威胁。非常感谢您的明确答复!

–执行
15年1月7日在18:09

与OP链接的站点明确将P-256和P-384列为不安全,并表示“安全地实现标准曲线在理论上是可能的,但是非常困难。”您的回答和该站点都让我迷失了细节,但是我想知道这是否意味着没有好的椭圆曲线SSL证书,我们应该完全避免使用它们吗?

–达伦·库克(Darren Cook)
15年1月13日在9:56

关键是,当站点将一条曲线列为“不安全”时,这意味着“可能存在某种涉及该曲线的协议,从而难以安全地实施它”。但是,这并不适用于曲线的所有用法。特别是,在X.509证书和SSL / TLS中,椭圆曲线以一种非常简单直接的方式使用,而这种风险不适用。

–托马斯·波宁(Thomas Pornin)
15年1月13日在11:25

@ThomasPornin但是,对于这两条曲线的刚度是否有些担心?此页面暗示“没有任何准备”原则尚未应用。

–执行
2015年2月1日9:08



“无所畏惧”原则(与心理学有关而不是对数学的重视)已得到部分应用,因为参数是使用完全指定的PRNG生成的-但从没有“合理”的种子开始。为了使这些曲线变弱,仍然必须假设一个迄今为止未知的攻击,这种攻击可能会破坏相当大比例的随机曲线。

–托马斯·波宁(Thomas Pornin)
2015年2月1日15:56

#2 楼

我会说要坚持secp521r1,甚至DJB都说P-521非常好用,并且每个现代加密货币库也都支持它。

同时,我们应推动采用非secp521r1。 NIST曲线(例如Curve25519)将是完全刚性的,不易出现实现错误,对于那些需要比secp521r1更快的解决方案的人来说,它可能是不错的选择。

评论


我爱我25519。希望它得到更广泛的接受和实施。

– Naftuli Kay
15年7月31日在18:36

@ naftuli-tzvi-kay在不久的将来,我们应该同时为TLS标准化Curve25519和Curve448(甚至更强大,也更安全,更有效)(请参阅IETF草案),我希望TLSv1.3实现将已经包括在内。

–麦恰(MichałStaruch)
2015年8月1日19:41

我不确定,但我认为他是在谈论E-521,而不是P-521。 (即safecurves.cr.yp.to中列出的那个)

–lapo
18-6-5在13:12



#3 楼

至少不要使用secp112r1,secp112r2,secp128r1,secp128r2,secp160k1,secp160r1,secp160r2,secp192k1曲线。根据NIST的建议,它们的尺寸对于安全性应用来说太小了!