Which crate to use for aes?

I want to use AES encryption for client stored session data but im not sure which implementation to start with
I checked OpenSSL and PGP
OpenSSL is dynamically linked which means I might run into problems on different environments with different versions of OpenSSL so I don't want to use it.
PGP is pure rust so no version issues but the problem with PGP is that it is huge.
It has so many things I don't need.
Is there any pure rust battle-tested AES implementation?

2 Likes

There's a quite a number of crates that implement AES in some form. Check out ring for the most Rusty one.

Note that you can't have pure-Rust crypto algorithms without risk of side-channel vulnerabilities, because Rust compiler can't guarantee constant time of operations.

3 Likes

What do you think about bincode_aes

1 Like

Why is it that rustc can't do this, but (presumably) gcc/llvm can?
I make the presumption because otherwise it wouldn't be possible write such code in C/C++ either (which is obviously false).

GCC and LLVM can't. C doesn't have any constant-time guarantees either. The options are:

  • Use AES-NI instruction on x86.
  • Accept you'll have side channel vulnerabilities and don't use the crypto code on any system that runs untrusted code (to be fair, given never-ending stream of Intel CPU side channel vulnerabilities, that's probably wise anyway)
  • Try to write code that happens to optimize to constant-time code you want, or carefully obfuscate the code to break optimizations you don't want. But you don't have a guarantee that a different version, different platform, or different settings won't cause the code to be optimized in a way that breaks algorithm's timing.
4 Likes

I would definitely use the crate aes-gcm. it is very good, and is developed by the RustCrypto group, which also have a number of other good encryption algorithms.

2 Likes

Just to be clear, as your post might give the impression that this is just a high-level language problem: 100% strict constant-time guarantees cannot be provided by any software implementation of AES, even one that's written in x86 assembly.

Ignoring all the recent scandals about CPU speculation vulnerabilities, a more fundamental reason is that one central component of AES is an u8 -> u8 lookup table (aka "8-bit S-box"). And that component is fundamentally vulnerable to (very slow) cache timing attacks when implemented on a caching CPU whose cache line size is smaller than 256 bytes and which doesn't allow locking a certain set of cache lines in place... which is true of all modern CPUs.

The only way to make an S-box (or any other kind of crypto-critical table lookup really) 100% guaranteed constant-time is to implement it as an ASIC that stores the lookup table data in its own private memory chip with no risk of cache invalidation. Which is one of the things that hardware implementations of AES like AES-NI are expected to do.


(Of course, an obvious problem with hardware crypto is that it seems purpose-built for enabling the creation of hardware backdoors, since it provides your black-box proprietary CPU with the super-precious metadata that a certain piece of information is a crypto key.

But unless you're into some shady business, it is probably a reasonable stance to be more worried about random code running on a neighbouring CPU core on your favorite cloud provider than about what the NSA and whoever else does intelligence business with Intel are going to do with your key.)

9 Likes

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.