Thanks for your answer Chris.
```
blackbird:~ # cryptsetup benchmark -c aes-xts-plain64 --key-size 512
# Tests approximatifs en utilisant uniquement la mémoire (pas de stockage E/S).
# Algorithme | Clé | Chiffrement | Déchiffrement
aes-xts 512b 84,3 MiB/s 83,5 MiB/s
```I forgot to mention RaspberryPi4, 3, 2, does not have AES flag too. Good to know a ticket has been already opened to Blivet. Regards, Casper Christopher Klooz a écrit : > 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@lists.fedoraproject.org > > > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@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@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@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 -- GnuPG: AE157E0B29F0BEF2 at keys.openpgp.org CA Cert: https://dl.casperlefantom.net/pub/ssl/root.der Jabber/XMPP Messaging: cas...@casperlefantom.net
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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
