Lope Posted August 20, 2019 Posted August 20, 2019 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 onwardshttps://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 likeCRYPTO_CHACHA20_NEONCRYPTO_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 Posted August 21, 2019 Posted August 21, 2019 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 Posted August 21, 2019 Posted August 21, 2019 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 Posted August 21, 2019 Posted August 21, 2019 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 Posted August 22, 2019 Posted August 22, 2019 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.
Recommended Posts