On Sun, Jul 13, 2014, Andy Polyakov wrote: > >>> Also the changes I am proposing may not be acceptable for similar reasons. > >>> > >> It may be that your implementation of an AF_ALG EVP_CIPHER for XTS can be > >> changed so it works with unmodified OpenSSL. The OpenSSL XTS implementation > >> is a software implementation and some techniques it uses wont be > >> appropriate. > >> > >> Is the EVP_CIPHER code you're using for XTS available somewhere? > >> > > > > If you look through the existing code for XTS mode in e_aes.c you'll see it > > copies the IV manually. If your EVP_CIPHER implementation includes the > > EVP_CIPH_ALWAYS_CALL_INIT flags you can do the same. If you handle that > > appropriately you shouldn't need to modify OpenSSL at all. > > Let's not loose our heads. What is the objective? To produce arbitrary > result? I mean suggested patch doesn't actually solve real problem in > sense that modified code doesn't produce cryptographically sound output, > nor does it handle corner cases. Same applies to tweaking flags!
There are AFAICS two separate problems. One is that enc can't handle XTS mode I don't think that can be fixed easily and I'd consider it acceptable to just indicate that XTS mode isn't support by enc. The separate problem is that the OP has written an ENGINE that supports XTS mode and the requested patch was to make XTS mode work in the ENGINE. I'm suggesting that the OPs ENGINE implementation of XTS mode in an EVP_CIPHER has set the flags incorrectly (perhaps it's a generic EVP_CIPHER that handles all cases identically). Using the correct flags in the ENGINE EVP_CIPHER and not making any changes to OpenSSL should solve the second problem. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
