On 01/17/2011 11:40 AM, Phil Sutter wrote: > Hi, > > On Sat, Jan 15, 2011 at 02:00:02PM +0100, Nikos Mavrogiannopoulos > wrote: >> On 01/06/2011 07:16 PM, Phil Sutter wrote: >>> When trying to en-/decrypt a buffer using CBC in two steps by >>> passing a part from the buffer's start at first, and then the >>> remaining data in the second call, the second operation depends >>> on the first one in that it's IV depends on it's result. >>> Insiders know of course, that the IV of any CBC block to operate >>> on is simply the enciphered last block. So this patch is maybe >>> most useful for everyone else, altering the passed IV upon >>> returning the results. >> >> Why do you need that? This is really CBC specific and might make no >> sense in other modes (that might be added in the future). If the >> code this flag is supposed to target is CBC-specific anyway, >> wouldn't it be easier to just use the last block? > Well, isn't the whole IV-concept kind of CBC-specific? Of course, if > the continuative IV is _always_ the last block (whose size also may > vary from one cipher to the other), one could easily use that. But I > suppose, this is subject to change (not really, but there will > probably be algorithms which use the IV differently). After all, > this is basically just the cryptoapi's behaviour exposed. So there is > no calculation done in cryptodev at all, just the updated > cdata->async.iv written back to userspace.
There are other block modes that use IV as well, but anyway I see that it might be useful to have that... If you add a flag for that (to avoid overwriting IVs when shouldn't), I'll apply that. regards, Nikos _______________________________________________ Cryptodev-linux-devel mailing list Cryptodev-linux-devel@gna.org https://mail.gna.org/listinfo/cryptodev-linux-devel
