Ctr32

[tarcieri]

There are several constructions based on stream ciphers that use a 32-bit counter:

• AES-GCM
• AES-GCM-SIV
• ChaCha20Poly1305 (IETF version, but we can implement the "legacy" version with one too)

I was thinking it would be interesting to have a Ctr32 type which is generic around the block size. If so, I could impl the ChaCha20 and Salsa20 core functions as a sort of 512-bit wide pseudo-BlockCipher, which would let us have reusable stream cipher buffer management and seeking across all three of the aforementioned ciphers. Note that pulling this off would also need for it to be generic around endianness, as I believe AES-GCM needs a big endian counter and AES-GCM-SIV and ChaCha20Poly1305 need a little endian counter.

If we had that, it would also eliminate the need for the salsa20-core crate, or rather, we could merge it into the salsa20 crate.

Notably right now the only other ctr type, Ctr128, is specialized to a 128-bit block size. This actually seems ok to me, as it seems rather unusual to use a 128-bit counter with anything other than a 128-bit block size.

[tarcieri]

@newpavlov I think it might be possible to have one Ctr trait to rule them all, that has both the counter size and the block size as generic parameters.

I'm also curious if it might make sense to have something other than BlockCipher be the trait which a fully generic Ctr type uses. Something like this (apologies for the awful name):

pub trait Ctrable {
    type Counter: Add<Output = Self>;
    type BlockSize: ArrayLength<u8>;

    fn block(&self, counter: N) -> GenericArray<u8, Self::BlockSize>;
}

This sidesteps a few issues:

• Endianness
• Cases where we might need more initial state than just a key (ChaCha20 IV)
• Mismatches between the counter and block size (that's left to the trait implementor to screw up)

...but it should also allow unified buffer management across all stream ciphers which are fundamentally block based at their core, which seems like a win to me.

I think you could also have some sort of marker traits like:

pub trait CtrableBlockCipher<E: ByteOrder>: BlockCipher + CtrEndian {}

pub trait CtrEndian {
     type ByteOrder;
}

...along with a blanket impl of CtrableBlockCipher for all CtrableBlockCipher types.

[newpavlov]

I am not yet sure about usefulness of such generalization. How SIMD optimizations will look if we'll adapt this trait? Will we make even wider pseudo block cipher?

[tarcieri]

I was going to take a stab at SIMD ChaCha20 after my latest refactor. The short answer is you don't want to compute multiple blocks in parallel (the construction is already amenable to SIMD without computing multiple blocks in parallel, which for AES-NI is a largely a hack around the formerly high clock cycle). AVX2 backend now implemented, and does compute two blocks in parallel.

[tarcieri]

Presently the aes-gcm and aes-gcm-siv crates both contain a Ctr32 implementation. They are nearly identical: the main difference is endianness:

• https://github.com/RustCrypto/AEADs/blob/master/aes-gcm/src/ctr.rs
• https://github.com/RustCrypto/AEADs/blob/master/aes-gcm-siv/src/ctr.rs

Neither of them presently implement any of the stream cipher traits, although it seems like they probably should.

I think it'd be nice to unify them and move them into the ctr crate, as well as potentially providing AES-NI optimized versions in the aes crate, using the stream cipher traits to allow for using either depending on which features are enabled.

See this PR as well, where there's interest in reusing them (in a special implementation of AES-GCM which is designed to prevent a timing discrepancy on MAC verification failure):

RustCrypto/AEADs#188

[tarcieri]

I'd like to look at unifying and upstreaming the Ctr32 implementations, but question:

Should we put them in the ctr crate, or consider splitting ctr into separate ctr32 and ctr128 crates?

[newpavlov]

I think we can keep them in one crate. It could be worth to look into generating those types via a macro to reduce code duplication. There was also an old proposal (unfortunately I don't remember the author), to write CTR mode generic over Fn(&mut Counter), this function would increment an inner state, though I am not sure if such generalization will be zero-cost and useful in practice.

[tarcieri]

@newpavlov I'd like to upstream Ctr32 more or less as it exists today, except generalizing over the big endian vs little endian difference, and then we can do another pass to try unifying them maybe.

Note that there are still some small discrepancies between Ctr32 in AES-GCM and AES-GCM-SIV beyond endianness that make generalizing those annoying, let alone generalizing Ctr32 and Ctr128.

[tarcieri]

Opened an initial PR here to vendor the Ctr32 implementations from the aes-gcm and aes-gcm-siv crates here:

#170

[tarcieri]

This was merged in #170 and (pre)released in ctr v0.6.0-pre.