From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric Biggers Subject: Re: [Bug] Rockchip crypto driver sometimes produces wrong ciphertext Date: Thu, 4 Apr 2019 10:12:05 -0700 Message-ID: <20190404171204.GA121392@gmail.com> References: <20190126210530.GB709@sol.localdomain> <1894799.pWIprST79S@phil> <20190315033140.GB1671@sol.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: "linux-arm-kernel" Errors-To: linux-arm-kernel-bounces+linux-arm-kernel=m.gmane.org@lists.infradead.org To: Herbert Xu Cc: Tao Huang , Zain Wang , Heiko Stuebner , Arnd Bergmann , Ard Biesheuvel , Pascal Van Leeuwen , Zhang Zhijie , "linux-rockchip@lists.infradead.org" , "open list:HARDWARE RANDOM NUMBER GENERATOR CORE" , Olof Johansson , "ezequiel@collabora.com" , linux-arm-kernel List-Id: linux-rockchip.vger.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