Hacker News Reader

Comment by fulafel | Hacker News Reader

AES is quite efficient in software. The RPi4 should be able to saturate its network connectivity many times over with SW AES.

A Pentium II 200 MHz could saturate 100 Mbps with AES-128[1], RPi4 has 4 x 1400 MHz cores (with 64-bit ALU & NEON available).

[1] https://www.di.ens.fr/~granboul/recherche/AES/timings.html

edit: There are RPi4 AES and other benchmarks here in this "openssl speed" paste: https://gist.github.com/HimaJyun/f05d3017dfb05a4ccb0def010bb... - indicates 50-80 MB/s = 400-640 Mbps per core.

View on HN

Fast table based software AES implementations leak bits of the secret key in array offsets, so anything that can use the cache on the chip can get the key. A software implementation of AES that is secure against side channel attacks by using bitslicing is slow, you would be better off using chacha20-poly1305.

So you're saying OpenSSL might still be using side channel vulnerable AES code, all these years after there was a big row about it?

This ARMv8 impl according to comments is constant time: https://github.com/openssl/openssl/blob/master/crypto/aes/as...

There are also other ARM AES implementations in the tree: https://github.com/openssl/openssl/tree/master/crypto/aes/as...

AFAICT one is for the hardware AES instructions, and one is a bitsliced (so constant time) impl for 32-bit ARMv7, and one is for low end ARMv4. The latter sounds like it might still be vulnerable to timing sidechannel attacks but no idea if it is still used by default in any configuration...

I don't know about openssl's status on old / weak platforms. People who need AES without hardware AES instructions should be using BearSSL code or the rust code that has been reviewed by the author of BearSSL (see e.g. https://github.com/RustCrypto/block-ciphers/issues/65).

I have heard that AES is very complicated to implement in software, if one intends to avoid side-channel leaks.

You don't, especially not GCM mode. You use one of the mature tested versions out there.

To build on this: I was able to implement AES and OCB mode by just reading papers without any code in them. I was, however, not able to implement GCM reliably even by translating a "simple" reference C implementation into scheme. Sure, it worked, but even after 2 rewrites it still did not produce the same output as the simple reference implementation for some edge cases.

All this was done on a just-for-fun basis, but it ended up just making me frustrated so I stopped trying.

I use geli for full disk encryption on FreeBSD.. If you do not load the kernel model "aesni" it is intolerably slow.

That doesn't solve disk encryption, and it's primarily about efficiency for a lot of cases.

Scenarios where the data read/written from disk is not going over the network and needs is be processed locally at the RPi at faster data rates than these exist but they are a small minority.

Reply on news.ycombinator.com