Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The State of OpenSSL for pyca/cryptography

cryptography.io

Post reply on HN
Print view View original

41–50 of 65 posts

Re: The State of OpenSSL for pyca/cryptography

#41

Post by whizzter »

groby_b wrote: post #32
timschmidt wrote: post #28

Earlier quoted context omitted.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

And once you realize that Management + Finance + Marketing outnumber engineering at OpenSSL [1], you know the money is put to good use, too. [1]: https://openssl-corporation.org/about/leadership/

Seems plenty of the people occur multiple times, so there's more engineers... if only barely :|

Re: The State of OpenSSL for pyca/cryptography

#43

Post by some_furry »

teunispeters wrote: post #42

I look forward to crypto libraries not openssl that can provide support for ED25519 and ED448, as well as a wide range of EC keys. These are requirements for my current work, and OpenSSL 3+ was the only crypto library that delivered.

What do you need Ed448 for? I've not seen much real world deployments of this algorithm, so I'm very curious about this.

Re: The State of OpenSSL for pyca/cryptography

#44

Post by commandlinefan »

formerly_proven wrote: post #2

> Finally, taking an OpenSSL public API and attempting to trace the implementation to see how it is implemented has become an exercise in self-flagellation. Being able to read the source to understand how something works is important both as part of self-improvement in software engineering, but also because as sophisticated consumers there are inevitably things about how an implementation works that aren’t documented…

> OpenSSL code was not pleasant or easy to read

I published a book about SSL a while back - my original plan for the book was going to be to work through the OpenSSL source code and relate each piece back to the relevant specifications, step by step. I found that the OpenSSL source code was so complex that I would have spent a lot more time discussing the intricacies of the C code itself than the cryptographic algorithms they were implementing - so much so that it made more sense to just write my own SSL implementation and walk through that.

In fairness to OpenSSL, though, I can see how and why it got so complex: they're trying to be all things to all people in a backwards compatible way. At the time, OpenSSL still had support for SSLv2, an albatross that LibreSSL doesn't have around its neck.

Re: The State of OpenSSL for pyca/cryptography

#45

Post by woodruffw »

nine_k wrote: post #25
jmspring wrote: post #11

Earlier quoted context omitted.

I’d say correct common path. OpenSSL due to hand waving deals with a lot of edge cases the correct path doesn’t handle. Even libraries like libnss suffers from this.

Are these edge cases correct to the spec, or not?

There are multiple overlapping specifications for things like X.509. There are the RFCs (3280 and 5280 are the "main" ones) which OpenSSL generally targets, while the Web PKI generally tries to conform to the CABF BRs (which are almost a perfect superset of RFC 5280).

RFC 5280 isn't huge, but it isn't small either. The CABF BRs are massive, and contain a lot of "policy" requirements that CAs can be dinged for violating at issuance time, but that validators (e.g. browsers) don't typically validate. So there's a lot of flexibility around what a validator should or shouldn't do.

Re: The State of OpenSSL for pyca/cryptography

#46

Post by zxcvasd »

tptacek wrote: post #31
timschmidt wrote: post #28

Earlier quoted context omitted.

I am not surprised at all, because instead of throwing their support behind the LibreSSL folks who audited the OpenSSL codebase after Heartbleed and found deep design and implementation issues, Linux Foundation and member orgs including most of Silicon Valley decided that OpenSSL just needed more funding. Felt like good money after bad on day 1.

The problem with the OpenSSL 3 codebase isn't security; many organizations, including the OpenSSL team itself, have been responsible for pulling out of the security rut OpenSSL was in when Heartbleed happened. The OpenSSL 3 problem is something else.

[dead]

Re: The State of OpenSSL for pyca/cryptography

#47

Post by amluto »

Retr0id wrote: post #6

By the way, pyca/cryptography is a really excellent cryptography library, and I have confidence that they're making the right decisions here. The python-level APIs are well thought-out and well documented. I've made a few minor contributions myself and it was a pleasant experience. And my personal "new OpenSSL APIs suck" anecdote: https://github.com/openssl/openssl/issues/19612 (not my gh issue but I ran into the exa…

This is amazing.

Once upon a time, OpenSSL was the place to go for crypto primitives that were hardware specific and well optimized, and you would pay the price of using a nasty API. Now it’s an even nastier API and it’s not even fast anymore?

SHA256 is almost the prototype of a pure function. There should not be concepts like “EVP”. Output sizes should be static. Failure should be entirely impossible unless I opt in to using an async interface for an async accelerator. The only complexity should be the hidden part that selects the best synchronous implementation.

Re: The State of OpenSSL for pyca/cryptography

#48

Post by amluto »

ForHackernews wrote: post #35
ameliaquining wrote: post #13

Earlier quoted context omitted.

Note that all cryptographic primitives are still going to be in C via an OpenSSL-like API for the next while; the current proposal is to migrate from OpenSSL to one of its forks. Various bits of backend logic that aren't cryptographic primitives (e.g., parsing) have been rewritten in Rust; additionally, https://github.com/ctz/graviola is mentioned near the end as a possible implementation of cryptographic primitives…

Whatever happened to libsodium that was designed to provide vetted cryptographic primitives with a modern API? https://doc.libsodium.org/doc

libsodium is great if you only need to interoperate with other software using libraries that sound like “sodium”. This is generally not helpful for the kinds of things that people use OpenSSL for.

Re: The State of OpenSSL for pyca/cryptography

#49

Post by tuetuopay »

> OpenSSL allowed replacing any algorithm at any point in program execution

Just this is completely nuts. What in the world is the usecase for this? Fanatics of hotpatching systems for zero-downtime-ever? No wonder the performance is crippled by locks left and right, it's pure recipe for disaster.

Re: The State of OpenSSL for pyca/cryptography

#50

Post by Retr0id »

amluto wrote: post #47
Retr0id wrote: post #6

By the way, pyca/cryptography is a really excellent cryptography library, and I have confidence that they're making the right decisions here. The python-level APIs are well thought-out and well documented. I've made a few minor contributions myself and it was a pleasant experience. And my personal "new OpenSSL APIs suck" anecdote: https://github.com/openssl/openssl/issues/19612 (not my gh issue but I ran into the exa…

This is amazing. Once upon a time, OpenSSL was the place to go for crypto primitives that were hardware specific and well optimized, and you would pay the price of using a nasty API. Now it’s an even nastier API and it’s not even fast anymore? SHA256 is almost the prototype of a pure function. There should not be concepts like “EVP”. Output sizes should be static. Failure should be entirely impossible unless I opt in…

I can see the value of the EVP API for certain use cases, I just wish they didn't deprecate the not-EVP API.
Post reply on HN