Upgrade to Kernel 4.21 for Secure Encryption (XChaCha20 adiantum)

[Lope]

AES has some major weaknesses, keys are breakable through timing attacks (dependent on implementation) due to it's design flaws

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2835&rep=rep1&type=pdf
I'm not sure if hardware accelerated AES-NI is vulnerable to timing attacks. But the bottom line is that AES is very complicated and easy to screw up in the implementation such that it's vulnerable to various attacks.
ChaCha20 on the other hand (XChaCha20 in newer kernels) is simple to implement, (much faster than AES when implemented purely in software) and easy to reason about.

The most secure cipher available seems to be DJB's XChaCha20. XChaCha20 performs almost as well as AES, even though there is no hardware acceleration for it. Due to the performance being really good on Embedded devices, Google has selected XChaCha as the default algorithm for devices without AES acceleration.
For interest's sake I ran a cryptsetup benchmark of the available ciphers on my orange Pi Zero and got these results
 

                       enc     dec  (MiB/s)
aes-xts	  	256b	24	21
twofish-xts	512b	19	19
aes-xts	  	512b	19	16
twofish-xts	256b	19	19
aes-cbc	  	128b	18	19
twofish-cbc	256b	17	19
twofish-cbc	128b	17	19
aes-cbc	  	256b	14	15
serpent-xts	512b	12	13
serpent-xts	256b	12	13
serpent-cbc	256b	11	13
serpent-cbc	128b	11	13

I was not able to test XChaCha20 / adiantum because my Orange Pi Zero is only running Kernel 4.19.

XChaCha20 support will is available from Kernel 4.21 onwards
https://www.spinics.net/lists/dm-crypt/msg07821.html

On all the devices I've tested (even powerful x86_64 CPUs (that have AES-NI of course)) the performance of XChaCha20 was close enough that it can be used without impacting performance (for example even on my old Haswell I get >1400MB/s for enc and dec with XChaCha20)
Yes AES is faster, but if it's not actually doing it's job properly, it's not apples vs apples comparison.

Anyway, whether you think AES is good enough or not, XChaCha20 will continue to see increased adoption.

I'd love to try it out on the H3, H5 and so on.

It seems that most Armbian builds have a 4.19 Kernel, likely because Debian Stable (Buster) uses this kernel.
But a as I understand it, these SoCs are running "mainline" kernels. So in theory, a 4.21 Kernel could probably be compiled with ease and hopefully would not break anything?
The alternative is waiting for Debian 11, which could take a very long time (at least 1-2 years)

Kernel config tip (Source https://www.reddit.com/r/crypto/comments/b3we04/aesadiantum_new_mode_in_linux_kernel_5/ )

Apparently there are ARM kernel options equivalent to the X86 options
CONFIG_CRYPTO_CHACHA20_X86_64
CONFIG_CRYPTO_NHPOLY1305_AVX2
That should be enabled for best performance.

I see in https://github.com/torvalds/linux/blob/master/arch/arm/crypto/Kconfig
There are options like
CRYPTO_CHACHA20_NEON
CRYPTO_NHPOLY1305_NEON
which should definitely be enabled.

 

How to run a benchmark
 

#possible with >=4.21 kernel and >=2.0 cryptsetup
cryptsetup benchmark --cipher xchacha20,aes-adiantum-plain64

#default cipher benchmarks
cryptsetup benchmark

#note these benchmark results are not entirely realistic vs real-world performance due to userspace/kernelspace and initialization issues, but gives an approximation.

Bottom line
So I'm just mentioning this stuff incase maintainers are interested
It would be cool to have a >=4.21 Kernel, and cryptsetup > 2.0.0 to take advantage of XChaCha20 aka Adiantum

[lanefu]

Hi@lope thanks for sharing your research on modern crypto options.

Kernel 5.x for allwinner CPUs is available as the armbian dev kernel. You can switch to it via the armbian-config tool. An image is also available via the "other downloads" link on the download page for your chosen SBC.

[Igor]

9 hours ago, Lope said:

likely because Debian Stable (Buster) uses this kernel.

There is virtually no relationship with Debian on a kernel level. We maintain our own line of kernel(s) for each board family. This is just a coincidence. We use most appropriate mainline sources + (in case of allwinner) huge number of patches.

 

10 hours ago, Lope said:

The alternative is waiting for Debian 11, which could take a very long time (at least 1-2 years)

Or backporting? If someone finds the interest ... but otherwise we are on the way to move to 5.x. sooner.

[Werner]

You can give 5.3.0-rc3 a shot if you want. You can find precompiled packages for various OrangePi boards following the link below (in my signature).

 

Offtopic: For better encryption performance you should grab a ARM64 board, like something based on the Allwinner H5 or H6 SoC.

 

 

root@orangepioneplus:~# cryptsetup benchmark --cipher xchacha20,aes-adiantum-plain64
# Tests are approximate using memory only (no storage IO).
#            Algorithm |       Key |      Encryption |      Decryption
xchacha20,aes-adiantum        256b       136.5 MiB/s       152.3 MiB/s

Linux honeypot3 5.3.0-rc3-sunxi64 #5.94 SMP Sat Aug 17 14:21:45 UTC 2019 aarch64 GNU/Linux

 

[sfx2000]

On 8/20/2019 at 1:59 PM, Lope said:

AES has some major weaknesses, keys are breakable through timing attacks (dependent on implementation) due to it's design flaws

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.140.2835&rep=rep1&type=pdf
I'm not sure if hardware accelerated AES-NI is vulnerable to timing attacks. But the bottom line is that AES is very complicated and easy to screw up in the implementation such that it's vulnerable to various attacks.

 

I think with Crypto - leave it to Pro's -  people smarter than you or me - and I'm smart enough not to go into a tizzy over an academic exercise without a CVE attached to it.

 

ChaCha might faster in SW than AES - but with most platforms, AES isn't really an issue - AMD64/aarch64 - not withstanding the mitigations resulting from things like Meltdown/Spectre, etc...

 

And that's implementation - even there - it's arch differences across generations of cores and vendors, along with supporting compilers, source code...

 

Playing around with Crypto is always a risk on the leading edge - and God does not roll dice on pseudorandom devices like CPU's and Software.

 

 

 

 

[Pander]

Is this still an issue or can it be closed?

[lanefu]

Id say it can be closed