Repository navigation
Intermediate IV exposing for save/restore APIs #5
Description
Hello folks, would you accept a PR similar to block-ciphers/pull/227 as suggested by @newpavlov, allowing to serialize ciphers and continue operation later? Note that even without the exposure, the cryptor can recover the internal IV state at any moment, but this would require additional caching (one full ciphertext block for CFB, and one ciphertext block + one plaintext block + one xor for OFB). Perhaps we could implement the same IvState trait.
Regards
cc. @jethrogb
Activity
tarcieri commentedon Mar 22, 2021
Sounds good to me. @newpavlov, what do you think?
zugzwang commentedon Mar 23, 2021
One detail is that the
IvStateextends aBlockMode. In hindsight, I could have made it more general so that a stream cipher can implement it (IvStateonly needsSelf::IvSize). Should I be change it? Or should the stream cipher have its own trait?tarcieri commentedon Mar 23, 2021
Unifying it into a single trait sounds good to me and follows the general course of what @newpavlov has been working on in the
ciphercratenewpavlov commentedon Mar 24, 2021
Sounds good to me as well, but, as you've noticed, it's blocked on introduction of a block-level trait for stream ciphers. Right now we have only slice-based traits which handle buffering internally, thus the
IvStatetrait will not be a good fit here. If you need this functionality ASAP, then as a temporary solution we can add CTR to theblock-modescrate. We already duplicate the two CFB modes, so I think it will be fine to duplicate CTR as well.jethrogb commentedon Mar 24, 2021
I don't understand this part? The whole point is to use the byte-based interface.
zugzwang commentedon Mar 29, 2021
I should have emphasized on the fact that we currently need this for CFB and OFB (for CTR,
current_posandseekdo the job). We prefer to use CFB and OFB within thestream-cipherscrate, since as @jethrogb mentions, we want byte granularity. From what I see, they both define one internal block that would allow serialization and that the client could recover at any time hélas with some effort (Cfb.ivandOfb.block).newpavlov commentedon Feb 10, 2022
I think #2 should resolve this issue. For performance reasons we store encrypted IV, so implementation of the
IvStatetrait in the CFB case also requiresBlockDecryptbound.Also note that neither
cfb, norciphercrates include built-in buffering for async stream ciphers. We only provide consuming byte-level methods, so you may have to implement your own block buffering.cfal commentedon Mar 12, 2022
did this used to be supported?
AsyncStreamCiphertook an&mut selfwhich allowed it to be used in a streaming manner.. is there a replacement for this or another issue relating to this change?newpavlov commentedon Mar 12, 2022
@cfal
Yes, it was. But I think that for most cases the current non-buffering approach is sufficient. It's still possible to build a buffering wrapper around the
AsyncStreamCiphertrait, but currently it's not included intocipher. If you need such wrapper, please open an issue in the traits repository.cfal commentedon Mar 13, 2022
@newpavlov thank you! created RustCrypto/traits#964