Another OpenSSL alternative:
BearSSL – Smaller SSL/TLS
81–90 of 206 posts
Re: BearSSL – Smaller SSL/TLS
#82Earlier quoted context omitted.
What would be a better language for creating a small, portable crypto library that works on embedded systems? Would you really put your trust in a brand new language?
Given that this is a reasonably small code base (compared to, say, an OS kernel), an idea would be to use a language that provides strong guarantees about correctness the implementation. For example, Spark Ada can be used to do that. Alternatively, keeping the implementation in C, a similar level of assurance could be achieved by developing the library along with a specification, and requiring any extensions to pass…
The is approach taken by the F* folks on their TLS library.
Re: BearSSL – Smaller SSL/TLS
#83Earlier quoted context omitted.
cant be any worse than openssl. they have all code running in constant time from the alpha version. Next comes making sure there are no buffer overflows. the code is stable and compatible. If everyone leaves it to someone else who does it exactly? Obviously not ready for use in production until its been audited. Remind me again where i can download an audited ssl implimentation?
> cant be any worse than openssl. Not sure I'd agree with that. OpenSSL is very far from perfect and obviously contains many many security bugs, but it also has a very long history of fixes, knowledge, etc. and has a large number of eyes on it. It's more of a known quantity than something new.
OpenSSL does not have half the fixes people think it does. Generally what gets fixed is the ciphersuites some people happen to use, and the rest remain broken. For example, the constant time ECDSA signing only works with some curves, not all. It still supports horrific hacks for random number generation, instead of using OS provided interfaces. NSS is not much better on this front, but does a far better job of parsing TLS records in a sane way.
Re: BearSSL – Smaller SSL/TLS
#84If Thomas has enough time to finish it (bearing in mind the hundreds of hours it will take to bring it to production quality) - and if he has time to maintain it over the years - and if he is able to commit to years' worth of future maintenance - then this could become a very nice and usable implementation.
I think it's great when people write something for the love of it.
For a high quality TLS implementation that is production-ready, and has had extensive third-party verification and certification, I'd recommend mbedTLS from ARM.
Re: BearSSL – Smaller SSL/TLS
#85I love the idea of a zero allocation crypto library, but isn't the fact that this is also in C going eventually lead down a similar path as that of OpenSSL? I'm personally really excited for this: https://github.com/briansmith/ring It's a Rust oxidization of the BoringSSL library, meaning that parts of BoringSSL are being rewritten in Rust, with the eventual goal of being pure Rust.
> with the eventual goal of being pure Rust
No, being pure Rust is not the goal. It aims to use Rust as much as possible for the parts that Rust is good at. But core crypto algorithms generally need to be written in assembler, to avoid various timing attacks that could be introduced by optimization. And for things that would require large amounts of `unsafe` in Rust, there's less reason to port that to Rust, and leaving it in C can be more clear.
See the style guidelines from the project:
https://github.com/briansmith/ring/blob/master/STYLE.md#unsa...
The thing that are most appropriate for Rust are parsing, protocol implementation, higher level code that uses core crypto primitives, and providing a safe API to client code. But the core crypto primitives themselves will remain written in C and/or assembler, as appropriate.
Re: BearSSL – Smaller SSL/TLS
#86An obvious dig at wolfSSL - I'd be curious to see a comparison between the two. wolfSSL appears to be the more mature of the two (which makes sense, it's been in use for over a decade, and has a business dedicated to its development).
Not quite, Thomas's avatar in many places is that of a bear. He has named a few of his works after bears, in particular his password hashing function Makwa.
Huh, the first thing that came to my mind when I saw the name was this thing: https://matt.ucc.asn.au/dropbear/dropbear.html . Apparently forest animals are popular in the SSL implementation writing crowd.
Re: BearSSL – Smaller SSL/TLS
#87Earlier quoted context omitted.
Not quite, Thomas's avatar in many places is that of a bear. He has named a few of his works after bears, in particular his password hashing function Makwa.
I'll admit, they're a local company that I have a fair bit of respect for, so I'm a bit protective about people attacking them. That said, BearSSL is just too close to be coincidence. The author could have easily continued with their trend of using alternative languages and ended up with something just as unique. UrsidSSL, BhaalooSSL, XiongSSL; all could have continued the trend without coming across as a sly attack.…
But then you don't have the homophone bear/bare, with "bare" having some nice connotations when your context of the topic includes OpenSSL.
Re: BearSSL – Smaller SSL/TLS
#88Earlier quoted context omitted.
Honestly, all my internal git commit messages are "...". I intend to write (in many details) how the whole thing is designed. Give me a couple of months.
Okay, that explains it, anyway. :) I have absolutely nothing to say when it comes to crypto, but as a C dork I found it ... quirky that the encoding/decoding functions in inner.h ( https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/inner.h;h... ) seem to use e.g. uint32_t to get a 32-bit type, while assuming that char is 8 bits (rather than using uint8_t). This seems strange.
I don't think it assumes it's 8 bits, but rather it assumes the values won't be outside the range of an 8 bit number, which should be fine, given that it's an octet-oriented protocol?
Using char pointers presumably is to get correct aliasing analysis?
Re: BearSSL – Smaller SSL/TLS
#89Libraries like this are almost invariably a terrible idea: none of the more recent alternatives to OpenSSL I've seen have avoided resurrecting crypto bugs OpenSSL fixed years ago.
But: Thomas Pornin!
So, this is pretty neat. I hope lots of crypto people take a very hard look at it.
Re: BearSSL – Smaller SSL/TLS
#90Libraries like this are almost invariably a terrible idea: none of the more recent alternatives to OpenSSL I've seen have avoided resurrecting crypto bugs OpenSSL fixed years ago. But: Thomas Pornin! So, this is pretty neat. I hope lots of crypto people take a very hard look at it.
Yeah, the general wisdom is, basically, "if you don't know what you're doing, leave the crypto to the experts".
I don't know the guy but, from what I gather, he is considered to one of these experts, yes?
(Edit: If I would have read further comments before replying, I would've found the answer to my question.)