| Message ID | 20201029100546.28686-1-gilad@benyossef.com |
|---|---|
| Headers | show |
| Series | crypto: switch to crypto API for EBOIV generation | expand |
On 29/10/2020 11:05, Gilad Ben-Yossef wrote: > > +config CRYPTO_EBOIV > + tristate "EBOIV support for block encryption" > + default DM_CRYPT > + select CRYPTO_CBC > + help > + Encrypted byte-offset initialization vector (EBOIV) is an IV > + generation method that is used in some cases by dm-crypt for > + supporting the BitLocker volume encryption used by Windows 8 > + and onwards as a backwards compatible version in lieu of XTS > + support. > + > + It uses the block encryption key as the symmetric key for a > + block encryption pass applied to the sector offset of the block. > + Additional details can be found at > + https://www.jedec.org/sites/default/files/docs/JESD223C.pdf This page is not available. Are you sure this is the proper documentation? I think the only description we used (for dm-crypt) was original Ferguson's Bitlocker doc: https://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/bitlockercipher200608.pdf IIRC EBOIV was a shortcut I added to dm-crypt because we found no official terminology for this IV. And after lunchtime, nobody invented anything better, so it stayed as it is now :-) Milan
Hi, On Fri, Oct 30, 2020 at 12:33 PM Milan Broz <gmazyland@gmail.com> wrote: > > On 29/10/2020 11:05, Gilad Ben-Yossef wrote: > > > > +config CRYPTO_EBOIV > > + tristate "EBOIV support for block encryption" > > + default DM_CRYPT > > + select CRYPTO_CBC > > + help > > + Encrypted byte-offset initialization vector (EBOIV) is an IV > > + generation method that is used in some cases by dm-crypt for > > + supporting the BitLocker volume encryption used by Windows 8 > > + and onwards as a backwards compatible version in lieu of XTS > > + support. > > + > > + It uses the block encryption key as the symmetric key for a > > + block encryption pass applied to the sector offset of the block. > > + Additional details can be found at > > + https://www.jedec.org/sites/default/files/docs/JESD223C.pdf > > This page is not available. Are you sure this is the proper documentation? You need to register at the JEDEC web site to get the PDF. The registration is free though. It's the only standard I am aware of that describe this mode, as opposed to a paper. > > I think the only description we used (for dm-crypt) was original Ferguson's Bitlocker doc: > https://download.microsoft.com/download/0/2/3/0238acaf-d3bf-4a6d-b3d6-0a0be4bbb36e/bitlockercipher200608.pdf Yes, the JEDEC has a reference to that as well, but the white paper doesn't actually describe the option without the diffuser. > > IIRC EBOIV was a shortcut I added to dm-crypt because we found no official terminology for this IV. > And after lunchtime, nobody invented anything better, so it stayed as it is now :-) Well, I still don't have any better name to offer, LOL :-) Gilad
Hi, On Thu, Oct 29, 2020 at 12:05 PM Gilad Ben-Yossef <gilad@benyossef.com> wrote: > > > This series creates an EBOIV template that produces a skcipher > transform which passes through all operations to the skcipher, while > using the same skcipher and key to encrypt the input IV, which is > assumed to be a sector offset, although this is not enforced. I hope I didn't miss anything, but it seems I didn't get an ACK, NACK or request of changes to the latest iteration. Any feedback is very much welcome. Thanks, Gilad -- Gilad Ben-Yossef Chief Coffee Drinker values of β will give rise to dom!
This series creates an EBOIV template that produces a skcipher transform which passes through all operations to the skcipher, while using the same skcipher and key to encrypt the input IV, which is assumed to be a sector offset, although this is not enforced. This matches dm-crypt use of EBOIV to provide BitLocker support, and so it is proposed as a replacement in patch #3. Replacing the dm-crypt specific EBOIV implementation to a Crypto API based one allows us to save a memory allocation per each request, as well as opening the way for use of compatible alternative transform providers, one of which, based on the Arm TrustZone CryptoCell hardware, is proposed as patch #4. Future potential work to allow encapsulating the handling of multiple subsequent blocks by the Crypto API may also benefit from this work. The code has been tested on both x86_64 virtual machine with the dm-crypt test suite and on an arm 32 bit board with the CryptoCell hardware. Since no offical source for eboiv test vectors is known, the test vectors supplied as patch #2 are derived from sectors which are part of the dm-crypt test suite. Signed-off-by: Gilad Ben-Yossef <gilad@benyossef.com> Cc: Eric Biggers <ebiggers@kernel.org> Cc: Milan Broz <gmazyland@gmail.com> Changes from v2: - Remove needless internal include left over by mistake. Changes from v1: - Incorporated feedback from Eric Biggers regarding eboiv template code. - Incorporated fixes for issues found by kernel test robot. - Moved from a Kconfig dependency of DM_CRYPT to EBOIV to EBOIV default of DM_CRYPT as suggested by Herbert Xu. Gilad Ben-Yossef (4): crypto: add eboiv as a crypto API template crypto: add eboiv(cbc(aes)) test vectors dm crypt: switch to EBOIV crypto API template crypto: ccree: re-introduce ccree eboiv support crypto/Kconfig | 23 +++ crypto/Makefile | 1 + crypto/eboiv.c | 269 ++++++++++++++++++++++++++ crypto/tcrypt.c | 9 + crypto/testmgr.c | 6 + crypto/testmgr.h | 279 +++++++++++++++++++++++++++ drivers/crypto/ccree/cc_cipher.c | 132 +++++++++---- drivers/crypto/ccree/cc_crypto_ctx.h | 1 + drivers/md/dm-crypt.c | 61 ++---- 9 files changed, 702 insertions(+), 79 deletions(-) create mode 100644 crypto/eboiv.c