
Rapid Web Application Server in Assembler - franklyjeremy
https://2ton.com.au/rwasa/
======
vardump
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.

~~~
2ton_jeff
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.

------
2ton_jeff
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.

------
pjmlp
While it might feel the "it looks cool" projects, I hope no one is plugging
such servers into a network, other than on micro-controlers.

