PuTTY bug eddsa-overlarge-s

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

summary: EdDSA verification accepts signatures with overlarge value of s
class: bug: This is clearly an actual problem we want fixed.
absent-in: 0.67
present-in: 0.68
fixed-in: af996b5ec27ab79bae3882071b9d6acf16044549

PuTTY's EdDSA signature verification (used for Ed25519 and Ed448 keys) accepts signatures whose value of s is out of range. According to RFC 8032, it should reject values of s greater than or equal to the order of the curve's base point. Instead, PuTTY reduces large values of s modulo that order.

This causes a property known as "signature malleability": given a valid signature for a message, an attacker can modify it into a different signature which is still accepted. But it doesn't allow an attacker to create a signature on any data for which it did not already have a valid signature from the same key.

RFC 8032 says that "some systems" depend on the absence of signature malleability (also known as "strong unforgeability"), and would consider it to be a security vulnerability. However, RFC 8032 is more general than just SSH, and does not say which systems do depend on strong unforgeability.

This issue was reported to us by email in February 2026, and in March 2026, was disclosed in the manner of a vulnerability, via a Github repository describing itself as a proof of concept. However, with respect to the reporter, in the context of an SSH client in particular, we don't believe this is a vulnerability.

PuTTY verifies Ed25519 signatures in two contexts:

1. Verifying the server's signature during key exchange. In the initial key exchange, the signature is sent in clear, so an attacker on the wire could modify it into an equivalent non-canonical form. However the bits of that signature are not used in any further part of the SSH protocol: in particular, they are not used as input to any hash or MAC for the following encrypted session. So modifying the network traffic in this way makes no difference to the rest of the session.

2. Verifying a CA signature on a host key certified using the OpenSSH certificate system. Again, during the initial key exchange, an on-path attacker could modify the certificate to change the CA's signature into an equivalent non-canonical form. An effect would be to change the fingerprint of the certified host key; one could imagine a nuisance-level DoS attack resulting from this, if you managed to poison someone's host key cache so that they distrusted the true key. But the entire certified host key is also fed into the key exchange hash, so another effect would be to prevent the server's signature on that hash (which would have used the true version of the certificate) from validating. And PuTTY checks that the signature is valid before checking the host key against its cache or prompting the user about it. So the user would never see the modified key fingerprint in the first place: they would get a message about signature validation failure first.

Following links from the above Github issue suggests that this report was related to a paper "The Provable Security of Ed25519: Theory and Practice". That paper seems to say on page 3 that there is a real threat to SSH from Ed25519 signature malleability (my emphasis):

In 2014, SSH was proven to be secure even when the same signing key is used across multiple ciphersuites, assuming that the underlying signature is strongly unforgeable. However, SSH implementations may use the originally-proposed version Ed25519-Original, which does not satisfy SUF-CMA. This yields a counterexample in their security model: mauling a signature in an otherwise honest session allows a session-key reveal on the peer, as the sessions no longer match. Thus, their proof does not apply as-is to SSH implementations that use Ed25519-Original.
The 2014 security proof referred to is "Multi-ciphersuite security of the Secure Shell (SSH) protocol".

That looks as if it's saying that signature malleability can be converted into an exposure of the session key. But read more carefully, it's only saying this in the context of the security model used by the 2014 proof. That is, it causes the proof to be invalid (as the final sentence of that snippet also says – "does not apply as-is"). But a hole in a proof does not imply the result is untrue – often it merely implies that something remains to be proved by another method.


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 2026-03-12 13:23:30 +0000)