[zdw]

I'd be more interested in a comparison in the strategies used to harden the codebase in the forks like BoringSSL and LibreSSL, and how well those strategies have panned out.

There has historically been some crowing from the LibreSSL crowd about how their work avoided CVE's later discovered in OpenSSL: https://undeadly.org/cgi?action=article&sid=20150319145126

[guidovranken]

I've been doing differential fuzzing of many major cryptographic libraries. It currently tests symmetric crypto, some elliptic curve crypto, bignum arithmetic, message digests and MACs, KDFs, but not TLS, X509, ASN1 etc (yet). The list of bugs it has found so far can be viewed here [1].

The bug count per library can not be used as an absolute metric and not all bugs are security vulnerabilities (though many can be under specific circumstances).

BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC: BoringSSL is smaller in terms of functionality (# of message digests, ciphers, ...) than LibreSSL, which is smaller than OpenSSL. OpenSSL sometimes commits new buggy code whereas BoringSSL does not, but OpenSSL has a higher commit frequency than BoringSSL, and BoringSSL might be aiming for a production-safe master branch where OpenSSL might not.

So it's not easy to derive a reliable metric from this, but with that said, you can't really go wrong with BoringSSL if it offers what you need.

[1] https://github.com/guidovranken/cryptofuzz#bugs-found-by-cry...

[DyslexicAtheist]

> but not TLS, X509, ASN1 etc (yet)

then this may interest you:

https://blog.doyensec.com/2020/05/14/asn1fuzz.html

^^ ASN1 is really the bees-knees for fuzzing telecoms protocols in UMTS/LTE/5G etc and doesn't get enough love in other domains. It's a high learning curve but once you get beyond the "standardese" language in the docs it's opening doors to opportunities in so many industries.

> BoringSSL has fewer bugs than LibreSSL, which has fewer bugs than OpenSSL. One of the reasons for this could be that the bug count is proportional to the complexity/SLOC

the openSSL codebase is notorious but I think it's also because it has been in existing for so long. if I look around today I see 2 camps: cryptographers and software engineers. letting sw-engineers do crypto is usually a bad idea but it's often worse when cryptographers start coding. it's almost like a variation of the old joke of "the 2 most dangerous things in Tech are a sw-engineer with a soldering iron and a hw-engineer with a sw-patch" ... apart from complexity leading to bugs I'd also say there is another downside which is stronger in openssl: people end up using it wrongly which makes it a proverbial foot-gun for implenters.

> [1] https://github.com/guidovranken/cryptofuzz

very cool thanks!!

[tialaramex]

> not all bugs are security vulnerabilities

I think to make such a claim you need to specify attack model constraints. With an unconstrained model all bugs in a library are in fact security vulnerabilities.

This does depend on a very narrow reading of what constitutes a bug, for example I would not consider it a bug per se if a function does something that you wouldn't expect (and which perhaps the developers didn't intend) but does strictly match the documentation.

The problem is that the application software developer may depend upon documented features of your library in ways you didn't anticipate and if those documents are wrong (because of a bug) then you can't be sure it hasn't got security implications somewhere.