AES-based encryption feasible?

[Atemu]

This is more of a question than an issue.

Bcachefs currently uses ChaCha-based encryption which is good for devices without AES acceleration like smartphones and other low power devices.

In systems that do have an AES accelerator (which is pretty much any amd64 CPU of the past decade), AES is faster but ChaCha is not far behind in high-end systems.

Another system type to consider is low end CPUs that lack 256bit SIMD instructions such as those used in many home NAS systems. ChaCha20 seems to be about half as fast with 128b SIMD (SSE2) vs 256b (AVX2).

Considering that an encrypted NAS system is going to be a common use-case for bcachefs, ChaCha could be a major bottleneck. Especially since those NAS CPUs are generally quite slow. (AES is still quick; on the order of GiB/s because of AES_NI.)

Is it feasible to add AES-based encryption later without an enormous effort and/or format changes?

I know that there are many reasons for ChaCha outside of performance but bcachefs might simply end up not working out well for many users because of it.

[YellowOnion]

bcachefs just uses the kernel crypto libraries, and looking at the code, I think it's pretty easy to change (I'm no expert) Kent made some comments on the website about adding other algorithmns later, and the on disk format should support it pretty easily.

The other thing worth noting is that AES-XTS is probably the format we want to use, and it's quite a bit slower than other non-disk modes.

[Atemu]

That's good to hear!

The other thing worth noting is that AES-XTS is probably the format we want to use, and it's quite a bit slower than other non-disk modes.

According to cryptsetup's benchmark and botan, AES-XTS is still about an order of magnitude faster than chacha20 on my Celeron J4105.

[Atemu]

@koverstreet said the following in his bcachefs update yesterday:

- Encryption: people keep wanting AES support, so at some point I'll try and find the time to add AES/GCM.

Thank you!

[DemiMarie]

The other thing worth noting is that AES-XTS is probably the format we want to use, and it's quite a bit slower than other non-disk modes.

bcachefs uses AEAD (Authenticated Encryption with Associated Data) ciphers, so AES-XTS isn’t suitable.

[mrnerdhair]

Something I haven't seen addressed yet is that ChaCha20 is a stream cipher, while AES is a block cipher. This means that to use AES, padding must be used to bring ciphertexts which aren't multiples of 16 bytes up to the block size, which in general means that you have to be prepared for your plaintext and ciphertext to be of different lengths. (There are modes of operation like AES-CTR that can turn AES into a stream cipher and make padding irrelevant, but they aren't AEAD.)

I'm not familiar enough (yet) with bcachefs's architecture myself to know if this makes an impact, but I could imagine that being a significant headache down the road under the wrong circumstances.

[DemiMarie]

@mrnerdhair This is not an issue for bcachefs because AES-GCM exists, which is practically a drop-in replacement for ChaCha20-Poly1305.

[mrnerdhair]

@mrnerdhair This is not an issue for bcachefs because AES-GCM exists, which is practically a drop-in replacement for ChaCha20-Poly1305.

AES-GCM is a block cipher, not a stream cipher, so it's not in general a drop-in replacement. It might be under special circumstances, but I don't know if bcachefs has those special circumstances.

[DemiMarie]

@mrnerdhair This is not an issue for bcachefs because AES-GCM exists, which is practically a drop-in replacement for ChaCha20-Poly1305.

AES-GCM is a block cipher, not a stream cipher, so it's not in general a drop-in replacement. It might be under special circumstances, but I don't know if bcachefs has those special circumstances.

AES-GCM uses counter mode internally.