Block-modes state saving

[jethrogb]

Would you accept a PR adding serde support behind a feature to block-modes? This could be used to implement multi part encryption APIs on top of block-modes. For example: you encrypt a couple of block, save the state, later, restore the state and encrypt a couple more blocks, save/restore, (etc.) finalize. This is a pretty standard paradigm in some legacy crypto APIs that I'd like to implement with a Rust backend.

cc @zugzwang

[newpavlov]

Note that a straightforward implementation of the serde traits would require serde support from block cipher crates as well, which I would like to avoid (e.g. in the case of aes it becomes non-trivial, since we support two backends).

I think a better approach would be to add a method for exposing current IV, which then can be used to re-initialize block mode.

[jethrogb]

Then you're just pushing the cipher (key) serialization onto the user. You coud just say C: Serialize + Deserialize. For block ciphers that don't have it, it's easy to wrap them with something that remembers the key and (de)serializes. Not sure if the bound is necessary for P?

Either way is fine for me. I guess I'd want to same on ctr.

@zugzwang do you think this is doable?

[newpavlov]

Not even touching the matter of different backends in aes, I think it's far more reasonable to serialize and transfer over wire a key, than a block cipher state, which usually contains a bunch of expanded round keys (i.e. cipher states are bigger than keys used for their initialization).

For ctr you already can do it by transferring IV/nonce used during mode initialization and current stream position (see SyncStreamCipherSeek).

[jethrogb]

Well, presumably, a cipher serialization would serialize the original key and not the expanded key. But I suppose it may not be saving the key in order to do that?

[tarcieri]

Both backends of the aes crate retain only the expanded key, in two different (and incompatible) representations

[zugzwang]

@jethrogb it is doable. I can send a PR with the method to expose the "current IV" mentioned by @newpavlov, according to each mode of operation. (The clients can already compute the IV anyway at the cost of XORing blocks - such a method would avoid extra caching).