> 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
