| Message ID | 20190614083404.20514-1-ard.biesheuvel@linaro.org |
|---|---|
| Headers | show |
| Series | crypto: switch to shash for ESSIV generation | expand |
On 14/06/2019 10:34, Ard Biesheuvel wrote: > This series is presented as an RFC for a couple of reasons: > - it is only build tested > - it is unclear whether this is the right way to move away from the use of > bare ciphers in non-crypto code > - we haven't really discussed whether moving away from the use of bare ciphers > in non-crypto code is a goal we agree on > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > where the digest size of the hash must be a valid key length for the cipher. > The setkey() operation takes the hash of the input key, and sets into the > cipher as the encryption key. Digest operations accept input up to the > block size of the cipher, and perform a single block encryption operation to > produce the ESSIV output. > > This matches what both users of ESSIV in the kernel do, and so it is proposed > as a replacement for those, in patches #2 and #3. > > As for the discussion: the code is untested, so it is presented for discussion > only. I'd like to understand whether we agree that phasing out the bare cipher > interface from non-crypto code is a good idea, and whether this approach is > suitable for fscrypt and dm-crypt. If you want some discussion, it would be very helpful if you cc device-mapper list to reach dm-crypt developers. Please add at least dm-devel list. Just a few comments: - ESSIV is useful only for CBC mode. I wish we move to some better mode in the future instead of cementing CBC use... But if it helps people to actually use unpredictable IV for CBC, it is the right approach. (yes, I know XTS has own problems as well... but IMO that should be the default for sector/fs-block encryption these days :) - I do not think there is a problem if ESSIV moves to crypto API, but there it is presented as a hash... It is really just an IV generator. > - wiring up some essiv(x,y) combinations into the testing framework. I wonder > if anything other than essiv(aes,sha256) makes sense. In cryptsetup testsuite, we test serpent and twofish ciphers at least, but in reality, essiv(aes,sha256) is the most used combination. If it makes sense, I can run some tests with dm-crypt and this patchset. Thanks, Milan
On Sat, 15 Jun 2019 at 20:19, Milan Broz <gmazyland@gmail.com> wrote: > > On 14/06/2019 10:34, Ard Biesheuvel wrote: > > This series is presented as an RFC for a couple of reasons: > > - it is only build tested > > - it is unclear whether this is the right way to move away from the use of > > bare ciphers in non-crypto code > > - we haven't really discussed whether moving away from the use of bare ciphers > > in non-crypto code is a goal we agree on > > > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > > where the digest size of the hash must be a valid key length for the cipher. > > The setkey() operation takes the hash of the input key, and sets into the > > cipher as the encryption key. Digest operations accept input up to the > > block size of the cipher, and perform a single block encryption operation to > > produce the ESSIV output. > > > > This matches what both users of ESSIV in the kernel do, and so it is proposed > > as a replacement for those, in patches #2 and #3. > > > > As for the discussion: the code is untested, so it is presented for discussion > > only. I'd like to understand whether we agree that phasing out the bare cipher > > interface from non-crypto code is a good idea, and whether this approach is > > suitable for fscrypt and dm-crypt. > > If you want some discussion, it would be very helpful if you cc device-mapper list > to reach dm-crypt developers. Please add at least dm-devel list. > > Just a few comments: > > - ESSIV is useful only for CBC mode. I wish we move to some better mode > in the future instead of cementing CBC use... But if it helps people > to actually use unpredictable IV for CBC, it is the right approach. > (yes, I know XTS has own problems as well... but IMO that should be the default > for sector/fs-block encryption these days :) > I agree that XTS should be preferred. But for some reason, the kernel's XTS implementation does not support ciphertext stealing (as opposed to, e.g., OpenSSL), and so CBC ended up being used for encrypting the filenames in fscrypt. I am trying to serve both customers with the same solution here, regardless of whether it is the recommended approach or not. > - I do not think there is a problem if ESSIV moves to crypto API, > but there it is presented as a hash... It is really just an IV generator. > True. But we don't have the proper abstractions to make this distinction, and so a shash is currently the best match. > > - wiring up some essiv(x,y) combinations into the testing framework. I wonder > > if anything other than essiv(aes,sha256) makes sense. > > In cryptsetup testsuite, we test serpent and twofish ciphers at least, but in > reality, essiv(aes,sha256) is the most used combination. > If it makes sense, I can run some tests with dm-crypt and this patchset. > OK, that is helpful, thanks. Mind if I ping you once we reach a state where we need to test for correctness? At the moment, this is still mostly a discussion piece.
[+Cc dm-devel and linux-fscrypt] On Fri, Jun 14, 2019 at 10:34:01AM +0200, Ard Biesheuvel wrote: > This series is presented as an RFC for a couple of reasons: > - it is only build tested > - it is unclear whether this is the right way to move away from the use of > bare ciphers in non-crypto code > - we haven't really discussed whether moving away from the use of bare ciphers > in non-crypto code is a goal we agree on > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > where the digest size of the hash must be a valid key length for the cipher. > The setkey() operation takes the hash of the input key, and sets into the > cipher as the encryption key. Digest operations accept input up to the > block size of the cipher, and perform a single block encryption operation to > produce the ESSIV output. > > This matches what both users of ESSIV in the kernel do, and so it is proposed > as a replacement for those, in patches #2 and #3. > > As for the discussion: the code is untested, so it is presented for discussion > only. I'd like to understand whether we agree that phasing out the bare cipher > interface from non-crypto code is a good idea, and whether this approach is > suitable for fscrypt and dm-crypt. > > Remaining work: > - wiring up some essiv(x,y) combinations into the testing framework. I wonder > if anything other than essiv(aes,sha256) makes sense. > - testing - suggestions welcome on existing testing frameworks for dm-crypt > and/or fscrypt > > Cc: Herbert Xu <herbert@gondor.apana.org.au> > Cc: Eric Biggers <ebiggers@google.com> > > Ard Biesheuvel (3): > crypto: essiv - create a new shash template for IV generation > dm crypt: switch to essiv shash > fscrypt: switch to ESSIV shash > > crypto/Kconfig | 3 + > crypto/Makefile | 1 + > crypto/essiv.c | 275 ++++++++++++++++++++ > drivers/md/Kconfig | 1 + > drivers/md/dm-crypt.c | 137 ++-------- > fs/crypto/Kconfig | 1 + > fs/crypto/crypto.c | 11 +- > fs/crypto/fscrypt_private.h | 4 +- > fs/crypto/keyinfo.c | 64 +---- > 9 files changed, 321 insertions(+), 176 deletions(-) > create mode 100644 crypto/essiv.c I agree that moving away from bare block ciphers is generally a good idea. For fscrypt I'm fine with moving ESSIV into the crypto API, though I'm not sure a shash template is the best approach. Did you also consider making it a skcipher template so that users can do e.g. "essiv(cbc(aes),sha256,aes)"? That would simplify things much more on the fscrypt side, since then all the ESSIV-related code would go away entirely except for changing the string "cbc(aes)" to "essiv(cbc(aes),sha256,aes)". Either way, for testing the fscrypt change, I recently added tests to xfstests that verify the on-disk ciphertext in userspace, including for non-default modes such as the AES-128-CBC-ESSIV in question. So I'm not too worried about the fscrypt encryption getting accidentally broken anymore. If you want to run the AES-128-CBC-ESSIV test yourself, you should be able to do it by following the directions at https://github.com/tytso/xfstests-bld/blob/master/Documentation/kvm-quickstart.md and running 'kvm-xfstests -c ext4 generic/549'. As for adding essiv to testmgr, sha256 and aes would be enough for fscrypt. There aren't any plans to add more ESSIV settings to fscrypt, and AES-128-CBC-ESSIV was only added in the first place because some people wanted to use fscrypt on platforms with CBC hardware acceleration but not XTS. - Eric
[+Cc linux-fscrypt] On Sun, Jun 16, 2019 at 09:13:01PM +0200, Ard Biesheuvel wrote: > > > > - ESSIV is useful only for CBC mode. I wish we move to some better mode > > in the future instead of cementing CBC use... But if it helps people > > to actually use unpredictable IV for CBC, it is the right approach. > > (yes, I know XTS has own problems as well... but IMO that should be the default > > for sector/fs-block encryption these days :) > > > > I agree that XTS should be preferred. But for some reason, the > kernel's XTS implementation does not support ciphertext stealing (as > opposed to, e.g., OpenSSL), and so CBC ended up being used for > encrypting the filenames in fscrypt. > Actually, for fscrypt CTS-CBC was also chosen because all filenames in each directory use the same IV, in order to efficiently support all the possible filesystem operations and to support filenames up to NAME_MAX. So there was a desire for there to be some propagation across ciphertext blocks rather than use XTS which would effectively be ECB in this case. Neither solution is great though, since CBC-CTS still has the common prefix problem. Long-term we're planning to switch to an AES-based wide block mode such as AES-HEH or AES-HCTR for filenames encryption. This is already solved for Adiantum users since Adiantum is a wide-block mode, but there should be a pure AES solution too to go along with AES contents encryption. - Eric
On Sun, Jun 16, 2019 at 11:44 PM Eric Biggers <ebiggers@kernel.org> wrote: > > [+Cc dm-devel and linux-fscrypt] > > On Fri, Jun 14, 2019 at 10:34:01AM +0200, Ard Biesheuvel wrote: > > This series is presented as an RFC for a couple of reasons: > > - it is only build tested > > - it is unclear whether this is the right way to move away from the use of > > bare ciphers in non-crypto code > > - we haven't really discussed whether moving away from the use of bare ciphers > > in non-crypto code is a goal we agree on > > > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > > where the digest size of the hash must be a valid key length for the cipher. > > The setkey() operation takes the hash of the input key, and sets into the > > cipher as the encryption key. Digest operations accept input up to the > > block size of the cipher, and perform a single block encryption operation to > > produce the ESSIV output. ... > I agree that moving away from bare block ciphers is generally a good idea. For > fscrypt I'm fine with moving ESSIV into the crypto API, though I'm not sure a > shash template is the best approach. Did you also consider making it a skcipher > template so that users can do e.g. "essiv(cbc(aes),sha256,aes)"? That would > simplify things much more on the fscrypt side, since then all the ESSIV-related > code would go away entirely except for changing the string "cbc(aes)" to > "essiv(cbc(aes),sha256,aes)". I will also add that going the skcipher route rather than shash will allow hardware tfm providers like CryptoCell that can do the ESSIV part in hardware implement that as a single API call and/or hardware invocation flow. For those system that benefit from hardware providers this can be beneficial. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
On Mon, 17 Jun 2019 at 10:52, Gilad Ben-Yossef <gilad@benyossef.com> wrote: > > On Sun, Jun 16, 2019 at 11:44 PM Eric Biggers <ebiggers@kernel.org> wrote: > > > > [+Cc dm-devel and linux-fscrypt] > > > > On Fri, Jun 14, 2019 at 10:34:01AM +0200, Ard Biesheuvel wrote: > > > This series is presented as an RFC for a couple of reasons: > > > - it is only build tested > > > - it is unclear whether this is the right way to move away from the use of > > > bare ciphers in non-crypto code > > > - we haven't really discussed whether moving away from the use of bare ciphers > > > in non-crypto code is a goal we agree on > > > > > > This series creates an ESSIV shash template that takes a (cipher,hash) tuple, > > > where the digest size of the hash must be a valid key length for the cipher. > > > The setkey() operation takes the hash of the input key, and sets into the > > > cipher as the encryption key. Digest operations accept input up to the > > > block size of the cipher, and perform a single block encryption operation to > > > produce the ESSIV output. > ... > > I agree that moving away from bare block ciphers is generally a good idea. For > > fscrypt I'm fine with moving ESSIV into the crypto API, though I'm not sure a > > shash template is the best approach. Did you also consider making it a skcipher > > template so that users can do e.g. "essiv(cbc(aes),sha256,aes)"? That would > > simplify things much more on the fscrypt side, since then all the ESSIV-related > > code would go away entirely except for changing the string "cbc(aes)" to > > "essiv(cbc(aes),sha256,aes)". > > I will also add that going the skcipher route rather than shash will > allow hardware tfm providers like CryptoCell that can do the ESSIV > part in hardware implement that as a single API call and/or hardware > invocation flow. > For those system that benefit from hardware providers this can be beneficial. > Ah yes, thanks for reminding me. There was some debate in the past about this, but I don't remember the details. I think implementing essiv() as a skcipher template is indeed going to be the best approach, I will look into that.
On Mon, Jun 17, 2019 at 11:15:01AM +0200, Ard Biesheuvel wrote: > > Ah yes, thanks for reminding me. There was some debate in the past > about this, but I don't remember the details. I think there were some controversy regarding whether the resulting code lived in drivers/md or crypto. I think as long as drivers/md is the only user of the said code then having it in drivers/md should be fine. However, if we end up using/reusing the same code for others such as fs/crypto then it might make more sense to have them in crypto. Cheers, -- Email: Herbert Xu <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
On Mon, 17 Jun 2019 at 11:20, Herbert Xu <herbert@gondor.apana.org.au> wrote: > > On Mon, Jun 17, 2019 at 11:15:01AM +0200, Ard Biesheuvel wrote: > > > > Ah yes, thanks for reminding me. There was some debate in the past > > about this, but I don't remember the details. > > I think there were some controversy regarding whether the resulting > code lived in drivers/md or crypto. I think as long as drivers/md > is the only user of the said code then having it in drivers/md should > be fine. > > However, if we end up using/reusing the same code for others such as > fs/crypto then it might make more sense to have them in crypto. > Agreed. We could more easily test it in isolation and ensure parity between different implementations, especially now that we have Eric's improved testing framework that tests against generic implementations.
On 17/06/2019 11:15, Ard Biesheuvel wrote: >> I will also add that going the skcipher route rather than shash will >> allow hardware tfm providers like CryptoCell that can do the ESSIV >> part in hardware implement that as a single API call and/or hardware >> invocation flow. >> For those system that benefit from hardware providers this can be beneficial. >> > > Ah yes, thanks for reminding me. There was some debate in the past > about this, but I don't remember the details. > > I think implementing essiv() as a skcipher template is indeed going to > be the best approach, I will look into that. For ESSIV (that is de-facto standard now), I think there is no problem to move it to crypto API. The problem is with some other IV generators in dm-crypt. Some do a lot of more work than just IV (it is hackish, it can modify data, this applies for loop AES "lmk" and compatible TrueCrypt "tcw" IV implementations). For these I would strongly say it should remain "hacked" inside dm-crypt only (it is unusable for anything else than disk encryption and should not be visible outside). Moreover, it is purely legacy code - we provide it for users can access old systems only. If you end with rewriting all IVs as templates, I think it is not a good idea. If it is only about ESSIV, and patch for dm-crypt is simple, it is a reasonable approach. (The same applies for simple dmcryp IVs like "plain" "plain64", "plain64be and "benbi" that are just linear IVs in various encoded variants.) Milan
On Mon, 17 Jun 2019 at 12:39, Milan Broz <gmazyland@gmail.com> wrote: > > On 17/06/2019 11:15, Ard Biesheuvel wrote: > >> I will also add that going the skcipher route rather than shash will > >> allow hardware tfm providers like CryptoCell that can do the ESSIV > >> part in hardware implement that as a single API call and/or hardware > >> invocation flow. > >> For those system that benefit from hardware providers this can be beneficial. > >> > > > > Ah yes, thanks for reminding me. There was some debate in the past > > about this, but I don't remember the details. > > > > I think implementing essiv() as a skcipher template is indeed going to > > be the best approach, I will look into that. > > For ESSIV (that is de-facto standard now), I think there is no problem > to move it to crypto API. > > The problem is with some other IV generators in dm-crypt. > > Some do a lot of more work than just IV (it is hackish, it can modify data, this applies > for loop AES "lmk" and compatible TrueCrypt "tcw" IV implementations). > > For these I would strongly say it should remain "hacked" inside dm-crypt only > (it is unusable for anything else than disk encryption and should not be visible outside). > > Moreover, it is purely legacy code - we provide it for users can access old systems only. > > If you end with rewriting all IVs as templates, I think it is not a good idea. > > If it is only about ESSIV, and patch for dm-crypt is simple, it is a reasonable approach. > > (The same applies for simple dmcryp IVs like "plain" "plain64", "plain64be and "benbi" that > are just linear IVs in various encoded variants.) > Agreed. I am mostly only interested in ensuring that the bare 'cipher' interface is no longer used outside of the crypto subsystem itself. Since ESSIV is the only one using that, ESSIV is the only one I intend to change.
On Mon, 17 Jun 2019 at 12:58, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > > On Mon, 17 Jun 2019 at 12:39, Milan Broz <gmazyland@gmail.com> wrote: > > > > On 17/06/2019 11:15, Ard Biesheuvel wrote: > > >> I will also add that going the skcipher route rather than shash will > > >> allow hardware tfm providers like CryptoCell that can do the ESSIV > > >> part in hardware implement that as a single API call and/or hardware > > >> invocation flow. > > >> For those system that benefit from hardware providers this can be beneficial. > > >> > > > > > > Ah yes, thanks for reminding me. There was some debate in the past > > > about this, but I don't remember the details. > > > > > > I think implementing essiv() as a skcipher template is indeed going to > > > be the best approach, I will look into that. > > > > For ESSIV (that is de-facto standard now), I think there is no problem > > to move it to crypto API. > > > > The problem is with some other IV generators in dm-crypt. > > > > Some do a lot of more work than just IV (it is hackish, it can modify data, this applies > > for loop AES "lmk" and compatible TrueCrypt "tcw" IV implementations). > > > > For these I would strongly say it should remain "hacked" inside dm-crypt only > > (it is unusable for anything else than disk encryption and should not be visible outside). > > > > Moreover, it is purely legacy code - we provide it for users can access old systems only. > > > > If you end with rewriting all IVs as templates, I think it is not a good idea. > > > > If it is only about ESSIV, and patch for dm-crypt is simple, it is a reasonable approach. > > > > (The same applies for simple dmcryp IVs like "plain" "plain64", "plain64be and "benbi" that > > are just linear IVs in various encoded variants.) > > > > Agreed. > > I am mostly only interested in ensuring that the bare 'cipher' > interface is no longer used outside of the crypto subsystem itself. > Since ESSIV is the only one using that, ESSIV is the only one I intend > to change. OK, so inferring the block cipher name from the skcipher algo name is a bit finicky, since the dm-crypt code does that *after* allocating the TFMs, and allocating the essiv skcipher happens before. But more importantly, it appears to be allowed currently to use ESSIV with authenticated modes, which means we'd need both a skcipher and a aead essiv template, or do some non-trivial hacking to insert the essiv template in the right place (which I'm not sure is even possible) So my main question/showstopper at the moment is: which modes do we need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers and AEADs?
On 17/06/2019 15:59, Ard Biesheuvel wrote: > > So my main question/showstopper at the moment is: which modes do we > need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers > and AEADs? Support, or cover by internal test? I think you nee to support everything what dmcrypt currently allows, if you want to port dmcrypt to new API. I know of many systems that use aes-xts-essiv:sha256 (it does not make sense much but people just use it). Some people use serpent and twofish, but we allow any cipher that fits... For the start, run this https://gitlab.com/cryptsetup/cryptsetup/blob/master/tests/mode-test In other words, if you add some additional limit, we are breaking backward compatibility. (Despite the configuration is "wrong" from the security point of view.) Milan
On Mon, 17 Jun 2019 at 16:35, Milan Broz <gmazyland@gmail.com> wrote: > > On 17/06/2019 15:59, Ard Biesheuvel wrote: > > > > So my main question/showstopper at the moment is: which modes do we > > need to support for ESSIV? Only CBC? Any skcipher? Or both skciphers > > and AEADs? > > Support, or cover by internal test? I think you nee to support everything > what dmcrypt currently allows, if you want to port dmcrypt to new API. > > I know of many systems that use aes-xts-essiv:sha256 (it does not make sense > much but people just use it). > > Some people use serpent and twofish, but we allow any cipher that fits... > Sure, that is all fine > For the start, run this > https://gitlab.com/cryptsetup/cryptsetup/blob/master/tests/mode-test > > In other words, if you add some additional limit, we are breaking backward compatibility. > (Despite the configuration is "wrong" from the security point of view.) > Yes, but breaking backward compatibility only happens if you break something that is actually being *used*. So sure, xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is that also true for, say, gcm(aes)-essiv:sha256 ?
On 17/06/2019 16:39, Ard Biesheuvel wrote: >> >> In other words, if you add some additional limit, we are breaking backward compatibility. >> (Despite the configuration is "wrong" from the security point of view.) >> > > Yes, but breaking backward compatibility only happens if you break > something that is actually being *used*. So sure, > xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is > that also true for, say, gcm(aes)-essiv:sha256 ? These should not be used. The only way when ESSIV can combine with AEAD mode is when you combine length-preserving mode with additional integrity tag, for example # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb it will produce this dm-crypt cipher spec: capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 IV is processed inside dm-crypt as IV. So if authenc() composition is problem, then yes, I am afraid these can be used in reality. But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are not supported by cryptsetup (we support only random IV in this case), so these should not be used anywhere. Milan
On Mon, 17 Jun 2019 at 19:05, Milan Broz <gmazyland@gmail.com> wrote: > > On 17/06/2019 16:39, Ard Biesheuvel wrote: > >> > >> In other words, if you add some additional limit, we are breaking backward compatibility. > >> (Despite the configuration is "wrong" from the security point of view.) > >> > > > > Yes, but breaking backward compatibility only happens if you break > > something that is actually being *used*. So sure, > > xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is > > that also true for, say, gcm(aes)-essiv:sha256 ? > > These should not be used. The only way when ESSIV can combine with AEAD mode > is when you combine length-preserving mode with additional integrity tag, for example > > # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb > > it will produce this dm-crypt cipher spec: > capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 > > the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 > IV is processed inside dm-crypt as IV. > > So if authenc() composition is problem, then yes, I am afraid these can be used in reality. > > But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are > not supported by cryptsetup (we support only random IV in this case), so these should > not be used anywhere. > OK, understood. Unfortunately, that means that the essiv template should be dynamically instantiated as either a aead or a skcipher depending on the context, but perhaps this is not a big deal in reality, I will check. One final question before I can proceed with my v2: in crypt_ctr_blkdev_cipher(), do you think we could change the code to look at the cipher string rather than the name of the actual cipher? In practice, I don't think they can be different, but in order to be able to instantiate 'essiv(authenc(hmac(sha256),cbc(aes)),sha256,aes)', the cipher part needs to be parsed before the TFM(s) are instantiated.
On 17/06/2019 19:29, Ard Biesheuvel wrote: > On Mon, 17 Jun 2019 at 19:05, Milan Broz <gmazyland@gmail.com> wrote: >> >> On 17/06/2019 16:39, Ard Biesheuvel wrote: >>>> >>>> In other words, if you add some additional limit, we are breaking backward compatibility. >>>> (Despite the configuration is "wrong" from the security point of view.) >>>> >>> >>> Yes, but breaking backward compatibility only happens if you break >>> something that is actually being *used*. So sure, >>> xts(aes)-essiv:sha256 makes no sense but people use it anyway. But is >>> that also true for, say, gcm(aes)-essiv:sha256 ? >> >> These should not be used. The only way when ESSIV can combine with AEAD mode >> is when you combine length-preserving mode with additional integrity tag, for example >> >> # cryptsetup luksFormat -c aes-cbc-essiv:sha256 --integrity hmac-sha256 /dev/sdb >> >> it will produce this dm-crypt cipher spec: >> capi:authenc(hmac(sha256),cbc(aes))-essiv:sha256 >> >> the authenc(hmac(sha256),cbc(aes)) is direct crypto API cipher composition, the essiv:sha256 >> IV is processed inside dm-crypt as IV. >> >> So if authenc() composition is problem, then yes, I am afraid these can be used in reality. >> >> But for things like gcm(aes)-essiv:sha256 (IOW real AEAD mode with ESSIV) - these are >> not supported by cryptsetup (we support only random IV in this case), so these should >> not be used anywhere. >> > > OK, understood. Unfortunately, that means that the essiv template > should be dynamically instantiated as either a aead or a skcipher > depending on the context, but perhaps this is not a big deal in > reality, I will check. > > One final question before I can proceed with my v2: in > crypt_ctr_blkdev_cipher(), do you think we could change the code to > look at the cipher string rather than the name of the actual cipher? > In practice, I don't think they can be different, but in order to be > able to instantiate > 'essiv(authenc(hmac(sha256),cbc(aes)),sha256,aes)', the cipher part > needs to be parsed before the TFM(s) are instantiated. You mean to replace crypto_tfm_alg_name() with the cipher string from the device-mapper table constructor? I hope I am not missing anything, but it should be ok. It just could fail later (in tfm init). The constructor is de-facto atomic step for device-mapper, I think it does not matter when it fails, the effect of failure is the same for userspace. Milan