PuTTY semi-bug side-channels

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 · Pre-release · Snapshot | Docs | Privacy | Changes | Wishlist

summary: Rewrite crypto code to avoid cache/timing side channels
class: semi-bug: This might or might not be a bug, depending on your precise definition of what a bug is.
difficulty: tricky: Needs many tuits.
fixed-in: 9cb8c4bcb78fd3388f10ed626e853a225c33faed (0.71)

Between the 0.70 and 0.71 releases, a great deal of PuTTY's cryptographic code has been substantially rewritten to try to eliminate cache and timing side channels.

This is often referred to as ‘constant-time’ coding – see for example BearSSL's page entitled ‘Constant-Time Crypto’. However, that's a misnomer: firstly, timing is not the only consideration (you also need to avoid leaving sensitive data in the cache state), and secondly you can't make your code run in actually constant time, because it can be sped up or slowed down by many factors outside your control such as thermal CPU throttling, prior states of caches and branch predictors, or straight-up system load. Fortunately, you don't actually need the time to be literally constant; you only need it to be independent of your secret data (keys and plaintexts). Some alternative phrase such as ‘secret-independence’ would be better.

Anyway, be that as it may, we've rewritten the following components of PuTTY in that style for 0.71:

All of the affected code will run more slowly as a result of this rewrite. We haven't done detailed benchmarking on the asymmetric crypto used only in key exchange, but SGT's measurements on the bulk encryption suggest a factor of 4.5 slowdown for DES, and about 2 for software AES in SDCTR mode. AES in CBC mode will be slower still, because CBC encryption can't be parallelised.

However, on modern hardware, the software AES implementation will typically not be used, because we've also provided hardware-accelerated implementations: see cpu-crypto-accel. So, in the usual case where you're running on a system with hardware AES acceleration available and connecting to a server that speaks AES, you should find that PuTTY 0.71's bulk encryption is faster overall than 0.70's.

The following components of PuTTY have not been rewritten, but testing suggested that they already had the required secret-independence properties:

Finally, the following components still have cache and timing side channels, because rewriting them would make them so slow as to be virtually useless:

In recognition of this, Blowfish has been demoted to below the ‘weak algorithm’ warning threshold in PuTTY's default configuration. Arcfour was already below that threshold.

This work also included creating some test suites:


If you want to comment on this web site, see the Feedback page.
Audit trail for this semi-bug.
(last revision of this bug record was at 2019-03-16 16:34:15 +0000)