An 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).
BearSSL – Smaller SSL/TLS
41–50 of 206 posts
Re: BearSSL – Smaller SSL/TLS
#42An 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.
Re: BearSSL – Smaller SSL/TLS
#43This sounded very interesting. However, it seems it's been developed "in secret" and the only public commit is a huge import of all of it. :/ Too bad, the development history would have been very interesting to read, digesting it all at once is harder.
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.
Re: BearSSL – Smaller SSL/TLS
#44[deleted]
Re: BearSSL – Smaller SSL/TLS
#45Earlier quoted context omitted.
Generally the cliche is about not implementing your own cryptographic algorithms. As long as they only implement existing algorithms and don't generate new ones, I don't think this applies.
I used to think that; but I'm following Dan Boneh's crypto course on Coursera at the moment, and he specifically notes that you should not even try to implement known algorithms yourself (for production; you could do it ofcourse for the learning experience). The reason is that there are subtle attacks on the implementation, such as timing attacks, which can leak information.
[deleted]
Re: BearSSL – Smaller SSL/TLS
#46One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
I was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.
After a little bit of looking around on the internet, I think I agree.
Re: BearSSL – Smaller SSL/TLS
#47This sounded very interesting. However, it seems it's been developed "in secret" and the only public commit is a huge import of all of it. :/ Too bad, the development history would have been very interesting to read, digesting it all at once is harder.
[deleted]
Re: BearSSL – Smaller SSL/TLS
#48> written in C Stopped reading there.
you should have read the rest before commenting. This is ideal for embedded targets and C is the best way to write a truly portable library for these small targets. Consider that a lot of embedded code is designed to avoid mallocs() altogether and that helps a lot.
Having a C binding doesn't mean you have to implement the bulk of the code in C.
Re: BearSSL – Smaller SSL/TLS
#49One of the cliches about crypto is that you should not implement your own crypto. Not to suggest that the authors don't know what they are doing, but they mention 'alpha' quality themselves on the site. I wonder, how long does it take until a new library is deemed secure? What does the process look like? Trial and error? Or do they compare notes with vulnerabilities found in e.g. openssl?
It is a combination of "many eyes" and "good documentation". What is needed is some good text that describes the design choice, the rationale, and all the tricky details; and then people who read it and think about it. I'll write and publish such text within the next few months.
So I guess it is going to take years.
Generally, open source software benefits from more users. But having a huge amount of users makes it more difficult to improve and cleanup because you can't just deprecate stuff easily. (like SSL2/3).
Also, having 100% of the internet using openssl makes the impact of a vulnerability in that library huge. Some diversity is probably a good thing.
I appreciate the time and effort that you are putting into it, good luck.
Re: BearSSL – Smaller SSL/TLS
#50Please make a openssl compat api if possible, its incredibly hard porting n programs to $ssl.
I'm pretty sure that this library would lose many of its advantages (small footprint, no allocations) when you slap an OpenSSL facade on it.