jedisct1/rust-rocca-s

ROCCA-S cipher implementation for Rust.

ROCCA-S for Rust

This is a Rust implementation of the ROCCA-S: an efficient AES-based encryption scheme for beyond 5G authenticated cipher, ported from the Zig implementation.

ROCCA-S is key committing, has a 256 bit key size, a 128 bit nonce, processes 256 bit message blocks and outputs a 256 bit authentication tag.

Cargo flags

• std: allow dynamic allocations

std is the default.

IMPORTANT: In order to get decent code on x86 and x86_64 CPUs, you should set additional rustc flags prior to compiling that crate or a project using it:

export RUSTFLAGS="-Ctarget-feature=+aes,+sse4.1"

A benchmark can be run that way:

export RUSTFLAGS="-C target-cpu=native -Ctarget-feature=+aes,+pclmulqdq,+sse4.1"
cargo bench

Benchmarks

Benchmarks take a 16384 bytes input block. Results are in bytes per second.

Rust implementations

Crates:

• aes-gcm
• chacha20poly1305
• aegis128l
• rocca

Scaleway EPYC 7543 instance, RUSTFLAGS set.

cipher	speed
aes256-gcm	1.18 G/s
aes128-gcm	1.24 G/s
chacha20-poly1305	1.62 G/s
aegis128l (rust)	5.08 G/s
rocca	5.09 G/s

WebAssembly (Wasmtime)

cipher	speed
aes256-gcm	36.88 M/s
aes128-gcm	44.13 M/s
chacha20-poly1305	193.05 M/s
aegis128l	48.98 M/s
rocca	58.61 M/s

Other implementations

cipher (implementation)	speed
aes256-gcm (OpenSSL)	4.97 G/s
aes128-gcm (OpenSSL)	6.89 G/s
chacha20-poly1305 (OpenSSL)	2.67 G/s
aes128-ocb (OpenSSL)	8.93 G/s

rust-rocca-s's Issues

Consider implementing untagged decryption mode for select use cases

Although Rocca is an authenticated encryption mode producing and consuming a tag, it's possible that the user may deliberately not want to validate with a tag in some cases (they may not have it, or they may be achieving integrity checking in another way). I may point to a kind of "daisy chained" series of AEAD operations, or a length-preserving all-or-nothing-transform as examples.

And so this is a suggestion to consider a variant in this (and related/Morus) code to not validate against a tag when the user deliberately wants to do that.

A related idea is to have the decrypt produce the tag that the in-place encryption would have produced, and to return it instead of consuming it.

Very small or non-blocksize-multiple input size may not be decrypting properly

I can have some self-contained test cases on this in the coming days to showcase this, although speaking at a high level, I noticed that with this (Rocca) code (but not the similarly designed Morus one), small-sized (< 16 byte) inputs and/or inputs not a multiple of the blocksize, the decryption of an encrypted plaintext didn't return the original. For larger inputs or full integer multiple sizes I believe it was all working correctly. I thought this would be easy to reproduce with some test inputs at those sizes, but if not, please let me know. Note that the very similarly styled implementation for Morus didn't have an issue. Because these have similar design, looking at differences between them may help uncover what's going on. I'm using the encrypt/decrypt in-place mode.

Rocca-S

You may have seen this, but there's now an Internet Draft for Rocca-S, which has a 256-bit tag.