Rapid Web Application Server in Assembler
2ton.com.au
2ton.com.au
From the linked page:
> TLS Blacklist
> To prevent padding oracle and other timing side-channel attacks, the HeavyThing library employs a TLS blacklist feature. When a decryption error occurs, by default the offending source IP address is added to a blacklist such that no further connections will be accepted for a period of a full 24 hours. Please note that the blacklist is not shared or synchronized between multiple rwasa processes, so what this really means is that -cpu worth of connections will be accepted at most per 24 hour period. Even if this setting is disabled, special care is taken such that no timing information is leaked during MAC failures. During the course of normal operations, decrypt errors do not (and should not) occur so if everyone plays nice with rwasa this setting goes largely unnoticed. It is our opinion that this strategy of automatically blacklisting clients who are tampering is an effective server-side mitigation technique.
They try to deal with timing attacks using IP address blacklisting. This piece of software is unlikely to be secure, if that's all of the timing channel mitigation they've done! "... special care is taken such that no timing information is leaked during MAC failures." suggests they're doing "something".
There are also other side channel attacks. Like cache timing related attacks when in a shared or virtualized environments. In this scenario, attacker's code would be running on same physical server and deducing private keys out of side channel leaks.
The best way is to have algorithms that perform constant work and take constant time for public key cryptography. Even if it costs performance. Unless you want to leak your keys in unexpected ways.
First, lets start with: All of the library and showcase pieces are WAN material. If you bothered to look, you would have noticed that all of the necessary blinding is performed for all cryptographic operations as received, thus even for LAN access, thanks to blinding as widely accepted mitigation strategy, no timing information is leaked.
Second, if you bothered to actually peruse the implementation, you would have noticed that when it receives a bad HMAC, instead of reporting that differently to the would-be attacker, it randomizes the expected packet length, thereby rendering timing information based solely on the TLS and/or SSH state mechanism useless.
Third, padding related issues are treated the same, such that no attacker-perspective notifications are broadcast.
Fourth, the TLS Blacklist feature I added was only an additional, and IMO decent server-side mitigation technique insofar as during normal operations, decrypt operations do not fail, and if they do, why give an attacker the opportunity to perform 32M+ tests against my implementation?
In any case, as mentioned specifically on my rwasa page, I left the TLS Blacklist feature disabled for my own website due to the ssllabs.com security scans being incorrect if it is enabled.
In summary, my speed increases are not due to shortcutting security protocols or best practices, but the fact that my modular exponentiation routines in x86_64 assembler are indeed faster.
Please send me my private key to 2ton.com.au and I will take the whole lot down immediately.