Re: [Qemu-devel] [PATCH v4 09/26] crypto: import an implementation of the XTS cipher mode

[Eric Blake <eblake@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 3803 bytes --]

On 02/29/2016 05:00 AM, Daniel P. Berrange wrote:
> The XTS (XEX with tweaked-codebook and ciphertext stealing)
> cipher mode is commonly used in full disk encryption. There
> is unfortunately no implementation of it in either libgcrypt
> or nettle, so we need to provide our own.
> 
> The libtomcrypt project provides a repository of crypto
> algorithms under a choice of either "public domain" or
> the "what the fuck public license".
> 
> So this impl is taken from the libtomcrypt GIT repo and
> adapted to be compatible with the way we need to call
> ciphers provided by nettle/gcrypt.
> 
> Signed-off-by: Daniel P. Berrange <berrange@redhat.com>
> ---

> +++ b/crypto/xts.c
> @@ -0,0 +1,256 @@
> +/*
> + * QEMU Crypto XTS cipher mode
> + *
> + * Copyright (c) 2015 Red Hat, Inc.

Want to add 2016?

> +
> +#include "qemu/osdep.h"
> +#include "crypto/xts.h"
> +
> +static void xts_mult_x(uint8_t *I)
> +{
> +    int x;
> +    uint8_t t, tt;
> +
> +    for (x = t = 0; x < 16; x++) {
> +        tt = I[x] >> 7;
> +        I[x] = ((I[x] << 1) | t) & 0xFF;

Why '& 0xf'f? I[x] is already an 8-bit field.  But since it is a direct
copy from
https://github.com/libtom/libtomcrypt/blob/develop/src/modes/xts/xts_mult_x.c,
I won't reject it.  (I could understand the mask if the original code
were using uint_fast8_t for speed at the expense of worrying about
potential padding bits, but no one does that in crypto...)


> +/**
> + * xts_tweak_uncrypt:
> + * @param ctxt: the cipher context
> + * @param func: the cipher function
> + * @src: buffer providing the cipher text of XTS_BLOCK_SIZE bytes
> + * @dst: buffer to output the plain text of XTS_BLOCK_SIZE bytes
> + * @iv: the initialization vector tweak of XTS_BLOCK_SIZE bytes
> + *
> + * Decrypt data with a tweak
> + */
> +static void xts_tweak_decrypt(const void *ctx,
> +                              xts_cipher_func *func,
> +                              const uint8_t *src,
> +                              uint8_t *dst,
> +                              uint8_t *iv)
> +{
> +    unsigned long x;
> +
> +    /* tweak encrypt block i */
> +#ifdef LTC_FAST
> +    for (x = 0; x < XTS_BLOCK_SIZE; x += sizeof(LTC_FAST_TYPE)) {
> +        *((LTC_FAST_TYPE *)&dst[x]) =
> +            *((LTC_FAST_TYPE *)&src[x]) ^ *((LTC_FAST_TYPE *)&iv[x]);
> +    }

Nothing in our configure sets LTC_FAST and friends; should we just nuke
these expressions as dead code?  I see the point of what it is trying to
do: if the data is aligned (or if the processor doesn't care about
alignment), then vectorize it...

> +#else
> +    for (x = 0; x < XTS_BLOCK_SIZE; x++) {
> +        dst[x] = src[x] ^ iv[x];
> +    }

...but we've already argued that the compiler should be able to
auto-vectorize, or at least that hot-path tweaking can be done later.


> +void xts_decrypt(const void *datactx,
> +                 const void *tweakctx,

> +
> +    /* if length not divide XTS_BLOCK_SIZE then */
> +    if (mo > 0) {

If length is not a multiple of XTS_BLOCK_SIZE, then


> +void xts_encrypt(const void *datactx,
> +                 const void *tweakctx,

> +
> +    /* if length not divide XTS_BLOCK_SIZE then */

and again

> +++ b/include/crypto/xts.h
> @@ -0,0 +1,86 @@
> +/*
> + * QEMU Crypto XTS cipher mode
> + *
> + * Copyright (c) 2015 Red Hat, Inc.

2016


> +++ b/tests/test-crypto-xts.c
> @@ -0,0 +1,423 @@
> +/*
> + * QEMU Crypto XTS cipher mode
> + *
> + * Copyright (c) 2015 Red Hat, Inc.

and again

Modulo comment tweaks and a decision about whether to nuke LTC_FAST,
Reviewed-by: Eric Blake <eblake@redhat.com>

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 604 bytes --]