Lope Posted August 20, 2019 Share 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 0 Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.