Hacker News Reader

Comment by tptacek | Hacker News Reader

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.

View on HN

Of those, Camellia isn't altogether terrible, and still somewhat important for the box checkers in Japan.

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...

OCSP? Surely Chromium and Google servers use this. Edit: Ohhhh, just the protocol; stapling and parsing are fine.

<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:

https://www.imperialviolet.org/2014/04/19/revchecking.html

Revocation doesn't really work yet. Is there deployed stapling-required yet?</strike>

See AGL's comment below.

I think it just became a RFC.

200,000 lines of code doesn't sound like a whole lot. Couldn't someone like Google rewrite it in Rust?

I think Rust has to mature some more. As far as I know, it is currently not possible to implement constant-time functions using stable Rust.

That's been the consensus I've seen from the group working on Octavo, a rust crypto library. http://lukasz.niemier.pl/octavo/octavo/index.html

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.

> 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]

[1] https://github.com/rust-lang/rfcs/pull/129/files

[2] http://rust-dev.1092773.n5.nabble.com/Rust-crypto-highlights...

[3] https://github.com/klutzy/nadeko

[4] https://github.com/rust-lang/rfcs/issues/1274

[5] https://internals.rust-lang.org/t/stabilization-path-for-asm...

Why do you need asm! for it? .s files exist, and as far as I understand, are easy to link to.

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?

I am not like Google, but I'm already doing something like that: https://github.com/briansmith/ring and https://github.com/briansmith/webpki.

Someone at Google (the author of the blog post, Adam Langley) rewrote a lot of what OpenSSL does in Go: https://golang.org/pkg/crypto/

Reply on news.ycombinator.com