Hanlon or not Hanlon?

Posted Jan 19, 2026 4:33 UTC (Mon) by marcH (subscriber, #57642)
Parent article: The State of OpenSSL for pyca/cryptography

Lack of QA and complexity make the perfect couple to hide... "intentional bugs" = backdoors. Complexity takes care of code reviews and static analysis.

I have enough experience to have observed Hanlon's razor left and right but... OpenSSL is not "any"software. It's the type of target that secret services around the world prioritize if they work as they are supposed to.

to post comments

Hanlon or not Hanlon?

Posted Jan 19, 2026 18:22 UTC (Mon) by jd (guest, #26381) [Link]

Precisely, which is why security software needs far more stringent design and QA than you'd normally use, it should be regarded as mission-critical with more than just a dash of "failure is not an option".

Open Source learned that the hard way with Skipjack and two deliberately-tained PRNGs, but also with contaminated compression libraries. Methinks it's time to stop with the learning and actually apply the lessons.

Now, I'm not suggesting that they do an SEL4 and provide end-to-end proofs of implementation correctness (although, tbh, that would be truly awesome and something I could see security vendors seriously mulling over as something they could "crowdsource" at the inter-corporate level), but there are plenty of simpler paradigms (such as contracts for functions) that could be statically checked against to detect suspicious behaviours and implementation flaws.

To be fair, though, it might well be that developers will have to pull a Linux, unless LibreSSL has a good architecture to work from (basically the EGCS approach).