PuTTY semi-bug side-channels

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

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 the bignum-handling code (used in RSA, DSA, and elliptic curve algorithms)
• All the elliptic-curve code itself (the layer above the bignums)
• The AES and DES block ciphers.
• The CRC32 function that SSH-1 uses in place of a MAC.

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:

• The Chacha20-Poly1305 combined cipher and MAC.
• All the standalone hash functions: MD5, SHA-1, SHA-256, SHA-384, SHA-512.

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

• The Blowfish block cipher.
• The Arcfour (aka RC4) stream cipher.

This work also included creating some test suites:

• A functional test suite for crypto primitives and supporting libraries.
• A test suite that checks for side channels, based on DynamoRIO; see comments in testsc.c for details.