cipher: parallel in-place encrypt/decrypt with offset

[tarcieri]

This is a request for the aes crate specifically, but ideally it would work for any BlockCipher.

AES-SIV is a bit unique in that it prepends the authentication tag, rather than using a postfix tag like practically every other AEAD mode.

Ideally it would be nice to support an offset parameter when encrypting (as a counter mode cipher, that's all AES-SIV cares about, but it seems like supporting a decryption offset would be nice for symmetry if nothing else).

For the AES-SIV case specifically, it's a 1-block offset, that is to say, when encrypting the ciphertext is written with an offset of the block size (16-bytes) forward from the original start of the buffer. I understand there are some other use cases for an offset API which need to be finer grained than that (i.e. byte-level), such as parsing multiple AEAD messages in the same buffer as part of some framed packet protocol, but I'm not the one to ask about those.

Something which makes things a bit trickier is AES-SIV, as a counter mode cipher, uses the AES encryption block function to decrypt as well, and needs a "negative" offset in that case, decrypting a ciphertext which begins 1-block into the buffer, and then writing the resulting plaintext out at the beginning of the buffer.

I suppose this can be modeled by taking an isize as a parameter, checking its sign, and using that to determine if the offset is relative to the input or the output. Not sure that's the greatest API, but it would get the job done.

[newpavlov]

@tarcieri
In cipher v0.4 I plan to add support for buffer-to-buffer mode. Is this issue is still relevant in your opinion after that? Supporting in-place offsets generically could be a bit more efficient (you don't need to allocate additional buffers and there is less cache pressure), but implementation complexity will be quite high and I am not sure how to do it API-wise, especially for byte-level offsets. With the inout crate buffers only support two modes: either input and output buffers are equal to each other or they do not overlap. In theory we could could somehow add support for overlapping buffers, but it would require some kind of caching of in-flight blocks (otherwise we risk overwriting input data with output) and it's not clear how exactly it should be handled.

[tarcieri]

I'd say it's no big deal if we don't address this.

There are two AEAD modes in our current portfolio that could benefit: aes-siv and xsalsa20poly1305. Both of these use a prefix MAC tag, and utilize copy_within to shift the location of the ciphertext/plaintext within the buffer.

If it were more than these two I'd be a bit more concerned. Both of them are effectively obsoleted by aes-gcm-siv and chacha20poly1305 so I'm not terribly concerned.