Hacker News Reader

Comment by sureglymop | Hacker News Reader

My question is, why does the library even support AES-CBC? I know that it's OpenSSL here but why can't we have an additional library then that ships only the recommended encryption schemes, safe curves, etc. and deprecates obsolete practices in an understandable process? Something that is aimed at developers and also comes with good documentation on why it supports what it does.

View on HN

Legacy. You rarely only touch new stuff or secure stuff. And instead end up at least with one scenario that requires you do something with old stuff. And this is not just crypto.

I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto. We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers.

They should have another library which, like I said, actively deprecates obsolete and insecure practices but in a way that makes the update process digestible for people depending on it.

> I get that. But then, keeping that legacy stuff running is just as problematic as rolling your own crypto.

Both problems are from the lack of knowledge, but latter one is orders of magnitude harder to fix.

>We can leave OpenSSL as it is but it shouldn't be the popular recommendation for developers.

OpenSSL isn't a recommendation for developers. For TLS, LibreSSL and BoringSSL are. For other stuff, libsodium is.

The only reason I've picked OpenSSL, is it has a higher level library (pyca/cryptography) that gives bindings to X448.

Because such library is pretty useless in the real world where your system needs to interact with other systems using "legacy" encryption schemes.

Usability and practicality is critical for successful security approach.

Reply on news.ycombinator.com