OpenSSL 3.1 Released With Performance Optimizations, More AVX-512

[phoronix]

Phoronix: OpenSSL 3.1 Released With Performance Optimizations, More AVX-512

OpenSSL 3.1 is out today as the new stable release for this widely-used cryptographic library. There are a number of performance optimizations to enjoy with OpenSSL 3.1, including some additional AVX-512 tuning...

https://www.phoronix.com/news/OpenSSL-3.1-Released

[spiral_23]

michael - could you test a tiger lake cpu also?

[Michael]

michael - could you test a tiger lake cpu also?

can find some Tigerlake benchmarks of tests I've done so far (and past) @ https://openbenchmarking.org/test/pts/openssl#results

[Old Grouch]

My concern about performance optimisations is whether they increase the availability of side-channel attacks.

Light Blue Touchpaper: When Layers of Abstraction Don’t Get Along: The Difficulty of Fixing Cache Side-Channel Vulnerabilities (2009-02-20)

Rambus: Side-channel attacks explained: everything you need to know (October 14, 2021)

Medium: Yan1x0s Side Channel Attacks — Part 1 ( Timing Analysis — Password Recovery) (Feb 14, 2021)
Medium: Yan1x0s Side Channel Attacks — Part 2 ( DPA & CPA applied on AES Attack ) (Apr 20, 2021)

[hotaru]

My concern about performance optimisations is whether they increase the availability of side-channel attacks.

as long as the code is constant-time, making it faster actually decreases the availability of side-channel attacks.

[Old Grouch]

as long as the code is constant-time, making it faster actually decreases the availability of side-channel attacks.

Unfortunately, this is not true.

Hertzbleed: Turning Power Side-Channel Attacks Into Remote Timing Attacks on x86

Of course, constant-time code is a a good thing: but I get worried when people talk about performance optimisations, as that often means run-time reductions, and assuring that any particular optimisation maintains the constant-time property is not necessarily what the naive optimiser will be doing. On the other hand, I would hope naive coders are not working on OpenSSL.

[hotaru]

Unfortunately, this is not true.

no, it definitely is true. the less time the CPU spends running code that deals with sensitive data, the less time there is for an attacker to exploit any side channels.

[Old Grouch]

no, it definitely is true. the less time the CPU spends running code that deals with sensitive data, the less time there is for an attacker to exploit any side channels.

That is trivially true, and not addressing the point I made. Constant-time code can still have side-channels.

[discordian]

That is trivially true, and not addressing the point I made. Constant-time code can still have side-channels.

Stream En-/Decryption shouldn't have anything exploitable by sidechannels - the later depend on some branches or access-patterns to sniff out. Those are fixed, the entire control flow could be unrolled in advance.

[hotaru]

That is trivially true, and not addressing the point I made. Constant-time code can still have side-channels.

you didn't make any point. of course constant-time code can have side channels, which is why faster constant-time code makes it more difficult to exploit side channels. if there were no side channels, the code being faster would have no effect on side channels.