Home

FAQ

Feedback

Licence

Updates

Mirrors

Keys

Links

Team
Download:
Stable
·
Snapshot

Docs

Changes

Wishlist
In sidechannels, we rewrote most of the PuTTY cryptography code to eliminate timing and cache side channels (as far as our own test suite can determine). This rewrite covered all the crypto that PuTTY itself performs during a network connection (with the exception of the Blowfish and Arcfour ciphers, which are both below our current securitywarning threshold).
However, it did not cover PuTTYgen's key generation code in full – partly because we didn't know how, and also because it seemed less critical given that key generation is done offline and can't be timed by the other party in a network connection.
Keypair generation for discretelog publickey systems (i.e. any of the DSA family, integer or ellipticcurve) became sidechannel safe automatically when we rewrote the underlying primitives, because in those cryptosystems, the private key is a random integer and the public key is derived from it by an exponentiation. And both the operations of inventing a random integer and exponentiation are covered by the previous rewrite.
But RSA key generation is based on inventing primes and keeping them secret, and at the time, we were not aware of any technique for doing that in a way that kept the primes secret even from sidechannel attacks on the same machine.
(Integer DSA also requires inventing primes, but in DSA, the primes are not secret: they're published as part of the public key, and it's even safe to reuse them between different people's public keys.)
This is now fixed: if you're using PuTTYgen's default probabilistic prime generation, then even if hostile code on the same machine can somehow collect timing traces from PuTTYgen or examine its effects on the cache, those traces should not reveal the prime factors of the RSA key.
This does not affect the nondefault provable prime generation, however. RSA key generation with the provableprime option will still have variable timing depending on the primes chosen. We still don't know of a reliable way to make that safe.