>>> 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! If goal is to encrypt files with XTS with enc utility, then it's *not* the way to solve the problem. There are two possible options: 1. Forbid usage or XTS with enc. 2. Decide how to handle it (multiple options, real mode-specific, non-API ones, discussed earlier) and implement it in enc(*). One can do both in the given order. If goal is to compare performance, then speed -evp aes-128-xts with and without -engine argument would suffice. (*) if XTS layer is extended with notion of block size, it's possible to minimize enc's involvement to just initially setting block size. In which case XTS layer would have to take care of tweak chaining, IV increment (basically counter, but in little-endian order), perhaps even adaptive padding... ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
