COLM

[Schmid7k]

This is an optimized implementation of the COLM AEAD cipher using x86_64 instructions. COLM has been selected as the second choice for defense in-depth during the CAESAR competition.

Currently it is only COLM0, meaning the COLM variant without intermediate tag generation.

It comes with a pre-defined Colm0 type using Aes128 as underlying block cipher, as specified by the original COLM document, though it can be used with any block cipher.

Given the same inputs it produces the same output as the reference implementation in C.

Since I am in contact with an author of the original COLM specification I was able to benchmark an optimized C implementation against this optimized Rust implementation. Both versions behave almost equally in terms of performance, though the Rust implementation was slightly faster (diff of ~0.06cpb, so negligible) with smaller buffer sizes (<= 1KB), while the C implementation was slightly faster (diff of ~0.05cpb, again negligible) with bigger buffer sizes (>= 2KB). The general speed was 2.73 - 2.61cpb for buffer sizes of 1KB - 16KB on an Intel Core I7 8700k at 3.7GHz core clock.

The crate is [no_std] but one thing I have to point out is that I am using the u8x16 type from core::simd, which requires me to enable #![feature(portable_simd)], because it is still considered an unstable library feature.

I think this is good enough for an initial release though I can certainly still improve some parts of the encryption procedure. And then there is also the case of implementing it generic over the intermediate tag generation.

[tarcieri]

Sorry I haven't had time to look at this yet. Been doing releases of all of the other AEAD crates, but those releases are done.

Can you rebase and get CI green?

[Schmid7k]

Sorry I haven't had time to look at this yet. Been doing releases of all of the other AEAD crates, but those releases are done.

Can you rebase and get CI green?

Yeah sure no problem!
I worked on parallelizing COLM in the meantime and got a version that's proper and working, though it is only properly implemented for platforms with an encryption pipeline of length 4 ('cause it always processes 4 blocks in parallel). Guess I would have to do something along the lines of your AES crate if I wanted to implement it generic over the underlying encryption pipeline length?

[Schmid7k]

Both the workspace/codecov and the clippy tests are failing, because of the #![feature(portable_simd)] in my code.

[Schmid7k]

Oh and btw I have implemented an optimized version of SUNDAE in the meantime. It was submitted to the NIST lightweight cryptography competition as part of SUNDAE-GIFT. Would you be interested in this as well? If so should I include it with this PR and update the title or open a new one?

[tarcieri]

Would you be interested in this as well? If so should I include it with this PR and update the title or open a new one?

A new PR would be great so they can be reviewed/merged independently of one another

[Schmid7k]

Ok codewise I am pretty much done. One thing to point out though is that colm as a crate name is already registered so we would have to come up with a different name. Currently it is named colm_rs though something like colm_cipher would probably be more meaningful.

[tarcieri]

@Schmid7k wow, I really apologize for letting these go by the wayside along with #469.

If you can rebase them again we can try to get them landed before our next breaking upgrade.

[Schmid7k]

@tarcieri Oh, no problem.
I instinctively thought you were waiting for core::simd::u8x16; to become stable as it was still an unstabled feature back when I developed these.
Gotta take a look at it now and will push an update soon!

[Schmid7k]

Alright, here's a rebased version for you.