Re-export chacha module from chacha20poly1305

[rosingrind]

Some crates such as chacha20poly1305 are missing re-export rules for base crates. Others, in contrast, may have optional features such as this one:

AEADs/aes-gcm/src/lib.rs

Lines 106 to 107 in 50710da

	#[cfg(feature = "aes")]
	pub use aes;

[tarcieri]

Is there a particular use case you have in mind where you need access to the raw stream cipher?

In the case of aes-gcm, it's to allow customization of the nonce size, where you need to pass the variant of AES-GCM as a generic parameter along with the nonce size (and arguably that would be better handled by type aliases which are generic around the nonce size).

No such concern exists in this crate.

[rosingrind]

A case: boxed traits if you'd like to implement abstraction from encryption backends. Detaching abstract encryption trait from aes/cha/etc could be more pleasant if every crate will re-export the same set of under the hood traits. I understand that in this case peer dependency integrity is not guaranteed, but I actually don't see any other reliable choices in such a case

[tarcieri]

Can you provide a code example?

I can't tell if what you're describing just needs a re-export of the cipher crate, as opposed to re-exporting the raw stream ciphers

[rosingrind]

Sure, I'll try my best to explain. Assume you have an universal trait to perform any encryption-related action on your data:

trait CipherActor {
    fn act(&self, data: &[u8]) -> Result<Vec<u8>>;
}

You may abstract your AES-related backend in such a fashion (note that all related traits are grabbed from aes_gcm::aead and aes_gcm::aes crates):

struct AesCipher<T, U>
where
    T: BlockCipher + BlockSizeUser<BlockSize = U16> + BlockEncrypt,
    U: ArrayLength<u8>,
{
    cipher: AesGcm<T, U>,
}

impl<T, U> CipherActor for AesCipher<T, U>
where
    T: BlockCipher + BlockSizeUser<BlockSize = U16> + BlockEncrypt,
    U: ArrayLength<u8>,
{
    fn act(&self, data: &[u8]) -> Result<Vec<u8>> {
        self.cipher
            .encrypt(&AesGcm::<T, U>::generate_nonce(&mut OsRng), data)
    }
}

Now you could try and abstract another backend implementation such as ChaCha20 (note that you need to import 4 traits from another crate):

use chacha20::cipher::{KeyInit, KeyIvInit, StreamCipher, StreamCipherSeek};
...
struct ChaCipher<C, N>
where
    C: KeyInit<KeySize = U32>,
    N: ArrayLength<u8>,
{
    cipher: ChaChaPoly1305<C, N>,
}

impl<C, N> CipherActor for ChaCipher<C, N>
where
    C: KeyIvInit<KeySize = U32, IvSize = N>
        + KeyInit<KeySize = U32>
        + StreamCipher
        + StreamCipherSeek,
    N: ArrayLength<u8>,
{
    fn act(&self, data: &[u8]) -> Result<Vec<u8>> {
        self.cipher
            .encrypt(&ChaChaPoly1305::<C, N>::generate_nonce(&mut OsRng), data)
    }
}

If you did all right, you can instance dyn CipherActor according to the needs, for example if you're grabbing needed cipher type from config file.

I'm actually in doubt if re-exports for these needs at least could help to ensure cargo peer deps, I'm in doubt if this particular case is even valid to implement. But, I think re-exporting needed traits in such a fashion may help to build more abstract things and greatly reduce amount of code. Any thoughts on this?

[tarcieri]

It sounds like all you need is for it to re-export the cipher crate

[rosingrind]

I actually didn't realize that at first glance... I think my questions are fulfilled, if you feel the same - feel free to do anything with the issue. I didn't check another algo crates for cipher re-export, so I think this may be a good addition for any others in case the issue will get a move

[tarcieri]

We can add cipher re-exports where it makes sense