GCM: encrypt with `Read` / allow for several call about aeads HOT 4 CLOSED

I think the best solution to this sort of problem is to provide a segmented / "online" encrypted mode instantiated from AES-GCM, e.g. Phil Rogaway's STREAM construction:

https://github.com/miscreant/meta/wiki/STREAM

This would allow Read and Write to consume and release chunks of a message, ensuring they're each authenticated, in the correct order, and not truncated.

from aeads.

Thanks for your quick answer, and for pointing this construction.

I still have a more implementation related problem: the Read might receive only 1 byte per call. Then, I would like to avoid having to create and embed a tag for just one byte (sizing issue, the output being a file). Also, and I didn't mention it in my first post, I would like to be able to seek in the encrypted form, and then decrypt.

Then, I was planning to, given an "online" API, encrypt until, let's say 4MB, have been produced. The tag is then dumped, and we start a new chunk, with an incremental IV.
Decryption with seeking is performed by going to the (chunk + tag) rounded size, performing a in-memory authenticated decryption of the whole chunk, and then returning the asked bytes. The memory constraint aforementioned is actually on the producer (the one encrypting the data).

from aeads.

Read might receive only 1 byte per call

To use STREAM with io::{Read, Write} you will need to do one of two things:

• Use a fixed chunk size, and buffer until you reach that size
• Add framing around the protocol with length information for variable-sized messages

In either case, you'll need buffering, either with chunk-size buffers, or until you reach the length specified by whatever framing protocol you're using.

I would like to be able to seek in the encrypted form, and then decrypt.

You definitely want STREAM for this. There is no way to authenticate an AEAD message without processing the whole thing.

I definitely would like to provide a STREAM crate, or possibly add STREAM itself to the AEAD crate (probably start with the former). I've been working on an implementation inside one of my tools, and rage also has one /cc @str4d

from aeads.

Again, thanks for your quick answer and the associated links.

I will indeed consider the use of STREAM, and maybe implement it on my own (likely based on the rage implementation). If you ever find the time to implement a STREAM crate, I'll consider using it instead :).

In either case, you'll need buffering, either with chunk-size buffers, or until you reach the length specified by whatever framing protocol you're using.

As I mention earlier, I would like to be able to write the encrypted bytes as soon as possible, to avoid keeping them in memory, and finalize each fixed-size chunk with the corresponding tag. My requirement is probably too custom to deserve a proper implementation in this crate, so I'm closing this issue.

Thanks again for your help!

from aeads.