Ctr32 about stream-ciphers HOT 9 CLOSED

@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.

from stream-ciphers.

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?

from stream-ciphers.

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.

from stream-ciphers.

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

from stream-ciphers.

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?

from stream-ciphers.

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.

from stream-ciphers.

@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.

from stream-ciphers.

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

#170

from stream-ciphers.

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

from stream-ciphers.