4 ms·

The CPU of the Raspberry Pi 4 is the only 64-bit ARM chip I've ever seen that doesn't include native AES instructions. As a result, it's much lower performance

• my123 7y ago
  They are a recommended extension. I expect that the crypto instructions are not present on the RPi3/4 because of legal reasons, to allow it to be exported to Iran and such...
• fulafel 7y ago
  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 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/f05d3017dfb05a4ccb0def010bb2c91a https://gist.github.com/HimaJyun/f05d3017dfb05a4ccb0def010bb... - indicates 50-80 MB/s = 400-640 Mbps per core.
  • kohtatsu 7y ago
    That doesn't solve disk encryption, and it's primarily about efficiency for a lot of cases.
    • fulafel 7y ago
      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.
  • atanasi 7y ago
    I have heard that AES is very complicated to implement in software, if one intends to avoid side-channel leaks.
    • bjoli 7y ago
      You don't, especially not GCM mode. You use one of the mature tested versions out there.
      • bjoli 7y ago
        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.
  • wolf550e 7y ago
    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.
    • fulafel 7y ago
      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/asm/vpaes-armv8.pl 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/asm 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...
      • wolf550e 7y ago
        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 https://github.com/RustCrypto/block-ciphers/issues/65).
  • asveikau 7y ago
    I use geli for full disk encryption on FreeBSD.. If you do not load the kernel model "aesni" it is intolerably slow.
• MikusR 7y ago
  Syncthing hashing performance of Rock64 (that has crypto extensions) is ten times that of Raspberry pi 4.