On Thu, Apr 04, 2019 at 01:41:50PM +0000, Pascal Van Leeuwen wrote: > > The issue is that the self-tests now verify that CBC implementations update the > > IV buffer to contain the next IV, aka the last ciphertext block. But the Rockchip > > crypto driver doesn't do that, so it needs to be fixed. > > > > This has always been a requirement for CBC implementations so that users can > > chain CBC requests. Unfortunately it was just never tested for... > > > This did not immediately trigger me when it came flying past a couple of weeks > ago, but I ran into the same issue today with the inside_secure driver I'm playing > with: it does NOT return correct IV outputs for CBC modes. > > However ... I'd like to question that very requirement ... if I may :-) > > My reasoning is that this IV output *is* available as the last block of either the > output (for encrypt) or input (for decrypt) datastream. So requiring it to be > updated in the IV buffer as well seems redundant to me. It burdens the driver > with an extra data copy operation, while in the majority of practicle use cases > you would not even *need* this output IV. (chaining IV's would not work on > a hardware accelerator anyway, because you would need to serialize the > datastream, meaning you run at the speed of the round-trip latency instead > of the throughput, which is typically one to two orders of a magnitude slower) > > And in the odd case you do need it, you can just grab it from the data buffer > yourself. > > Pascal van Leeuwen > Silicon IP Architect, Multi-Protocol Engines > Herbert, can you explain what users actually rely on the next IV being returned? I don't know all the historical context behind this. - Eric
