On Sat, 23 May 2020 at 20:52, Stephan Müller <smueller@xxxxxxxxxx> wrote: > > Am Donnerstag, 21. Mai 2020, 15:23:41 CEST schrieb Ard Biesheuvel: > > Hi Ard, > > > On Thu, 21 May 2020 at 15:01, Gilad Ben-Yossef <gilad@xxxxxxxxxxxxx> wrote: > > > Hi Ard, > > > > > > Thank you for looping me in. > > > > > > On Wed, May 20, 2020 at 10:09 AM Ard Biesheuvel <ardb@xxxxxxxxxx> wrote: > > > > On Wed, 20 May 2020 at 09:01, Stephan Mueller <smueller@xxxxxxxxxx> > wrote: > > > > > Am Mittwoch, 20. Mai 2020, 08:54:10 CEST schrieb Ard Biesheuvel: > > > > > > > > > > Hi Ard, > > > > > > > > > > > On Wed, 20 May 2020 at 08:47, Stephan Mueller <smueller@xxxxxxxxxx> > wrote: > > > > ... > > > > > > > > > > > The state of all block chaining modes we currently have is defined > > > > > > > with > > > > > > > the > > > > > > > IV. That is the reason why I mentioned it can be implemented > > > > > > > stateless > > > > > > > when I am able to get the IV output from the previous operation. > > > > > > > > > > > > But it is simply the same as the penultimate block of ciphertext. So > > > > > > you can simply capture it after encrypt, or before decrypt. There is > > > > > > really no need to rely on the CTS transformation to pass it back to > > > > > > you via the buffer that is only specified to provide an input to the > > > > > > CTS transform. > > > > > > > > > > Let me recheck that as I am not fully sure on that one. But if it can > > > > > be > > > > > handled that way, it would make life easier. > > > > > > > > Please refer to patch 2. The .iv_out test vectors were all simply > > > > copied from the appropriate offset into the associated .ctext member. > > > > > > Not surprisingly since to the best of my understanding this behaviour > > > is not strictly specified, ccree currently fails the IV output check > > > with the 2nd version of the patch. > > > > That is what I suspected, hence the cc: > > > If I understand you correctly, the expected output IV is simply the > > > next to last block of the ciphertext? > > > > Yes. But this happens to work for the generic case because the CTS > > driver itself requires the encapsulated CBC mode to return the output > > IV, which is simply passed through back to the caller. CTS mode itself > > does not specify any kind of output IV, so we should not rely on this > > behavior. > > Note, the update to the spec based on your suggestion is already in a merge > request: > > https://github.com/usnistgov/ACVP/issues/860 > > Thanks for your input. > Thanks for the head's up. I've left a comment there, as the proposed change is not equivalent to the unspecified current behavior.
