Recent searches
Search options
Administered by:
Some people are like "don't use browser forks, they will get you pwned" and while I haven't look into that, from a distance this looks like "Don't roll your own crypto".
And similar to how we don't want to discourage people from learning how to implement cryptographt, so it's more of a "Don't (let people) rely on your own crypto"
we also shouldn't discourage people from learning to work on these inscrutable behemoths that we call browser engines, so we advise people to just not rely on them
1/
But it seems to me that the browaer engine ecosystem isn't as healthy as cryptography implementation ecosystem these days.
It seems more like pre-PGP times (which I don't remember because I wasn't alive back then, so correct me if I'm wrong):
The only widely established implementations are opaque and developed by insular groups with questionable agendas.
IOW, unlike with libssl or libsodium, we desoerately need forks of browser engines.
2/
But let's take a step back: why are browser engines, which are one of the most comolex pieces of software in the world, so security critical?
Is it a skill issue that forks fail to keep the same security level as Chromium and Gecko?
Or are these two projects trying to achieve something that shouldn't be done, and they're lucky to have any resemblence of security?
Maybe Stallman was right to only open a few trusted websited in his browser, and read every other site through a sandboxed wget...
Maybe the browser we use to log in to our bank account or domain registrar should not run with the same OS privileges as the browser we use to explore random websites or watch videos
Or looked at the code of popular cryptographic libraries? Because a lot of them are downright scary and wouldn't pass an audit (remember OpenBSD reaction to OpenSSL?).
Hence why I've only ever seen serious usage of "Don't roll your own crypto" to mean "Don't make your own algorithms".
As for browsers and the like, usages should be separated *but* it should be comfortable. Because attackers will exploit your stress (check articles from people who got phished), which is where you'll choose the easiest and most immediate path, which should still be secure.
(That sadly means getting proper security on smartphones for most people)
@lanodan I've seen "don't implement crypto algorithms yourself because you'll make a timing sidechannel, a padding oracle, or just, you know, accidentally override the key with all zeros"
I've also seen
"Don't build your own protocols on top of AES and SHA-256 because cryptogrqphic primitives are not lego bricks"
@lanodan also no, I did not look at the source code of openssl, libressl, wolfssl, mbedtls, boringssl, AWS-LC, nss, or gnutls.
I heard that openssl was horrible, which led to creation of libressl.
But like, if there are enough people who understand that shit to have 8 different implementations, I think it's not the worsr in terms of skill, even if it is bad in terms of currently existing code.
well. kind of. there is a heinous mistake when you hard code a digest. when that digest is broken or you want something else for whatever reason, you can't, so we end up carrying around a dozen useless algos (this came up in the Odin repos, where there is some swedish cipher, which is basically worthless but has to be there because some protocol on the ass end of nothing hardcoded it)