Announcement

Collapse
No announcement yet.

Linux 6.10 AES-XTS For Disk/File Encryption As Much As ~155% Faster For AMD Zen 4 CPUs

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • fitzie
    replied
    the nice thing is that cryptsetup has a built in benchmark tool. anyone can run just
    Code:
    cryptsetup benchmark
    and see how XTS performs on their hardware right now.


    Leave a comment:


  • Anux
    replied
    Originally posted by EphemeralEft View Post
    According to Grover's algorithm, quantum computers will eventually be able to brute force AES keys in √N attempts
    Grover is based an known plain text, which is pretty hard to do with FDE. It might be more feasible for communication encryption, where you know certain patterns appear at certain positions.

    And it depends on how fast a hypothetical quantum computer can calculate a single hash compared to traditional computers. I'm not sure if you can buy any quantum computer right now (IBM claimed once they would have a production ready in 2024) and how fast they are. With the samples they used in research any crypto hack would have been unfeasible slow. Maybe if they can split the problem over millions of Q computers, but then the limit is money and production (in the range where giant dedicated classic crack hardware is faster and cheaper).

    For me this is more a theoretical thread and actual usage is as far away as fusion power plants.

    Leave a comment:


  • qarium
    replied
    Originally posted by EphemeralEft View Post
    AES-192 is definitely faster than AES-256.
    According to Grover's algorithm, quantum computers will eventually be able to brute force AES keys in √N attempts, where N is the number of bits of the private key. That means AES-128, AES-192, and AES-256 will eventually have the same security as AES-64, AES-96, and AES-128, respectively. 192 bits still isn't great, but it's going to be secure against quantum computers for at least the next 10 years. I'm hoping that within 10 years, classical computers will be able to run AES-256 at least as fast as I can run AES-192 now.
    according to my knowlege and the wikipedia of AES... its not only the amount of bits what makes it weak against cracking its the algorithm itself.

    for example CAST 128bit is stronger than AES-256... because the AES algorithm is broken by design.




    for CAST nothing like this is known




    its a well known fact that AES is broken by design and that the NSA did create this standard to make sure they can crack it.

    if you use CAST128 or CAST256 instead nothing like this will ever happen.

    if you just compare the best crypto analysis between AES and CAST there is big big difference...

    "Currently, the best public cryptanalysis of CAST-256 in the standard single secret key setting that works for all keys is the zero-correlation cryptanalysis breaking 28 rounds with 2246.9 time and 298.8 data.[2]​"

    also keep in mind that against AES there are Side-channel attacks and Quantum attacks to...

    nothing like this exist for CAST...

    Leave a comment:


  • EphemeralEft
    replied
    Originally posted by Anux View Post
    Why is 128 too small? Isn't 192 just 256 cut down, so no performance improvement?
    AES-192 is definitely faster than AES-256.

    According to Grover's algorithm, quantum computers will eventually be able to brute force AES keys in √N attempts, where N is the number of bits of the private key. That means AES-128, AES-192, and AES-256 will eventually have the same security as AES-64, AES-96, and AES-128, respectively. 192 bits still isn't great, but it's going to be secure against quantum computers for at least the next 10 years. I'm hoping that within 10 years, classical computers will be able to run AES-256 at least as fast as I can run AES-192 now.

    Leave a comment:


  • Anux
    replied
    Originally posted by EphemeralEft View Post
    I hope AES-192 also gets the speedup. 128 is too small, 256 is too big, but 192 is juuuuuuust right.
    Why is 128 too small? Isn't 192 just 256 cut down, so no performance improvement?

    Leave a comment:


  • EphemeralEft
    replied
    I hope AES-192 also gets the speedup. 128 is too small, 256 is too big, but 192 is juuuuuuust right.

    Leave a comment:


  • EphemeralEft
    replied
    Originally posted by bradh352 View Post
    Its fairly unlikely you're being bottlenecked on your encryption performance, but more likely not using the right flags in modern systems. See
    In this post, we will investigate the performance of disk encryption on Linux and explain how we made it at least two times faster for ourselves and our customers!


    You need to use no_read_workqueue and no_write_workqueue on modern systems. I really have no idea why those aren't the default these days.
    I used to have an issue where my system would freeze for 1-5 minutes, 1-2 times per day, for years. I tried so many things including the workqueue options, but in the end it turned out to be my filesystem. TL;DR, reformatting my BTRFS filesystem with the new block-group-tree feature completely solved the issue. I never noticed a difference (positive or negative) with the workqueue options.

    Leave a comment:


  • Anux
    replied
    Originally posted by sobrus View Post
    Zen3 scored impressive gains as well, even though it doesn't feature AVX512. While Zen2 fares much worse.
    And Sapphire Roads results for avx2 and both avx10 flavours are very close.

    All there processors feature AVX2, but only some have high gains. Also AVX512 is again not so much faster than AVX2.
    So its VAES that is mosty responsible for this huge uplift, not AVX.
    This might be the reason: https://images.anandtech.com/doci/16...e-page-026.jpg

    Leave a comment:


  • sobrus
    replied
    Zen3 scored impressive gains as well, even though it doesn't feature AVX512. While Zen2 fares much worse.
    And Sapphire Roads results for avx2 and both avx10 flavours are very close.

    All there processors feature AVX2, but only some have high gains. Also AVX512 is again not so much faster than AVX2.
    So its VAES that is mosty responsible for this huge uplift, not AVX.
    Last edited by sobrus; 09 April 2024, 07:40 AM.

    Leave a comment:


  • Anux
    replied
    Originally posted by MarkG View Post
    A few years ago, my dentist found a cavity in an upper-back molar and did a root-canal. It was not until I was driving home, and after the novacaine wore off, that I realized "OMG, I've been putting up with this discomfort for a long time." I've been doing LUKS FDE ~everywhere ~forever, but don't notice any pain -- it's just the cost of doing business. But, I suspect/hope that when this rolls out generally, I'll have a similar "Ahhh" moment when I notice the speed-up.
    I never noticed any slow downs from FDE, my laptop has a core i 3000 and its AES is faster than the sata 3 SSD and on my desktop the NVMe has around 3,5 GB/s throughput and AES is around 3 GB/s, since those speeds are never the bottleneck for me there is no noticeable performance hit.
    I guess with heavy database usage or other disk intensive workloads you might be able to notice something.

    I'm not even sure if I activated the workqueue hack on my current system but I used it in the past and there was no noticeable change.

    With the improvement from the article I don't expect to feel a difference but the CPU load should be less.

    Leave a comment:

Working...
X