On 17 January 2017 at 09:25, Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> wrote: > On Tue, Jan 17, 2017 at 09:20:11AM +0000, Ard Biesheuvel wrote: >> >> So to be clear, it is part of the API that after calling >> crypto_skcipher_encrypt(req), and completing the request, req->iv >> should contain a value that could potentially be used to encrypt >> additional data? That sounds highly specific to CBC (e.g., this could >> never work with XTS, since the tweak generation is only performed >> once), so it does not make sense for skciphers in general. For >> instance, drivers for h/w peripherals that never need to map the data >> to begin with (since they only pass the physical addresses to the >> hardware) will need to explicitly map the destination buffer to >> retrieve those bytes, on the off chance that the transform may be >> wrapped by CTS. > > Yes this is part of the API. There was a patch to test this in > testmgr but I wanted to give the drivers some more time before > adding it. > Got a link? > It isn't just CBC that uses chaining. Other modes such as CTR > use it too. Disk encryption in general don't chaining but that's > because they are sector-oriented. > OK, so that means chaining skcipher_set_crypt() calls, where req->iv is passed on between requests? Are there chaining modes beyond cts(cbc) encryption that rely on this? It is easily fixed in the chaining mode code, so I'm perfectly happy to fix it there instead, but I'd like to understand the requirements exactly before doing so -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
