[HN Gopher] OpenSSL 3.1
___________________________________________________________________
OpenSSL 3.1
Author : wyday
Score : 104 points
Date : 2023-03-14 14:19 UTC (8 hours ago)
(HTM) web link (www.openssl.org)
(TXT) w3m dump (www.openssl.org)
| mfiguiere wrote:
| Phoronix has published some benchmarks of OpenSSL 3.1 vs 3.0:
| https://www.phoronix.com/news/OpenSSL-3.1-Released
| er4hn wrote:
| > A FIPS 140-3 compliant FIPS Provider
|
| This is actually a pretty big deal. FIPS 140 certifications are
| required for a lot of US Federal sales. The FIPS 140 standard
| changed sometime in the past year from major version 2 to major
| version 3 and lots of changes are required to certify against the
| v3 standard, even if you had a v2 certification. What's not
| obvious is that a lot of FIPS 140 certified software libraries
| are whitelabeled openssl. Because of the openssl teams hard work
| in getting this released, it really lowers the barrier to entry
| for companies trying to sell software to the US Federal
| government.
|
| I wish the certifications were not as onerous as they were, but
| this is a big step forward for teams that are not staffed to read
| and implement several hundred pages of ISO standards for how to
| correctly implement crypto algorithms. Don't even get me started
| on how the standards you certify against are themselves
| copyrighted...
| throw0101b wrote:
| > _Various assembler optimisations to a number of different
| algorithms (e.g. AES-GCM, ChaCha20, SM3, SM4, SM4-GCM) across
| multiple processor architectures_
|
| With modern compilers, how often (or in what circumstances) is it
| worth "hand-rolling" assembler code versus just letting the
| compiler do it? Does one make the assembler 'from scratch', or
| perhaps let the compiler generate the assembler and have a human
| look at it to see if there are any places it can be improved?
| swatcoder wrote:
| Compilers are capable of very effective optimizations, but they
| need certain guarantees to be able to apply them and
| _sometimes_ it 's a pain to communicate those guarantees
| adequately in your source code, or your platform targets don't
| support all the hints you might need to apply.
| dale_glass wrote:
| I think cryptography is one of the few places where it makes
| sense to do that. Because:
|
| * There's not that much code involved.
|
| * Many CPUs have instructions specifically made for
| accelerating cryptographic algorithms.
|
| * Security may have specific requirements from the code, such
| as not giving away any secrets through timing. This may require
| writing very specific, suboptimal code intentionally.
| sylware wrote:
| ... and keeping critical pieces of code as much independent
| as possible from the very few grotesquely and absurdely
| massive and complex optimizing compilers is always a good
| idea.
| freedomben wrote:
| Most of the time, a human will do worse than the compiler. But,
| a human who knows what they're doing and understands the
| problem well can still improve on the output.
| colmmacc wrote:
| It's very worth doing in this context ... almost all of the
| assembly I've written in the last ten years has been on
| routines like this. Compilers are very smart, but it's hard for
| them to optimize concurrent and interleaved cryptographic
| algorithms to be cache pipeline efficient and operation
| efficient at the same time.
|
| AES-GCM is "AES" and "GCM" running at the same time on the same
| data. ChaCha20 is "ChaCha20" and "Poly1305" running at the same
| time on the same data, usually block by block so that you avoid
| pulling data into cache more than once. You can interleave
| their imperative operations in C, or Rust code (or whatever)
| ... but the compiler isn't going to intuit how some of the math
| can be re-used across the algorithms without a lot of hints, or
| how it can be safely vectorized, and at that point you might as
| well just write the assembly.
| __s wrote:
| If you look at the output of your compiler many unnecessary
| loads/stores. Vectorized code in particular still comes out
| lacking even with intrinsics
|
| In fact, you can benchmark openssl's assembly vs openssl's C:
| https://github.com/openssl/openssl/blob/master/crypto/aes/ae...
|
| Granted, they aren't using intrinsics in that code, but a
| sufficiently smart compiler shouldn't need intrinsics
| aliljet wrote:
| This seems like a stupid question, but is anyone releasing
| binaries of OpenSSL for Windows environments? Is there an
| expectation that OpenSSL will take reigns in MacOS environments
| from LibreSSL?
| madduci wrote:
| You can use the Conan package manager with prebuilt
| binaries/libraries
|
| https://conan.io/center
| verall wrote:
| You can use vcpkg to build it locally from sources
| throw0101c wrote:
| * https://wiki.openssl.org/index.php/Binaries
| aliljet wrote:
| it feels weird not grabbing this directly from the openssl
| team. that's a gap in trust...
| e40 wrote:
| That's what I've always felt, which is why I build my own.
| dur-randir wrote:
| No API breakage?
| Vecr wrote:
| https://www.openssl.org/news/cl31.txt has a more detailed
| changelog.
| [deleted]
___________________________________________________________________
(page generated 2023-03-14 23:04 UTC)