Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

BearSSL – Smaller SSL/TLS

bearssl.org

Post reply on HN
Print view View original

11–20 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#11

Post by mSparks »

rdeboo wrote: post #4
lexman0 wrote: post #3

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

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?

Re: BearSSL – Smaller SSL/TLS

#12

Post by throwawayReply »

keymone wrote: post #10
lexman0 wrote: post #3

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

this might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.

Nobody gets fired for linking openssl.

Re: BearSSL – Smaller SSL/TLS

#14

Post by mythz »

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

Edit: Just discovered what makes this an even more interesting one to watch, it's the work of this Wizard: http://security.stackexchange.com/users/655/thomas-pornin

Re: BearSSL – Smaller SSL/TLS

#15

Post by drzaiusapelord »

eganist wrote: post #13

Edit: http://www.bolet.org/~pornin/cv-en.html Disregard me.

Says who? Maybe the cruft of the old ones means its impractical to fix. Maybe the leadership of the old ones means it can't be fixed due to incompetence or toxic politics. Sometimes rolling your own or forking is the smart move. There's a reason you use x.org and not xfree86 for example.

The idea that no one should ever roll their own cryptography is a cutesey warning for amateurs, but not an absolute rule. If no one ever did, we would never have any.

Also projects like openssl don't have third-party quarterly audits or other formal practices. They're "rolling their own" as much as the other guy.

Re: BearSSL – Smaller SSL/TLS

#16

Post by mpettitt »

rdeboo wrote: post #2

One 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?

This is a very important point. When it comes to implementing new software, especially in a critical field like crypto, it takes a long time for acceptance to build.

As alpha software, I'd be shocked if anyone was using it in a production capacity, but it could be useful for early investigations into issues like timing attacks - clearly, it's better to get them sorted before a "final" release. I'd hope that any project planning to adopt this or any) crypto code was first getting it analysed carefully.

On the other hand, quite a bit of existing crypto is there because it was the first implementation on a given platform, despite potentially having issues - think about heartbleed, which was missed for quite a while in very heavily used software. It's not always bad to have fresh alternatives, as long as they are approached cautiously.

Re: BearSSL – Smaller SSL/TLS

#19

Post by BillinghamJ »

mSparks wrote: post #11
rdeboo wrote: post #4

Earlier quoted context omitted.

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.

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.

Re: BearSSL – Smaller SSL/TLS

#20

Post by [deleted] »

mSparks wrote: post #11
rdeboo wrote: post #4

Earlier quoted context omitted.

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.

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?

[deleted]
Post reply on HN