But large amounts of OpenSSL could simply be discarded given our more limited scope. All the following were simply never copied into the main BoringSSL: Blowfish, Camllia, CMS, compression, the ENGINE code, IDEA, JPAKE, Kerberos, MD2, MDC2, OCSP, PKCS#7, RC5, RIPE-MD, SEED, SRP, timestamping and Whirlpool. The OpenSSL that we started from has about 468,000 lines of code but, today, even with the things that we've added (including tests) BoringSSL is just 200,000.
That's one of the most heartening things about BoringSSL: they've ditched a couple things that have credible real-world use cases, because the risk/reward simply wasn't worth it.
If you leave things in to appease the box-checkers, you end up with, well, OpenSSL.
I solidly agree with that in general. Camellia actually has a funny backstory in LibreSSL. It was for many years disabled in OpenBSD because it's patented and there wasn't a completely free license grant. When we went looking for things to delete, it seemed like an obvious choice, but then Theo took another look at the patent situation and decided we could enable it. And so we ended up turning on a feature in the midst of trying to delete them.
"If you leave things in to appease the box-checkers, you end up with, well, OpenSSL."
Whoa, who, let's not be so cruel to other crypto developers. You can appease the box-checkers quite a bit without being an utter, insecure mess like OpenSSL. There's libraries that do while making the box-checking stuff optional.
It would be true had you said: If the only thing you do is leave things in to appease the box-checkers...
<strike>I don't know if that line means they've removed all OCSP support from Chromium (though I hope they did) but worth noting that AGL isn't an OCSP supporter:
> As far as I know, it is currently not possible to implement constant-time functions using stable Rust.
For those wondering, that's because asm! is not stabilised and the stabilisation path for it is unclear[0], there's also been a proposal for an alternative asm![1], Rust otherwise relies on LLVM and Brian Anderson reported[2] having
> been told by LLVM folks that getting LLVM to do constant time code generation is essentially hopeless, and it should just be written in asm.
Nadeko[3] aims to do exactly that, but because of the above only works on nightly.
[0] an RFC was created then retracted[4] for discussions on internals[5]
I'm not sure composition would work so you'd have to code every constant-time function entirely in assembler.
And now I wonder why there isn't already such a project, surely the number of necessarily constant-time functions is relatively low? Constant-time equality (of byte sequences), constant time conditional (`a if b else c`), constant-time comparison (<=) and maybe constant-time bytes copy?
It's a possible future goal of the project to end up API compatible to OpenSSL to do just what the GP was saying. I think the constant time functions are the biggest reason it can't happen yet, though there's probably more I'm just not aware of.
