Re: Hardware without AES-NI: use xchacha12/Adiantum instead of AES-XTS

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux