Hi and sorry to interfere, I had to review all ciphers available in openssl, and what seemed weird to me is that algorithms are always given as a combination of a symmetric cipher and a mode of operation This approach was convenient since stream ciphers and block cipher with a mode of operation didn't need to be distinguished, and it worked fine as long as there were not so much chaining modes and none requiring more than an IV.
However, with much modes available now, and with these mode being quite independent from the block cipher used, I wonder if it wouldn't be nice to add something like EVP_MODE and EVP_MODE_CTX structures to manage modes independently. Practically, modes only need to know from a block cipher ecb encryption and decryption routines and block size. Thus treating block ciphers and modes separately could improve modularity (eg. Blowfish in GCM mode doesn't seems to exist, while both BF and GCM are implemented) EVP_MODE would provide init, update and final routines, depending on encrypt/decrypt routines from block cipher, and EVP_MODE_CTX would store Ivs, AADs, buffers and any other mode specific data. If I'm not mistaken, this is compliant with the API philosophy. Obviously, it can be tricky to make it compatible with the current API but it does not appear to be impossible. For example using a function that could create an EVP_CIPHER from a block cipher and a mode (basically by using the encrypt/decrypt routines from the block cipher). Or given all block ciphers and modes, one can also declare all possible combinations, without too big efforts since it would mainly consist in setting some pointers. With this approach, some functions EVP_MODE_CTX_set_xxx can also be added to manage mode-specific operations (setting IV length in XTS, or AAD in GCM) while maintaining backward compatibility. I hope this is a more constructive proposition. However I think this could be nice to have such feature from an user point-of-view, and that it would also make the library easier to maintain. Best regards Nicolas ----- Mail d'origine ----- De: Andy Polyakov <ap...@openssl.org> À: openssl-dev@openssl.org Cc: lull...@yahoo.com Envoyé: Fri, 11 Jul 2014 12:56:50 +0200 (CEST) Objet: Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command >> Bottom line [still] is that enc is not the place to perform XTS, >> *unless* it's treated specially. In other words question should not be >> about setting IV, but about *if* XTS should be supported by enc, and if >> so, how exactly. > > It seems to me this is why jamming modes like XTS into standard EVP as > if they were like other modes is a less than great idea. But providing own interface for every specific mode is also hardly fun. I mean there ought to be balance. Now we have EVP that implies different semantic in different modes. In other words application might have to perform extra calls depending on mode (and in this particular case problem is that enc doesn't do those calls). What would be alternative? Distinct interface for every class of modes? Can we define what makes up such class? What do we expect from interface? Also note that either way, the fact that it needs to be treated in enc in special way doesn't change. It's not like I'm rejecting alternatives to EVP, but discussion have to be more constructive. ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org ______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
