Theo's opinion about BoringSSL and LibreSSL portability: <a href="http://article.gmane.org/gmane.os.openbsd.tech/37174" rel="nofollow">http://article.gmane.org/gmane.os.openbsd.tech/37174</a>
So from what I understand, Google has a bunch of OpenSSL patches they use. They used to re-apply those patches to each new OpenSSL release, but now they're going to keep their own branch (BoringSSL) and pull and merge changes from OpenSSL?<p>What are the costs/benifits of one method over the other?
Great news! Hopefully between LibreSSL and BoringSSL, OpenSSL will go away and never return. I think AGL and the LibreSSL team will be able to do some fantastic informal collaboration. I'm looking forward to a healthy TLS ecosystem.
How, if at all, is this envisioned to interact with the work going on in LibreSSL?<p>I realize LibreSSL is optimized for BSD and Google is primarily Linux, but it seems silly to fork the code in 2 different directions.
Makes a hell of a lot more sense than rebasing 70-odd separate patches for your internal use! Making LibReSSL-portable is a good goal, and this work can be used to improve both (and OpenSSL, too - some of this found its way into the OpenSSL 1.2 branch).<p>I think the "safe" (EC)DSA nonce implementation is interesting but could use some review, and I've communicated that to the author: it's not as good as the proposal in RFC6979[1] (which uses HMAC_DRBG - which is good - to generate a truly deterministic DSA nonce, with test vectors and everything!). In particular, BN_generate_dsa_nonce from these patches uses modular reduction down into the prime order, which has a small bias towards 0 of course. The NIST prime orders aren't as close to powers of two as you might like to get away with that, and if I'm being honest, I'm not sure you can get away with <i>anything</i> with (EC)DSA - it is extraordinarily fragile in a way I think was always deliberate. The practical impact is probably limited, but I really don't want to take any chances there. (Ideally I'd want Ed25519, or something very like it - there really ought to be some more discussion on CFRG about that - although it's going to be quite some time before anyone can roll it out in certificates widely.)<p>Right now, it's still lipstick on a pig. OpenSSL is hairy as fuck. Long-term, I think the LibReSSL cleanup-via-demolition approach and then carefully rebuilding what's left over is what's needed. But I'm not sure I'd want to run LibReSSL in the middle of such fundamental reworking - and in the meantime, some of these patches look quite familiar to me. :)
___
1. <a href="https://tools.ietf.org/html/rfc6979" rel="nofollow">https://tools.ietf.org/html/rfc6979</a> - Deterministic Usage of the Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (ECDSA)