No mention of *ring* I guess :/
-
-
Replying to @durumcrustulum @BRIAN_____
We've got different design goals. Ring is moving towards a pure-Rust implementation, while we're sticking BoringSSL only. Also, we're working on an introductory blog post which goes into more detail, but Hacker News jumped the gun :)
3 replies 1 retweet 4 likes -
Replying to @joshlf_ @durumcrustulum
I'm not sure that distinction will persist long-term. It depends on what kind of non-OpenSSL API boundary BoringCrypto is able/willing to provide, the memory allocation strategies it supports, the latency of the verification of its memory safety & correctness.
1 reply 0 retweets 1 like -
Replying to @BRIAN_____ @durumcrustulum
They're pretty bound by (loose) API backwards-compatibility, so I don't expect the API to change drastically any time soon. I can't speak to allocation or formal verification;
@davidben__ or@agl__ might know more.1 reply 0 retweets 1 like -
Replying to @joshlf_ @durumcrustulum and
It's not so much about changing the existing API as it is about extending it to support a non-OpenSSL API. With *ring* one can do everything, (digests, AEADs, and ECC, etc.) except RSA without heap allocs. In contrast, in OpenSSL they're moving to requiring malloc for everything.
1 reply 0 retweets 1 like -
Replying to @BRIAN_____ @durumcrustulum and
Oh I see your point. Some of BoringSSL's API is already that way, like the Ed/X25519 stuff. Not sure how far they can push it for the existing APIs, though.
1 reply 0 retweets 0 likes -
Replying to @joshlf_ @BRIAN_____ and
I think my current view on mallocs is that they're worth clearing where easy or perf-impacting. Otherwise it probably does not justify maintaining a parallel API on it's own. But if I'm already reworking something, it's on the back of my mind.
1 reply 0 retweets 2 likes -
Replying to @davidben__ @joshlf_ and
Also we're not at all suggesting that BoringSSL is some platonic ideal. We need it to support vast amounts of code that grew up with OpenSSL. It's very much shaped to meet those, Google-specific, needs. If you're not Google, the BoringSSL API is unlikely to be best for you.
1 reply 2 retweets 5 likes
It's actually more about practicalities, especially w.r.t. the FIPS 140 validation in commercial settings. Also, a lot of the work I have done in *ring* is to sketch the structure of a formally verified implementation and it's not clear that Rust (or even C) is ultimately needed.
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.