>> If you encrypt the 32KB block with multiple calls to EVP_CipherUpdate (for >> example 4KB at a time), you'll see this effect. Each call to >> EVP_CipherUpdate restarts the tweak. I posted a question as whether that's a >> bug or a feature a few weeks ago but didn't get any conclusive responses. >> AES XTS is the only mode with this issue. Other modes preserve the chaining >> across calls to EVP_CipherUpdate. >> > > That's a feature of how XTS mode is implemented. The normal use for XTS is > hard disk encryption in sector size chunks where all the data is available in > memory at once.
Correct. And application is expected/required to set the "IV", conventionally block number in little-endian order, prior *each* EVP call. 'enc' doesn't do that. One can argue whether or not it would be harmful to make EVP increment IV upon each call so that it can be used with 'enc' command to encrypt files as whole. Couple of points. a) You have to use same block size (relying on default value is hardly appropriate as it may change). b) Last chunk of data has to be longer 16 bytes or longer. If XTS is to be made working with 'enc' utility, then encrypted data would have to be accompanied by custom header with block size and arrange padding. It's probably more appropriate to simply ban XTS (as well as CCM and GCM) for usage with 'enc' utility. On related note. If anything should be done with XTS, then it's probably notion of block size at EVP level, so that application can ask to process several blocks at a time. I mean consider storage. It's not seldom that you'd have to write multiple blocks at a time. As it is now you'd have to make call per each block (and generate accompanying per-block tweak value). But if you can ask subroutine to process several blocks at a time, you allow for optimization of tweak generation. I mean you'd still have to generate multiple tweaks, one per block, but in cases such as AES-NI, BSAES, you can parallelize the process and effectively divide overhead among multiple blocks (see even RT#3042). ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [email protected] Automated List Manager [email protected]
