Or extend EVP_CIPHER_CTX_ctrl() to handle things like changing IV's ?
Modes like XTS may gain a lot from that, you could use EVP_CIPHER_CTX_copy() to avoid repeated key expansion costs, change the IV with EVP_CIPHER_CTX_ctrl() and do the next block.
Peter
-----owner-openssl-...@openssl.org wrote: -----
To: openssl-dev@openssl.org
From: nicolas....@free.fr
Sent by: owner-openssl-...@openssl.org
Date: 07/11/2014 11:46PM
Subject: Re : Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command
From: nicolas....@free.fr
Sent by: owner-openssl-...@openssl.org
Date: 07/11/2014 11:46PM
Subject: Re : Re: [openssl.org #3442] [patch] AES XTS: supporting custom iv from openssl enc command
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
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
