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 cons

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.