RustCrypto Release Announcements

[bascule]

The RustCrypto Project has just completed another round of crate releases. We wanted to highlight some of the work we've been doing which has gone into this round of releases.

Symmetric Ciphers

Our project repos can be found at:

• AEADs: GitHub - RustCrypto/AEADs: Authenticated Encryption with Associated Data Algorithms: high-level encryption ciphers
• Block ciphers: https://github.com/RustCrypto/block-ciphers
• Stream ciphers: https://github.com/RustCrypto/stream-ciphers

Release highlights

Some crates to highlight from this release:

Traits

• aead v0.4: high-level authenticated encryption support
• cipher v0.3: low-level block and stream cipher traits

Ciphers

• aes v0.7: Advanced Encryption Standard (low-level crate)
• chacha20 v0.7: ChaCha20 family of ciphers (low-level crate)

AEADs

These are the recommended crates to use for end-user encryption applications:

• aes-gcm v0.9
• aes-gcm-siv v0.10
• chacha20poly1305 v0.8

CPU feature detection

We implement several symmetric cipher crates with SIMD backends, such as aes and chacha20, along with universal hash function crates like ghash, polyval, and poly1305. Before, in order to get optimum performance, you used to have to explicitly specify RUSTFLAGS with the correct -C target-features to activate the performance-oriented backends.

Not anymore: CPU features like AES-NI, AVX2, and CLMUL, are now automatically detected on i686/x86_64 CPUs. This means on these CPUs you should get optimal performance out of the box.

This applies to higher-level AEAD constructions like the aes-gcm and chacha20poly1305 crates as well.

Unified aes crate

Regarding the aes crate specifically: previously it served as a facade for the aesni and aes-soft crates. We have since combined all of these crates into the aes crate and will be retiring the aesni and aes-soft crates.

The aes crate will now autodetect AES-NI (and in the future, other CPU-specific instructions) and use it if available, and if it isn't, will fall back to a software implementation.

The force-soft feature can be used to always use the software implementation, avoiding CPU-specific instructions.

To force AES-NI all of the time, pass -C target-features=+aes in the RUSTFLAGS. This will assume AES-NI is always available, and will crash with an invalid instruction if it is disabled.

AEAD streaming

A common question we get with AEAD ciphers like aes-gcm and chacha20poly1305 is how to securely operate over large plaintexts/ciphertexts, particularly ones too big to process in RAM.

In the aead v0.4 crate, we have introduced a stream module which implements the STREAM nonce-based online authenticated encryption protocol designed by Phil Rogaway:

aead::stream - Rust

STREAM allows any AEAD cipher to be used in an incremental/streaming manner, with every chunk's integrity verified before it is decrypted. It provably defends against reordering and truncation attacks.

---

Elliptic Curves

See the project repo at: https://github.com/RustCrypto/elliptic-curves

Release highlights

• elliptic-curve v0.9: traits for generic programming over elliptic curves
• ecdsa v0.11: Elliptic Curve Digital Signature Algorithm

Curves

• bp256 v0.1: Brainpool P-256 elliptic curves
• bp384 v0.1: Brainpool P-384 elliptic curves
• k256 v0.8: secp256k1 elliptic curve
• p256 v0.8: NIST P-256 elliptic curve
• p384 v0.7: NIST P-384 elliptic curve

JWK Support

The elliptic-curve crate now natively implements JSON Web Keys (JWKs) in the form of the elliptic_curve::JwkEcKey type.

You will need to enable the jwk feature of your desired crate to use it.

When enabled, the corresponding SecretKey type for a given curve (e.g. p256::SecretKey) will have methods such as:

• SecretKey::from_jwk_str: decode a secret key from a string containing a serialized JWK
• SecretKey::to_jwk_string: serialize an elliptic curve secret key as a JWK string

---

crypto crate v0.2

Last but not least, we've cut a new release of the crypto crate, which provides a high-level facade over our other trait crates.

[jhpratt]

Thank you and everyone else for your hard work!

[teor]

@bascule

CPU features like AES-NI, AVX2, and CLMUL, are now automatically detected on i686/x86_64 CPUs. This means on these CPUs you should get optimal performance out of the box.

I'm curious what happens with Apple M1 processors here? Or on ARM generally?

(I realise it's much harder to get ARM hardware, for both CI and local development use.)

[bascule]

Right now the ARM acceleration we have is limited to some of the hash functions (sha2, sha1, whirlpool, and md5) and Linux/ARM64 only.

Getting this working on Apple M1 targets, and expanding support to crates like aes, is definitely very close to the top of our list for the next thing to work on.

We have several issues about this open right now if you'd like to peruse them:

• https://github.com/RustCrypto/block-ciphers/issues/10
• https://github.com/RustCrypto/hashes/issues/257
• https://github.com/RustCrypto/asm-hashes/issues/5
• https://github.com/RustCrypto/universal-hashes/issues/88
• https://github.com/RustCrypto/utils/issues/378

One of the trickiest things right now is stdarch intrinsics for ARM are unstable, so to support stable Rust we need to use ASM implementations.

That said, we have done some preliminary explorations of using the ARMv8 Cryptography Extensions via stdarch intrinsics, which would better fit the RustCrypto project's overall mantra of "pure Rust". It should be possible for us to start exploring stdarch intrinsic-based versions of e.g. AES and SHA1/256/etc but gated under e.g. a nightly cargo feature, and with automatic CPU feature detection.