Good everning, I just experienced that, when setting up a new Fedora, Anaconda (both "Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64 for disk encryption, even if the hardware does not support AES-NI. Does it make sense to use xchacha12,aes-adiantum-plain64 by default if there is no AES-NI in the hardware? For a general use case, the security advantages of Adiantum can be neglected; both aes-xts & chacha-adiantum are secure. But there are big performance disadvantages of AES when there is no AES-NI (this was the major reason for merging Adiantum into the kernel). Besides the use of system resources, netbooks and such may have strongly decreased battery life times with aes-xts (the issue is primarily aes, not xts). I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric, I expect that other Workstation installations tend to the same behavior. Adjustments would be limited to Anaconda. Regards & stay safe, Chris _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure

The irony is that XTS uses two different keys for different parts of the operation. This means that AES-XTS-256 is AES128 and AES-XTS-512 is AES256 (security is not increased by the second key). So, you compared AES with 128 bit encryption with XChaCha with 256 bit. And despite the doubled key length, XChaCha is still 3 times faster I would be curious to see how it is about XChaCha 256b against AES 256b (which is 512 in XTS) on your machine? If you reduce an algorithm's security to its security margin, XChaCha12 (=12 rounds of XChaCha) has still a higher security margin than AES256 (= AES-XTS-512), and XChaCha12 is obviously even faster than XChaCha20 (20 rounds of XChaCha). So on hardware without AES-NI, the performance can be heavily increased. Google made a good job with Adiantum imho, and of course djb with ChaCha The issue is already at Blivet: https://bugzilla.redhat.com/show_bug.cgi?id=2077532 Regards, Chris On 08/06/2022 04:18, Casper wrote: > I was curious to see if changes were significant on my old Asus laptop: > > ``` > blackbird:~ # cryptsetup benchmark -c xchacha20,aes-adiantum > # Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S). > # Algorithme | Clé | Chiffrement | Déchiffrement > xchacha20,aes-adiantum 256b 327,8 MiB/s 345,0 MiB/s > blackbird:~ # cryptsetup benchmark -c aes-xts-plain64 > # Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S). > # Algorithme | Clé | Chiffrement | Déchiffrement > aes-xts 256b 105,0 MiB/s 103,9 MiB/s > ``` > > Results on a SATA disk (no SSD), and no AES flag in cpuinfo. > > Regards, > Casper > > py0xc3 a écrit : > > Good everning, > > > > I just experienced that, when setting up a new Fedora, Anaconda (both > > "Custom" and "Advanced Custom (Blivet-GUI)") always uses aes-xts-plain64 for > > disk encryption, even if the hardware does not support AES-NI. > > > > Does it make sense to use xchacha12,aes-adiantum-plain64 by default if there > > is no AES-NI in the hardware? > > > > For a general use case, the security advantages of Adiantum can be > > neglected; both aes-xts & chacha-adiantum are secure. > > > > But there are big performance disadvantages of AES when there is no AES-NI > > (this was the major reason for merging Adiantum into the kernel). > > > > Besides the use of system resources, netbooks and such may have strongly > > decreased battery life times with aes-xts (the issue is primarily aes, not > > xts). > > > > I tested with Fedora 35, KDE spin; but as the issue is Anaconda-centric, I > > expect that other Workstation installations tend to the same behavior. > > > > Adjustments would be limited to Anaconda. > > > > Regards & stay safe, > > Chris > > _______________________________________________ > > devel mailing list -- devel(a)lists.fedoraproject.org > > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure > > _______________________________________________ > devel mailing list -- devel(a)lists.fedoraproject.org > To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure _______________________________________________ devel mailing list -- devel(a)lists.fedoraproject.org To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure