On Sun, Feb 21, 2010 at 09:01:40PM +0100, Sebastian Andrzej Siewior wrote: > > I also destroy the user supplied IV. You don't care about that? :) > So I have to know that someone called setkey() on this ctx but I can't > leave hints. How about this? You extend the IV by one more byte, and use that byte as a boolean flag to indicate whether the IV is valid. All users that cannot supply their own IVs can then set the IV to zero. When you see the zero flag in the IV, you reinitialise the IV per the key. > salsa also does not stick to plan here. ctx->input[6-9] is initialized > in encrypt() path. So two threads sharing a ctx are going to clobber > their state. Salsa should also be fixed. > What about a new api for the stream cipher? We would merge the ctx part > and the iv into one handle. So the user would call setup_iv() instead of > setkey(). The difference would be that I can access the iv from within > setkey(). And the algorithm can fully express himself since he is no > longer trapped in the wrong body :) There is some merit in that, but as the current API can be made to do the same thing (see above) I'm not convinced that this is worth the cost for the moment. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- 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
