Optimized crypto? Let the side channel attacks commence. Leak your private keys in no time. Unless, of course, these operations are constant time. And don't leak information through other side channels either, like memory cache. Mitigation for side channel attacks is the reason why established SSL/TLS libraries are slower than optimal.
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.
I was just badly berated by a colleague of mine for not providing a more technical response. My argument to him stands IMO, that your understanding of what constitutes a valid side channel attack is fundamentally flawed in any case.
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.
I don't know what the quality of this particular implementation is, but it's certainly easier in principle to write constant time algorithms in assembly than higher level languages (where the optimizer will transform your code in semi-unpredictable ways).
No surprise, but no one has handed me my private keys. An interesting aside is that my library also happens to provide an excellent framework for performing timing attacks. It is intentionally easy to walk through, and I encourage anyone with constructive actual criticism of my implementation to step up.
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.