From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: linux-crypto@vger.kernel.org
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>,
Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@google.com>,
dm-devel@redhat.com, linux-fscrypt@vger.kernel.org,
Gilad Ben-Yossef <gilad@benyossef.com>,
Milan Broz <gmazyland@gmail.com>
Subject: [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation
Date: Thu, 4 Jul 2019 20:30:10 +0200 [thread overview]
Message-ID: <20190704183017.31570-1-ard.biesheuvel@linaro.org> (raw)
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
(or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
encapsulated sync or async skcipher/aead by passing through all operations,
while using the cipher/shash pair to transform the input IV into an ESSIV
output IV.
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 #4.
Note to the maintainer: patches #2 .. #4 are against other subsystems, and
so it might make sense to take only the crypto patches (#1, #5, and optionally
#6 and #7) now, and allow the other subsystem maintainers to take the other
patches at their leisure during the next cycle.
This code has been tested using the fscrypt test suggested by Eric
(generic/549 *), as well as the mode-test scripts suggested by Milan for
the dm-crypt case. I also tested the aead case in a virtual machine,
but it definitely needs some wider testing from the dm-crypt experts.
* due to sloppiness on my part, the fscrypt change was actually broken
since I switched back to using full size IVs in the ESSIV template.
This time, I fixed this, and reran the test in question and it passed.
The consensus appears to be that it would be useful if the crypto API
encapsulates the handling of multiple subsequent blocks that are
encrypted using a 64-bit LE counter as IV, and makes it the duty of
the algo to increment the counter between blocks. However, this is
equally suitable for non-ESSIV transforms (or even more so), and so
this is left as a future enhancement to be applied on top.
Changes since v7:
- rebase onto cryptodev/master
- drop change to ivsize in #2
- add Milan's R-b's
Changes since v6:
- make CRYPTO_ESSIV user selectable so we can opt out of selecting it even
if FS_ENCRYPTION (which cannot be built as a module) is enabled
- move a comment along with the code it referred to (#3), not that this change
and removing some redundant braces makes the diff look totally different
- add Milan's R-b to #3 and #4
Changes since v5:
- drop redundant #includes and drop some unneeded braces (#2)
- add test case for essiv(authenc(hmac(sha256),cbc(aes)),aes,sha256)
- make ESSIV driver deal with assoc data that is described by more than two
scatterlist entries - this only happens when the extended tests are being
performed, so don't optimize for it
- clarify that both fscrypt and dm-crypt only use ESSIV in special cases (#7)
Changes since v4:
- make the ESSIV template IV size equal the IV size of the encapsulated
cipher - defining it as 8 bytes was needlessly restrictive, and also
complicated the code for no reason
- add a missing kfree() spotted by Smatch
- add additional algo length name checks when constructing the essiv()
cipher name
- reinstate the 'essiv' IV generation implementation in dm-crypt, but
make its generation function identical to plain64le (and drop the other
methods)
- fix a bug in the arm64 CE/NEON code
- simplify the arm64 code by reusing more of the existing CBC implementation
(patch #6 is new to this series and was added for this reason)
Changes since v3:
- address various review comments from Eric on patch #1
- use Kconfig's 'imply' instead of 'select' to permit CRYPTO_ESSIV to be
enabled as a module or disabled entirely even if fscrypt is compiled in (#2)
- fix an issue in the AEAD encrypt path caused by the IV being clobbered by
the inner skcipher before the hmac was being calculated
Changes since v2:
- fixed a couple of bugs that snuck in after I'd done the bulk of my
testing
- some cosmetic tweaks to the ESSIV template skcipher setkey function
to align it with the aead one
- add a test case for essiv(cbc(aes),aes,sha256)
- add an accelerated implementation for arm64 that combines the IV
derivation and the actual en/decryption in a single asm routine
Scroll down for tcrypt speed test result comparing the essiv template
with the asm implementation. Bare cbc(aes) tests included for reference
as well. Taken on a 2GHz Cortex-A57 (AMD Seattle)
Code can be found here
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v8
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@google.com>
Cc: dm-devel@redhat.com
Cc: linux-fscrypt@vger.kernel.org
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Milan Broz <gmazyland@gmail.com>
Ard Biesheuvel (7):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher from cipher string directly
md: dm-crypt: switch to ESSIV crypto API template
crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256)
crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk
crypto: arm64/aes - implement accelerated ESSIV/CBC mode
arch/arm64/crypto/aes-glue.c | 205 +++++--
arch/arm64/crypto/aes-modes.S | 29 +-
crypto/Kconfig | 28 +
crypto/Makefile | 1 +
crypto/essiv.c | 640 ++++++++++++++++++++
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 14 +
crypto/testmgr.h | 497 +++++++++++++++
drivers/md/Kconfig | 1 +
drivers/md/dm-crypt.c | 235 ++-----
fs/crypto/Kconfig | 1 +
fs/crypto/crypto.c | 5 -
fs/crypto/fscrypt_private.h | 9 -
fs/crypto/keyinfo.c | 93 +--
14 files changed, 1435 insertions(+), 332 deletions(-)
create mode 100644 crypto/essiv.c
--
2.17.1
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: linux-crypto@vger.kernel.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@google.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux-fscrypt@vger.kernel.org,
Gilad Ben-Yossef <gilad@benyossef.com>,
dm-devel@redhat.com, Milan Broz <gmazyland@gmail.com>
Subject: [dm-devel] [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation
Date: Thu, 4 Jul 2019 20:30:10 +0200 [thread overview]
Message-ID: <20190704183017.31570-1-ard.biesheuvel@linaro.org> (raw)
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
(or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
encapsulated sync or async skcipher/aead by passing through all operations,
while using the cipher/shash pair to transform the input IV into an ESSIV
output IV.
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 #4.
Note to the maintainer: patches #2 .. #4 are against other subsystems, and
so it might make sense to take only the crypto patches (#1, #5, and optionally
#6 and #7) now, and allow the other subsystem maintainers to take the other
patches at their leisure during the next cycle.
This code has been tested using the fscrypt test suggested by Eric
(generic/549 *), as well as the mode-test scripts suggested by Milan for
the dm-crypt case. I also tested the aead case in a virtual machine,
but it definitely needs some wider testing from the dm-crypt experts.
* due to sloppiness on my part, the fscrypt change was actually broken
since I switched back to using full size IVs in the ESSIV template.
This time, I fixed this, and reran the test in question and it passed.
The consensus appears to be that it would be useful if the crypto API
encapsulates the handling of multiple subsequent blocks that are
encrypted using a 64-bit LE counter as IV, and makes it the duty of
the algo to increment the counter between blocks. However, this is
equally suitable for non-ESSIV transforms (or even more so), and so
this is left as a future enhancement to be applied on top.
Changes since v7:
- rebase onto cryptodev/master
- drop change to ivsize in #2
- add Milan's R-b's
Changes since v6:
- make CRYPTO_ESSIV user selectable so we can opt out of selecting it even
if FS_ENCRYPTION (which cannot be built as a module) is enabled
- move a comment along with the code it referred to (#3), not that this change
and removing some redundant braces makes the diff look totally different
- add Milan's R-b to #3 and #4
Changes since v5:
- drop redundant #includes and drop some unneeded braces (#2)
- add test case for essiv(authenc(hmac(sha256),cbc(aes)),aes,sha256)
- make ESSIV driver deal with assoc data that is described by more than two
scatterlist entries - this only happens when the extended tests are being
performed, so don't optimize for it
- clarify that both fscrypt and dm-crypt only use ESSIV in special cases (#7)
Changes since v4:
- make the ESSIV template IV size equal the IV size of the encapsulated
cipher - defining it as 8 bytes was needlessly restrictive, and also
complicated the code for no reason
- add a missing kfree() spotted by Smatch
- add additional algo length name checks when constructing the essiv()
cipher name
- reinstate the 'essiv' IV generation implementation in dm-crypt, but
make its generation function identical to plain64le (and drop the other
methods)
- fix a bug in the arm64 CE/NEON code
- simplify the arm64 code by reusing more of the existing CBC implementation
(patch #6 is new to this series and was added for this reason)
Changes since v3:
- address various review comments from Eric on patch #1
- use Kconfig's 'imply' instead of 'select' to permit CRYPTO_ESSIV to be
enabled as a module or disabled entirely even if fscrypt is compiled in (#2)
- fix an issue in the AEAD encrypt path caused by the IV being clobbered by
the inner skcipher before the hmac was being calculated
Changes since v2:
- fixed a couple of bugs that snuck in after I'd done the bulk of my
testing
- some cosmetic tweaks to the ESSIV template skcipher setkey function
to align it with the aead one
- add a test case for essiv(cbc(aes),aes,sha256)
- add an accelerated implementation for arm64 that combines the IV
derivation and the actual en/decryption in a single asm routine
Scroll down for tcrypt speed test result comparing the essiv template
with the asm implementation. Bare cbc(aes) tests included for reference
as well. Taken on a 2GHz Cortex-A57 (AMD Seattle)
Code can be found here
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v8
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@google.com>
Cc: dm-devel@redhat.com
Cc: linux-fscrypt@vger.kernel.org
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Milan Broz <gmazyland@gmail.com>
Ard Biesheuvel (7):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher from cipher string directly
md: dm-crypt: switch to ESSIV crypto API template
crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256)
crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk
crypto: arm64/aes - implement accelerated ESSIV/CBC mode
arch/arm64/crypto/aes-glue.c | 205 +++++--
arch/arm64/crypto/aes-modes.S | 29 +-
crypto/Kconfig | 28 +
crypto/Makefile | 1 +
crypto/essiv.c | 640 ++++++++++++++++++++
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 14 +
crypto/testmgr.h | 497 +++++++++++++++
drivers/md/Kconfig | 1 +
drivers/md/dm-crypt.c | 235 ++-----
fs/crypto/Kconfig | 1 +
fs/crypto/crypto.c | 5 -
fs/crypto/fscrypt_private.h | 9 -
fs/crypto/keyinfo.c | 93 +--
14 files changed, 1435 insertions(+), 332 deletions(-)
create mode 100644 crypto/essiv.c
--
2.17.1
--
dm-devel mailing list
dm-devel@redhat.com
https://www.redhat.com/mailman/listinfo/dm-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: linux-crypto@vger.kernel.org
Cc: Herbert Xu <herbert@gondor.apana.org.au>,
Eric Biggers <ebiggers@google.com>,
Ard Biesheuvel <ard.biesheuvel@linaro.org>,
linux-fscrypt@vger.kernel.org,
Gilad Ben-Yossef <gilad@benyossef.com>,
dm-devel@redhat.com, Milan Broz <gmazyland@gmail.com>
Subject: [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation
Date: Thu, 4 Jul 2019 20:30:10 +0200 [thread overview]
Message-ID: <20190704183017.31570-1-ard.biesheuvel@linaro.org> (raw)
This series creates an ESSIV template that produces a skcipher or AEAD
transform based on a tuple of the form '<skcipher>,<cipher>,<shash>'
(or '<aead>,<cipher>,<shash>' for the AEAD case). It exposes the
encapsulated sync or async skcipher/aead by passing through all operations,
while using the cipher/shash pair to transform the input IV into an ESSIV
output IV.
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 #4.
Note to the maintainer: patches #2 .. #4 are against other subsystems, and
so it might make sense to take only the crypto patches (#1, #5, and optionally
#6 and #7) now, and allow the other subsystem maintainers to take the other
patches at their leisure during the next cycle.
This code has been tested using the fscrypt test suggested by Eric
(generic/549 *), as well as the mode-test scripts suggested by Milan for
the dm-crypt case. I also tested the aead case in a virtual machine,
but it definitely needs some wider testing from the dm-crypt experts.
* due to sloppiness on my part, the fscrypt change was actually broken
since I switched back to using full size IVs in the ESSIV template.
This time, I fixed this, and reran the test in question and it passed.
The consensus appears to be that it would be useful if the crypto API
encapsulates the handling of multiple subsequent blocks that are
encrypted using a 64-bit LE counter as IV, and makes it the duty of
the algo to increment the counter between blocks. However, this is
equally suitable for non-ESSIV transforms (or even more so), and so
this is left as a future enhancement to be applied on top.
Changes since v7:
- rebase onto cryptodev/master
- drop change to ivsize in #2
- add Milan's R-b's
Changes since v6:
- make CRYPTO_ESSIV user selectable so we can opt out of selecting it even
if FS_ENCRYPTION (which cannot be built as a module) is enabled
- move a comment along with the code it referred to (#3), not that this change
and removing some redundant braces makes the diff look totally different
- add Milan's R-b to #3 and #4
Changes since v5:
- drop redundant #includes and drop some unneeded braces (#2)
- add test case for essiv(authenc(hmac(sha256),cbc(aes)),aes,sha256)
- make ESSIV driver deal with assoc data that is described by more than two
scatterlist entries - this only happens when the extended tests are being
performed, so don't optimize for it
- clarify that both fscrypt and dm-crypt only use ESSIV in special cases (#7)
Changes since v4:
- make the ESSIV template IV size equal the IV size of the encapsulated
cipher - defining it as 8 bytes was needlessly restrictive, and also
complicated the code for no reason
- add a missing kfree() spotted by Smatch
- add additional algo length name checks when constructing the essiv()
cipher name
- reinstate the 'essiv' IV generation implementation in dm-crypt, but
make its generation function identical to plain64le (and drop the other
methods)
- fix a bug in the arm64 CE/NEON code
- simplify the arm64 code by reusing more of the existing CBC implementation
(patch #6 is new to this series and was added for this reason)
Changes since v3:
- address various review comments from Eric on patch #1
- use Kconfig's 'imply' instead of 'select' to permit CRYPTO_ESSIV to be
enabled as a module or disabled entirely even if fscrypt is compiled in (#2)
- fix an issue in the AEAD encrypt path caused by the IV being clobbered by
the inner skcipher before the hmac was being calculated
Changes since v2:
- fixed a couple of bugs that snuck in after I'd done the bulk of my
testing
- some cosmetic tweaks to the ESSIV template skcipher setkey function
to align it with the aead one
- add a test case for essiv(cbc(aes),aes,sha256)
- add an accelerated implementation for arm64 that combines the IV
derivation and the actual en/decryption in a single asm routine
Scroll down for tcrypt speed test result comparing the essiv template
with the asm implementation. Bare cbc(aes) tests included for reference
as well. Taken on a 2GHz Cortex-A57 (AMD Seattle)
Code can be found here
https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=essiv-v8
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: Eric Biggers <ebiggers@google.com>
Cc: dm-devel@redhat.com
Cc: linux-fscrypt@vger.kernel.org
Cc: Gilad Ben-Yossef <gilad@benyossef.com>
Cc: Milan Broz <gmazyland@gmail.com>
Ard Biesheuvel (7):
crypto: essiv - create wrapper template for ESSIV generation
fs: crypto: invoke crypto API for ESSIV handling
md: dm-crypt: infer ESSIV block cipher from cipher string directly
md: dm-crypt: switch to ESSIV crypto API template
crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256)
crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk
crypto: arm64/aes - implement accelerated ESSIV/CBC mode
arch/arm64/crypto/aes-glue.c | 205 +++++--
arch/arm64/crypto/aes-modes.S | 29 +-
crypto/Kconfig | 28 +
crypto/Makefile | 1 +
crypto/essiv.c | 640 ++++++++++++++++++++
crypto/tcrypt.c | 9 +
crypto/testmgr.c | 14 +
crypto/testmgr.h | 497 +++++++++++++++
drivers/md/Kconfig | 1 +
drivers/md/dm-crypt.c | 235 ++-----
fs/crypto/Kconfig | 1 +
fs/crypto/crypto.c | 5 -
fs/crypto/fscrypt_private.h | 9 -
fs/crypto/keyinfo.c | 93 +--
14 files changed, 1435 insertions(+), 332 deletions(-)
create mode 100644 crypto/essiv.c
--
2.17.1
next reply other threads:[~2019-07-04 18:30 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-04 18:30 Ard Biesheuvel [this message]
2019-07-04 18:30 ` [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 1/7] crypto: essiv - create wrapper template " Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-26 4:31 ` Herbert Xu
2019-07-26 4:31 ` Herbert Xu
2019-07-26 4:31 ` [dm-devel] " Herbert Xu
2019-07-26 9:00 ` Ard Biesheuvel
2019-07-26 9:00 ` Ard Biesheuvel
2019-07-26 9:00 ` Ard Biesheuvel
2019-08-02 3:55 ` Herbert Xu
2019-08-02 3:55 ` Herbert Xu
2019-08-02 3:55 ` [dm-devel] " Herbert Xu
2019-08-03 7:36 ` Ard Biesheuvel
2019-08-03 7:36 ` Ard Biesheuvel
2019-08-03 7:36 ` [dm-devel] " Ard Biesheuvel
2019-08-15 2:30 ` Herbert Xu
2019-08-15 2:30 ` Herbert Xu
2019-08-15 2:30 ` Herbert Xu
2019-07-04 18:30 ` [PATCH v8 2/7] fs: crypto: invoke crypto API for ESSIV handling Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 3/7] md: dm-crypt: infer ESSIV block cipher from cipher string directly Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 4/7] md: dm-crypt: switch to ESSIV crypto API template Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 5/7] crypto: essiv - add test vector for essiv(cbc(aes),aes,sha256) Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 5/7] crypto: essiv - add test vector for essiv(cbc(aes), aes, sha256) Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 6/7] crypto: arm64/aes-cts-cbc - factor out CBC en/decryption of a walk Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-04 18:30 ` [PATCH v8 7/7] crypto: arm64/aes - implement accelerated ESSIV/CBC mode Ard Biesheuvel
2019-07-04 18:30 ` Ard Biesheuvel
2019-07-04 18:30 ` [dm-devel] " Ard Biesheuvel
2019-07-05 6:35 ` [PATCH v8 0/7] crypto: switch to crypto API for ESSIV generation Ard Biesheuvel
2019-07-05 6:35 ` Ard Biesheuvel
2019-07-05 6:35 ` [dm-devel] " Ard Biesheuvel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20190704183017.31570-1-ard.biesheuvel@linaro.org \
--to=ard.biesheuvel@linaro.org \
--cc=dm-devel@redhat.com \
--cc=ebiggers@google.com \
--cc=gilad@benyossef.com \
--cc=gmazyland@gmail.com \
--cc=herbert@gondor.apana.org.au \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-fscrypt@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.