Re: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext

[Eric Biggers <ebiggers@kernel.org>]

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