Re: [dm-crypt] Encryption speed and reversing the direction

Re: [dm-crypt] Encryption speed and reversing the direction

[Eric Biggers]

On Tue, Aug 25, 2020 at 02:05:35AM -0400, John Lee McMahon wrote:
> Hello,
> 
> I would like to ask for some clarifications regarding randomness and speed
> of encrypted data, and consequences of reversing the direction of the
> encryption. Sorry for a long email, but I think the issues are related so
> it is better than separate emails. My questions are related to the answers
> I found in https://www.saout.de/pipermail/dm-crypt/2020-June/006531.html
> 
> I was under the assumption that the result of block device encryption
> should be indistinguishable from random data. If the encryption (data
> transformation) is supposed to work in both directions, it should produce
> random like output, correct?
> 
> echo "0 100000000 zero" | dmsetup create zero1
> echo "0 $(blockdev --getsize /dev/mapper/zero1) crypt \
>  aes-xts-plain64:sha512 $(sha512sum /proc/sys/kernel/random/uuid | cut -b
> 1-128) \
>  0 /dev/mapper/zero1 0" | dmsetup create crypto1
> rngtest -b 10000 < /dev/mapper/crypto1
> dieharder -a -g 200 < /dev/mapper/crypto1
> (failures/weak results seem comparable to /dev/urandom,
> or can you see a measurable difference?)

"aes-xts-plain64:sha512" doesn't make sense.  It should be "aes-xts-plain64".

> 
> echo "0 100000000 zero" | dmsetup create zero2
> echo "0 $(blockdev --getsize /dev/mapper/zero2) crypt \
>  aes-cbc-essiv:sha256 $(sha256sum /proc/sys/kernel/random/uuid | cut -b
> 1-64) \
>  0 /dev/mapper/zero2 0" | dmsetup create crypto2
> rngtest -b 10000 < /dev/mapper/crypto2
> (just failures, the data is visible pattern)
> 
> Is the reversed encryption strong? Why is the reversed
> aes-xts-plain64:sha512 generating random like output, but the reversed
> aes-cbc-essiv:sha256 is a pattern? Is there an explanation?

Unlike XTS mode, CBC mode doesn't emulate a tweakable block cipher.  CBC just
encrypts each plaintext block XOR'ed with the previous ciphertext block.

Or equivalently, CBC decrypts each ciphertext block by decrypting it with the
block cipher, then XOR'ing in the previous block of ciphertext.

So for an artificial ciphertext where every ciphertext block is the same, every
plaintext block except the first will be the same.

> The reverse aes-xts-plain64:sha512 is quite fast (I tested on Dell Optiplex
> 3020, quad Core i5-4590 3.30GHz, AESNI, kernel 4.14.150)
> 
> pv /dev/mapper/crypto1 > /dev/null
> (1.8 GB/sec, for previous aes-xts-plain64:sha512 dm-crypt table)
> 
> When I compare to other ways of generating random data, I get:
> 
> openssl enc -chacha20 -nosalt -pass file:/proc/sys/kernel/random/uuid \
>   < /dev/zero | pv > /dev/null
> (1.6 GB/sec)
> 
> /dev/urandom gives me 245 MB/sec on the same hardware
> 
> TrueRNG v3 produces 50KB/sec
> (https://www.amazon.com/TrueRNG-V3-Hardware-Random-Generator/dp/B01KR2JHTA)
> 
> I do not know about any faster way of generating good pseudo-random data
> than aes-xts-plain64:sha512 dm-crypt table. But on the list it was said
> that /dev/urandom has gotten a lot faster. Am I missing something why
> /dev/urandom is slow for me? Could I be missing any important kernel
> options?

Using AES-XTS to generate random numbers is weird.  Also if you actually care
about random number generation performance, you shouldn't be going through the
kernel at all, except to read an initial seed.  Just read some bytes from
/dev/urandom and use it to seed your own PRNG in userspace that uses a suitable
algorithm like AES-CTR or ChaCha20.  If it is appropriately optimized, it will
be faster than reading anything via kernel system calls.

- Eric

[dm-crypt] Encryption speed and reversing the direction

[John Lee McMahon]

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

Hello,

I would like to ask for some clarifications regarding randomness and speed
of encrypted data, and consequences of reversing the direction of the
encryption. Sorry for a long email, but I think the issues are related so
it is better than separate emails. My questions are related to the answers
I found in https://www.saout.de/pipermail/dm-crypt/2020-June/006531.html

I was under the assumption that the result of block device encryption
should be indistinguishable from random data. If the encryption (data
transformation) is supposed to work in both directions, it should produce
random like output, correct?

echo "0 100000000 zero" | dmsetup create zero1
echo "0 $(blockdev --getsize /dev/mapper/zero1) crypt \
 aes-xts-plain64:sha512 $(sha512sum /proc/sys/kernel/random/uuid | cut -b
1-128) \
 0 /dev/mapper/zero1 0" | dmsetup create crypto1
rngtest -b 10000 < /dev/mapper/crypto1
dieharder -a -g 200 < /dev/mapper/crypto1
(failures/weak results seem comparable to /dev/urandom,
or can you see a measurable difference?)

echo "0 100000000 zero" | dmsetup create zero2
echo "0 $(blockdev --getsize /dev/mapper/zero2) crypt \
 aes-cbc-essiv:sha256 $(sha256sum /proc/sys/kernel/random/uuid | cut -b
1-64) \
 0 /dev/mapper/zero2 0" | dmsetup create crypto2
rngtest -b 10000 < /dev/mapper/crypto2
(just failures, the data is visible pattern)

Is the reversed encryption strong? Why is the reversed
aes-xts-plain64:sha512 generating random like output, but the reversed
aes-cbc-essiv:sha256 is a pattern? Is there an explanation?



The reverse aes-xts-plain64:sha512 is quite fast (I tested on Dell Optiplex
3020, quad Core i5-4590 3.30GHz, AESNI, kernel 4.14.150)

pv /dev/mapper/crypto1 > /dev/null
(1.8 GB/sec, for previous aes-xts-plain64:sha512 dm-crypt table)

When I compare to other ways of generating random data, I get:

openssl enc -chacha20 -nosalt -pass file:/proc/sys/kernel/random/uuid \
  < /dev/zero | pv > /dev/null
(1.6 GB/sec)

/dev/urandom gives me 245 MB/sec on the same hardware

TrueRNG v3 produces 50KB/sec
(https://www.amazon.com/TrueRNG-V3-Hardware-Random-Generator/dp/B01KR2JHTA)

I do not know about any faster way of generating good pseudo-random data
than aes-xts-plain64:sha512 dm-crypt table. But on the list it was said
that /dev/urandom has gotten a lot faster. Am I missing something why
/dev/urandom is slow for me? Could I be missing any important kernel
options?

If I wanted to generate RSA key pairs I would go with a hardware generator,
but if I want to fill a large space with pseudo-random noise quickly then
aes-xts-plain64:sha512 table seems to be the fastest way. Or am I wrong?



I also do not understand why the AESNI encryption speed changed when I
upgrade the kernel from 4.14 to 5.4

The speed of /dev/urandom is about the same and 4.14 to 5.4.
pv /dev/urandom > /dev/null
- single run    1x 245 MB/sec
- dual run      2x 95 MB/sec
- triple run    3x 60 MB/sec
- quad run      4x 45 MB/sec

But for AES it is different
for X in 1 2 3 4; do
  echo "0 4294967296 zero" | dmsetup create zero${X}
  echo "0 $(blockdev --getsize /dev/mapper/zero${X}) crypt \
   aes-xts-plain64:sha512 $(sha512sum /proc/sys/kernel/random/uuid | cut -b
1-128) \
   0 /dev/mapper/zero${X} 0" | dmsetup create crypto${X}
done
pv /dev/mapper/cryptoX > /dev/null

Rough numbers I get for 4.14.150
- single run    1x 1800 MB/sec
- dual run      2x 1040 MB/sec
- triple run    3x  810 MB/sec
- quad run      4x  680 MB/sec

but for 5.4.58
- single run    1x 500 MB/sec
- dual run      2x 500 MB/sec
- triple run    3x 500 MB/sec
- quad run      4x 500 MB/sec

Is there a reason for this?



The last thing I wanted to point out is that I noticed no real interest in
inverted dm-crypt map. Do you think it is completely useless?

Somewhere in the past I found a discussion (sorry I do not have the link)
about possible use of inverted dm-crypt map for encrypted backups of plain
data (block based, possibly incremental, possibly onto a tape). Also
someone asked on dm-crypt about "inverted" usage for NBD
encryption/decryption
https://www.saout.de/pipermail/dm-crypt/2013-August/003474.html
https://www.saout.de/pipermail/dm-crypt/2013-August/003479.html

I thought it might be useful to have an option to encrypt the data by
reading from a dm-crypt device (read data and write somewhere) and then
being able to decrypt the data by another dm-crypt table (read again and
get the original data).

If I try a quick and dirty way of adding another cipher and reversing
encrypt/decrypt in recent 5.4 kernel
--- linux-5.4.56/arch/x86/crypto/aesni-intel_glue.c-orig
+++ linux-5.4.56/arch/x86/crypto/aesni-intel_glue.c
@@ -987,6 +987,22 @@ static struct skcipher_alg aesni_skciphers
                .setkey         = xts_aesni_setkey,
                .encrypt        = xts_encrypt,
                .decrypt        = xts_decrypt,
+       }, {
+               .base = {
+                       .cra_name               = "__xts(aesr)",
+                       .cra_driver_name        = "__xts-aesr-aesni",
+                       .cra_priority           = 401,
+                       .cra_flags              = CRYPTO_ALG_INTERNAL,
+                       .cra_blocksize          = AES_BLOCK_SIZE,
+                       .cra_ctxsize            = XTS_AES_CTX_SIZE,
+                       .cra_module             = THIS_MODULE,
+               },
+               .min_keysize    = 2 * AES_MIN_KEY_SIZE,
+               .max_keysize    = 2 * AES_MAX_KEY_SIZE,
+               .ivsize         = AES_BLOCK_SIZE,
+               .setkey         = xts_aesni_setkey,
+               .encrypt        = xts_decrypt,
+               .decrypt        = xts_encrypt,
 #endif
        }
 };


echo "0 100000000 zero" | dmsetup create zero
echo "0 $(blockdev --getsize /dev/mapper/zero) crypt \
 aesr-xts-plain64:sha512 $(sha512sum /bin/bash | cut -b 1-128) \
 0 /dev/mapper/zero 0" | dmsetup create crypto
echo "0 $(blockdev --getsize /dev/mapper/crypto) crypt \
 aes-xts-plain64:sha512 $(sha512sum /bin/bash | cut -b 1-128) \
 0 /dev/mapper/crypto 0" | dmsetup create crypto2

od /dev/mapper/crypto2
(zeroes)

It seems to work both ways aesr-xts-plain64 / aes-xts-plain64, or
aes-xts-plain64 / aesr-xts-plain64.

In case of transferring such encrypted data via NBD or iSCSI you mentioned
replay attack - if the attacker has access to the network the data can be
modified. Not sure if this would be the best usage example, But with
checksumming (e.g. BTRFS with checksums) this would be difficult, or not?

Or if the attacker has access to multiple versions (e.g. incremental
backups) of the encrypted data, then he can analyze changes. Does this make
XTS encryption problematic/unusable and the whole idea of inverted dm-crypt
useless?

Thank you very much,

John

[-- Attachment #2: Type: text/html, Size: 8147 bytes --]

Re: [dm-crypt] Encryption speed and reversing the direction

[Arno Wagner]

On Tue, Aug 25, 2020 at 04:44:50 CEST, Eric Biggers wrote:
> On Tue, Aug 25, 2020 at 02:05:35AM -0400, John Lee McMahon wrote:
[...]
> Also if you actually care about random number generation performance, you
> shouldn't be going through the kernel at all, except to read an initial
> seed.  
[...]

Not anymore. /dev/urandom has pretty good performance now.
On my very old Phenom II fileserver, I get about 270MB/sec
with a 5.x kernel.

Regards,
Arno

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: [dm-crypt] Encryption speed and reversing the direction

[Eric Biggers]

On Tue, Aug 25, 2020 at 04:59:29PM +0200, Arno Wagner wrote:
> On Tue, Aug 25, 2020 at 04:44:50 CEST, Eric Biggers wrote:
> > On Tue, Aug 25, 2020 at 02:05:35AM -0400, John Lee McMahon wrote:
> [...]
> > Also if you actually care about random number generation performance, you
> > shouldn't be going through the kernel at all, except to read an initial
> > seed.  
> [...]
> 
> Not anymore. /dev/urandom has pretty good performance now.
> On my very old Phenom II fileserver, I get about 270MB/sec
> with a 5.x kernel.

Sure, just using /dev/urandom (or getrandom()) should be the first choice.
I was talking about the rare case where those still aren't fast enough.

- Eric