Implement AsyncRead and AsyncWrite

[nicolaspernoud]

Hello,

Thanks for your amazing work.

Juste wondering how (and if) it would be possible to implement async writers and readers to be used with tokio::fs::File . For the time beeing it does not seems to be possible to do something like :

let mut f =  tokio::fs::File::create(full_path).await?;
write::Encryptor::new(f, Cipher::aes_128_cbc(), &key, &iv).unwrap();

[mqudsi]

This is the problem with the current fragmentation of the async ecosystem in rust. Tokio doesn't use the "centralized" version of AsyncRead/AsyncWrite found in futures::io and instead has its own tokio::AsyncWrite, but cryptostream is a library that doesn't have any dependencies on tokio, async-std, or any other specific async runtime.

That said, if you are using this to do crypto operations on a file residing on disk or to/from a pipe (i.e. not a network stream), then my suggestion is to use the following instead:

tokio::task::block_in_place(|| {
    let mut f = std::fs::File::create(full_path)?;
    write::Encryptor::new(f, Cipher::aes_128_cbc(), &key, &iv).unwrap();
});

You should ideally be doing this even if you're not using crytostream because file io is not actually async under tokio (or any other mainstream reactor) and instead actually blocks a separate thread serving the IO request to make it look like an async operation. Using block_in_place with the std version of File (or pipe) will give you better performance in this case (this is well-documented in the tokio GitHub repo).

To actually make cryptostream work with any tokio AsyncRead/AsyncWrite object, the cryptostream crate would need a new (optional) feature ("tokio") that operates against those traits; you would be able to then use that version of the api to interface with any AsyncRead/AsyncWrite "stream" generic over its underlying type (network, file, pipe, etc). If you would like to work on this, I'm more than happy to help you open a PR.

[nicolaspernoud]

Hello, thanks for your answer. My use case is actually encrypting and decrypting a file from a network stream, so your suggestion would not be applicable, but I'll try to find another way.

Some other questions :

• Is there a simple way to work out an encrypted file size from the original file size and the other way around ?
• Is it possible to wrap a file.seek(pos) method with a read::Decryptor ?
• Is it possible to store the IV as an header of the encrypted file ?

Best regards.

[mqudsi]

• Since AES is a symmetric block cipher, the encrypted file size is the same as the original file size but rounded to the nearest full block (128 bits/16 bytes).
• Arbitrarily seeking into an AES-encrypted file depends on the AES encryption mode you are using. AES CBC lets you decrypt any random block but the output must be xor'd with the previous ciphertext block instead of the IV. So it's perfectly doable, but you need to first seek to a position one block before the position you want, read that block as-is into a buffer, then construct the cryptostream with the contents of that buffer as the IV (instead of the initial IV you had for the whole file). Just remember that you can only decrypt at 16-byte block intervals, so you need to round down to the nearest block start and decrypt from there.
• You can store the IV as the first block in the file, but cryptostream doesn't do that so you'd have to insert it afterwards for encryption and read it first then seek past it for decryption. No problem after that.

[nicolaspernoud]

Hello, Thanks a lot for your answers. Regarding the last point, it would be nice to have a library taking care of the IV generation and storage alongside the data to allow foolproof usage. But I understand that is not in the cryptostream roadmap at least for now.