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

[Eric Biggers <ebiggers@kernel.org>]

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