BearSSL – Smaller SSL/TLS • Hacker News Board

Re: BearSSL – Smaller SSL/TLS

#51

Post by falcolas » Thu, Nov 03, 2016, 2:42 PM UTC

ayrx wrote: post #42

falcolas wrote: post #41

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

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.

It's not as if wolfSSL is a new kid on the block in the world of embedded SSL.

Re: BearSSL – Smaller SSL/TLS

#52

Post by mSparks » Thu, Nov 03, 2016, 2:44 PM UTC

BillinghamJ wrote: post #19

mSparks wrote: post #11

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

well. actually looks better from the start:

There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)

On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.

Re: BearSSL – Smaller SSL/TLS

#53

Post by savara » Thu, Nov 03, 2016, 2:46 PM UTC

The page claims: "[...] insecure protocol versions and choices of algorithms are not supported, by design",

followed by:

"TLS 1.0, TLS 1.1 and TLS 1.2 are supported", "3DES/CBC encryption algorithms are supported", and "SHA-1 [is supported]"

Sad-face.

Re: BearSSL – Smaller SSL/TLS

#54

Post by stompin » Thu, Nov 03, 2016, 2:46 PM UTC

Given various clues such as: -"OS-less" -small memory footprint -going out of their way to include discussion of legal jurisdictions -the author and past activities -performance seems not a major concern

Makes me suspect that a major goal is anonymity. It's less aimed at users installing on their non-anonymous Windows/Mac/phone but rather leverage generic/commodity hardware to communicate over SSL. Throwaway burner phones.

Re: BearSSL – Smaller SSL/TLS

#55

Post by stompin » Thu, Nov 03, 2016, 2:47 PM UTC

mythz wrote: post #14

The last thing the world needs is another immature SSL/TLS implementation however this makes it very interesting: > No dynamic allocation whatsoever. There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems,…

Is there any evidence that memcpy/memmove outperform malloc?

Re: BearSSL – Smaller SSL/TLS

#56

Post by bluejekyll » Thu, Nov 03, 2016, 2:48 PM UTC

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

Re: BearSSL – Smaller SSL/TLS

#57

Post by bluejekyll » Thu, Nov 03, 2016, 2:49 PM UTC

stompin wrote: post #55

mythz wrote: post #14

The last thing the world needs is another immature SSL/TLS implementation however this makes it very interesting: > No dynamic allocation whatsoever. There is not a single malloc() call in all the library. In fact, the whole of BearSSL requires only memcpy(), memmove(), memcmp() and strlen() from the underlying C library. This makes it utterly portable even in the most special, OS-less situations. (On “big” systems,…

Is there any evidence that memcpy/memmove outperform malloc?

I think the implication is that without malloc you will remove a slew of potential bugs related to memory management, making the software more stable.

Re: BearSSL – Smaller SSL/TLS

#58

Post by unwind » Thu, Nov 03, 2016, 2:49 PM UTC

pornin wrote: post #43

unwind wrote: post #36

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

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.

Re: BearSSL – Smaller SSL/TLS

#59

Post by mythz » Thu, Nov 03, 2016, 2:51 PM UTC

falcolas wrote: post #51

ayrx wrote: post #42

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

It has nothing to do with WolfSSL, Thomas uses a Bear as his avatar, done. I've never heard of WolfSSL, but Thomas's name and avatar was instantly familiar as someone who's contributed a wealth of invaluable Crypto knowledge to the world.

Re: BearSSL – Smaller SSL/TLS

#60

Post by byuu » Thu, Nov 03, 2016, 2:55 PM UTC

oconnor663 wrote: post #34

near wrote: post #24

Earlier quoted context omitted.

This thinking is why Heartbleed was such a disaster. Everyone left it to someone else, and the end result was OpenSSL being the only serious choice. Yet even the 'experts' got it wrong -- way wrong. I'm not advocating everyone and their mother implement their own crypto. But some software diversity is a good thing. These algorithms aren't quite as scary or fickle as the documentation and existing implementations make…

> Yet even DJB's stuff can be simplified. You can knock off a good 80% of the scary code at a cost of a mere 10% of performance. Wouldn't you say DJB (et al) did that themselves? https://tweetnacl.cr.yp.to/

I haven't benchmarked TweetNaCl's performance yet, but I think that goes way too far into making the code completely unreadable. The 80%/10% number I gave is against the ref10 implementation.

Compare theirs: https://tweetnacl.cr.yp.to/20140427/tweetnacl.c

To mine:

https://gitlab.com/higan/higan/blob/master/nall/elliptic-cur...

https://gitlab.com/higan/higan/blob/master/nall/cipher/chach...

https://gitlab.com/higan/higan/blob/master/nall/mac/poly1305...

https://gitlab.com/higan/higan/blob/master/nall/hash/sha256....

Please note that like BearSSL, my implementations are alpha-quality. Further, I'm not suggesting anyone use these in production. If I do so myself and it blows up in my face, it'll only have harmed me, and I'll only have myself to blame.

(Also, I'm really bad when it comes to source code comments, sorry. The why really needs you to read the research papers; the how is mostly self-evident. The remaining one-letter variable names were used to match the papers, and because I couldn't think of more descriptive terms.)