[TwoBit]

Whenever there's an article about OpenSSL, I get on my soapbox to talk about how shitty it is. The design is terrible, both internally and in the public API. Building it is a PITA. It is almost completely unaware of this thing called multithreading. It still is hard-coded to be able to read certificates only via disk files with fopen, despite having a screwy BIO system which is a half baked attempt at sometimes abstracting IO.

If it was anything other than a security library, it would have died long ago.

[dom0]

I contribute to some software that's relatively widely deployed and needs crypto primitives. Sadly on Linux there are few choices that support common algorithms and is usually available. The alternatives sometimes exhibit performance issues due to missing optimizations as well, or simply don't support the needed algorithms. On the other hand OpenSSL took it's sweet time to implement eg. 25519 based crypto or chacha20 which is also a pain - today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration.

Another thing I'd like to ramble about a bit is their API/release management. In 1.1 they made a bunch of structures opaque - which is good IMHO - but due to the very inconsistent APIs before they needed to add some utility APIs to handle opaque structs in some places; instead of backporting those to 1.0.x, so that you, as an application developer, don't need to add conditional compilation and shims to every application, they chose not to. Additionally shims posted in the wiki were (maybe still are) wrong.

Forcing application developers to figure out API compatibility code for a crypto library is bad. That code will be tested very little or not at all, additionally it's hard to test.

Cryptography on Linux (or - on most platforms) is still in a bad shape.

[cristinamillion]

> Cryptography on Linux (or - on most platforms) is still in a bad shape.

libsodium addresses the non-TLS part of this pretty well, doesn't it? I know it doesn't have any native password-based KDF that won't DOS your device under anything but simple load, but otherwise it uses good algorithms.

> today Chacha20-Poly1305 is the only viable AEAD crypto system for embedded/low-computing-capability devices, including those with AES acceleration.

True, but there are some nice-looking AEAD candidates in the CAESAR competition, some of which out-perform AES-GCM and CHACHA20 by a good margin. We'd probably all be using OCB mode if Rogaway hadn't used such a bizarre initial license (which took a few iterations to get in a sane state and still require you to pay him something like $70,000 USD for use in commercial embedded systems).

[dom0]

NaCl/libsodium doesn't really work for a lot of cases, partly since it only supports AES-(GCM) if the hardware supports it, which just ain't going to work for anything that uses encryption for storage ("You can't open this file on this computer, please go to a computer with AES-NI, thank you"), and partly because it's opinionated approach doesn't work for some software (AES-GCM is actually an instance of this).

Otherwise it's a nice library. So if it works for a project I highly recommend it.

--

I really hope that CAESAR moves the state of AEAD forwards. By all accounts it already has.

[wbond]

> Cryptography on Linux (or - on most platforms) is still in a bad shape.

Having worked with Windows and OS X crypto layers, OpenSSL, CryptoPP and libtomcrypt, I think that generally cryptography is in bad shape almost everywhere.

The libraries that are trying to improve the cryptography aspects tend to run into the issue that algorithms in heavy use are unsupported. The libraries that do support algorithms in heavy use tend to have poorly written code, convoluted APIs, or bad documentation.

I have a huge amount of respect for everyone doing work in this space. When things are working, most people ignore it, but when sometimes goes wrong, everyone is mad at you. I would imagine there isn’t a whole lot of motivation for most.

[bch]

I don't know about CryptoPP, or your application of encryption, but wasn't libtomcrypyt a well-intentioned but wholly poor attempt at re-presenting crypto to developers? Is it even widely used? I came to it by way of libtommath, but recall feeling pretty quickly tomcrypto was not a crypto solution.

[scrollaway]

phk had a talk (at fosdem I believe) a few years ago in which he stressed that the easiest way for the NSA to "create" vulnerable code is to push out bad, unnatural APIs with horrendeous defaults into OpenSSL.

[caf]

You can read certificates via the BIO system with PEM_read_bio_X509() or straight from a buffer with d2i_X509().

[mitchtbaum]

Gosh, to fix such a problem we'd almost need some kind of machine that can run a different program than its current one. Perhaps with evidence of that as a possibility, we could use a good crypto library instead, eg. https://github.com/jedisct1/libsodium

[dom0]

libsodium is not an OpenSSL replacement and doesn't want to be. It's a cryptographic primitive library and generally doesn't implement cryptographic protocols (eg. TLS, X.509, CMS, CRLs, OCSP, ...).

[mitchtbaum]

That'd be like moving from a beat-up frame-and-tarp survival shelter into any long-term, well-built house.. and still sleeping on dirt.