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@xxxxxxxxxxxxxxxxxxxxxxx
> > > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> >
> > _______________________________________________
> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > 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@xxxxxxxxxxxxxxxxxxxxxxx
> > Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> 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@xxxxxxxxxxxxxxxxxxxxxxx
> 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: casper@xxxxxxxxxxxxxxxxxx
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
