【Hacker News搬运】PuTTY漏洞vuln-521-bias

[hackernews]

Title: PuTTY vulnerability vuln-p521-bias

PuTTY漏洞vuln-521-bias

Text:

hn link

Url: https://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/vuln-p521-bias.html

PuTTY漏洞vuln-p521-bias分析

标题：PuTTY NIST P521私钥漏洞
作者：未提供
发布日期：未提供
顶部图片链接：无
文本内容：

主页
 |
常见问题
 |
反馈
 |
许可
 |
更新
 |
镜像
 |
密钥
 |
链接
 |
团队
下载：
稳定版
 ·
快照
 |
文档
 |
变更
 |
愿望清单
概要：NIST P521私钥在签名生成过程中暴露
类别：安全漏洞
优先级：高
版本缺失：0.67
版本包含：0.68 0.69 0.70 0.71 0.72 0.73 0.74 0.75 0.76 0.77 0.78 0.79 0.80
版本修复：c193fe9848f50a88a4089aac647fecc31ae96d27 (0.81)
PuTTY工具的每个版本从0.68到0.80 inclusive在生成使用NIST P521曲线的ECDSA私钥签名的代码中都有一个严重的安全漏洞。
(PuTTY或Pageant在生成签名时使用私钥对SSH服务器进行身份验证。)
这个漏洞已经分配了CVE-2024-31497。
它是由Ruhr University Bochum的Fabian Bäumer和Marcus Brinkmann发现的；请参阅他们在oss-security邮件列表上的描述。
坏消息：漏洞的效果是暴露私钥。拥有几十个已签名消息和公钥的信息足以恢复私钥，然后允许他们伪造签名，好像它们来自你，从而允许他们登录到你使用的任何服务器。为了获得这些签名，攻击者只需短暂地妥协你用于身份验证的任何服务器，或者暂时获得Windows Pageant中持有的密钥的访问权限。
(然而，这些签名不为SSH连接的被动监听者暴露。)
因此，如果您有这种类型的密钥，我们建议您立即撤销它：从所有OpenSSH authorized_keys文件中删除旧的公钥，以及在其他SSH服务器中的等效项，这样签名就不会有任何价值了。然后生成一个新的密钥对来替换它。
(问题不在于密钥最初是如何生成的；它无论来自PuTTYgen还是其他地方都无关紧要。重要的是它是否曾经用于PuTTY或Pageant。)
好消息：唯一受影响的密钥类型是521位ECDSA。
也就是说，在Windows PuTTYgen中以ecdsa-sha2-nistp521开头显示在'Key fingerprint'框中的密钥，或者在Windows Pageant中描述为'NIST p521'的密钥，或者在SSH协议或密钥文件中以ecdsa-sha2-nistp521开头的id。其他大小的ECDSA和 其他密钥算法均不受影响。特别是，Ed25519不受影响。
错误详情：
所有DSA签名方案在签名过程中都需要发明一个随机值，称为'nonce'（密码学用语，表示只使用一次的值），或有时用字母k表示。众所周知，如果攻击者可以猜测您使用的k值，或者找到您生成的两个具有相同k值的签名，那么他们可以立即恢复您的私钥。
这意味着在没有任何高质量随机数源的系统上生成DSA签名是非常危险的。与为单个会话生成加密密钥相比，私钥泄露的风险要大得多：私钥的泄露 compromises far more than one SSH session.
出于这个原因，自从PuTTY在Windows上开发以来，在它具有任何密码随机数生成器之前，PuTTY一直使用确定性方法生成它的k，从而避免了所有随机数的需求。这个巧妙的方法是计算一个安全哈希，其输入包括要签名的消息以及私钥。安全哈希输出与随机数据不可区分（否则哈希函数就没有完成其工作），并且这种生成方法不能被试图找到私钥的攻击者重复 – 如果他们能够生成与您相同的哈希输入，那么他们 already have the private key.
这种技术现在已经被广泛采用，RFC 6979文档描述了一种特定的已知方法。但PuTTY没有遵循该规范，因为我们早在2001年就开始这样做，而RFC直到2013年才发布。
Pu

Post by: aardvark179

Comments:

tptacek: This is one of the all-time cryptography footguns, an absolutely perfect example of how systems development intuition fails in cryptography engineering.<p>The problem here is the distinction between an n-bit random number and n-bit modulus. In DSA, if you're working with a 521-bit modulus, and you need a random k value for it, k needs to be random across all 521-bits.<p>Systems programming intuition tells you that a 512-bit random number is, to within mind-boggling tolerances, as unguessable as a 521-bit random number. But that's not the point. A 512 bit modulus leaves 9 zero bits, which are legible to cryptanalysis as bias. In the DSA/ECDSA equation, this reduces through linear algebra to the Hidden Number Problem, solvable over some number of sample signatures for the private key using CVP.<p><i>Later</i><p>Here you go, from Sean Devlin's Cryptopals Set 8:<p><a href="https://cryptopals.com/sets/8/challenges/62.txt" rel="nofollow">https://cryptopals.com/sets/8/challenges/62.txt</a>

tptacek: 这是有史以来密码学的一大亮点，是密码学工程中系统开发直觉如何失败的一个绝对完美的例子。<p>这里的问题是n位随机数和n位模之间的区别。在DSA中，如果您；我们使用521位的模数，需要一个随机的k值，k需要在所有521位中是随机的<p> 系统编程直觉告诉你，一个512位的随机数，在心智的承受能力范围内，和一个521位的随机数字一样是不可测的。但是；这不是重点。512位模数留下9个零位，这些零位对于密码分析来说是可识别的。在DSATM中；ECDSA方程，这通过线性代数简化为隐藏数问题，可以使用CVP在一定数量的私钥样本签名上求解<p> <i>稍后</i><p>给你，来自Sean Devlin；s Cryptopals集8:<p><a href=“https://；&#x2F；Cryptopals.com&#x2F！集&#x2F：8&#x2F，challenges&#x20F；62.txt”rel=“nofollow”>https://&#x2F；cryptopals.com；集合；8；挑战；62.txt</a>

MaxBarraclough: I don't have a substantive comment to offer, but good on Simon Tatham for the clear and forthcoming write-up. No damage-control lawyerly BS, no 'ego', just the facts about the issue.<p>It's reassuring to see a solid disclosure after a security issue, and we too often see half-truths and deceptive downplaying, e.g. LastPass.

MaxBarraclough: 我不；我没有实质性的评论，但西蒙·塔塔姆的清晰和即将发表的评论很好。无损害控制律师BS，无；自我；，只是关于这个问题的事实<p> 它；在安全问题之后看到可靠的披露是令人放心的，我们经常看到半真半假和欺骗性的淡化，例如LastPass。

e79: I did a bit of a deep dive into this, in case anyone is interested. I think reading the code is a great way to understand why this vulnerability happened:<p><a href="https://ericrafaloff.com/your-putty-generated-nist-p-521-client-keys-are-compromised/" rel="nofollow">https://ericrafaloff.com/your-putty-generated-nist-p-521-cli...</a>

e79: 我对此做了一点深入研究，以防有人感兴趣。我认为阅读代码是了解_why_发生此漏洞的好方法：<p><a href=“https://；&#x2F；ericrafaloff.com&#x2F：your-putty-generated-nist-p-521-client-keys-are-compromised&#x2F”rel=“nofollow”>https://&#x2F；ericrafaloff；你的推特生成的nist-p-521-cli</一

metadat: I wish this announcement included the backstory of how someone discovered this vulnerability.<p>Public keys are enough of a pain in the ass with PuTTY / KiTTY that I stick with password auth for my windows SSH'ing needs.<p>KiTTY even let's you save the passwords so you don't have to type it in, a horrible security practice no doubt, but so convenient... Perhaps more secure than the putty-gen'd ECDSA P521 keys? A tad bit ironic.

metadat: 我希望这份公告包括某人如何发现这个漏洞的背景故事<p> 公钥对于PuTTY/F来说已经够痛苦的了；KiTTY，我坚持使用我的windows SSH的密码验证；ing需求<p> KiTTY甚至让；你保存密码了吗；不用输入，这无疑是一种可怕的安全做法，但非常方便。。。也许比油灰gen；d ECDSA P521钥匙？有点讽刺。

londons_explore: So this signing method requires a 521 bit random number, and this flaw caused the top 9 bits of that number to be zero instead, and somehow after 60 signatures this leaks the private key?<p>Anyone care to explain how exactly? How it it any different to the top 9 bits being zero by chance (which happens in 1 out of ~500 attempts anyway)

londons_explore: 所以这个签名方法需要一个521位的随机数，而这个缺陷导致该数字的前9位为零，不知何故，在60个签名之后，这会泄露私钥<p> 有人想解释一下具体是怎么回事吗？它与前9位偶然为零有什么不同（无论如何，大约500次尝试中有1次会发生这种情况）