PuTTY bug diffie-hellman-range-check

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Missing range check in Diffie-Hellman key exchange
class: bug: This is clearly an actual problem we want fixed.
difficulty: fun: Just needs tuits, and not many of them.
priority: high: This should be fixed in the next release.
present-in: 0.63
fixed-in: 0.64 174476813f0ed94337aecc3e2d13a202a1dc2fa8

PuTTY 0.63 and earlier versions implement Diffie-Hellman key exchange without checking that the value sent by the server is within the range [1,p-1]. This range check is required by section 8 of RFC 4253.

PuTTY 0.64 does fix this. In fact, it enforces the slightly smaller range [2,p-2], since values 1 and p-1 are also worthless for secure Diffie-Hellman.

Thanks to Matta Security for reporting this bug.

Matta considers this to be a security vulnerability, on the grounds that a Diffie-Hellman value of zero (for example) sent by the server, if not rejected by the client, would constitute a weak key and permit even a passive eavesdropper to read the session traffic. Matta has assigned this issue the id "MATTA-2015-002"; we were given this URL for the forthcoming advisory, but as of the time of writing it has not yet appeared.

With respect to Matta, we do not classify this as a vulnerability: a server sending a value of zero on purpose could just as easily expose the session traffic by other methods anyway (e.g. simply sending a copy of the traffic to whoever it wanted to), and given the range of values from which Diffie-Hellman keys are selected, a server sending the value zero by accident would happen with probability far, far lower than a spontaneous collision in a secure hash function, so if spontaneous hash collision is not considered a vulnerability then neither should this be.


If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2016-12-27 11:40:22 +0000)