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

121–130 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#121

Post by rthille »

stavros wrote: post #110
darksaints wrote: post #98

Earlier quoted context omitted.

What sorts of applications are written for OS-less systems that require a TLS library? EDIT: Thanks for the sincere responses. In retrospect my question might have appeared smarmy, but that wasn't my intent and I really appreciate the responses.

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secret and then push updates to other people's devices.

Re: BearSSL – Smaller SSL/TLS

#122

Post by tptacek »

lexman0 wrote: post #3
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?

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.

Whoah, no. It's about building crypto code at all.

Given a choice between building something with Nacl and a bespoke stream cipher and building something with a bespoke cryptosystem and AES, I would have a hard time picking, but I'd lean towards Nacl.

Re: BearSSL – Smaller SSL/TLS

#123

Post by tptacek »

sintalfoob wrote: post #97
DasIch wrote: post #65

Earlier quoted context omitted.

There is not supporting insecure protocols and then there is living in fantasy land away from everyone else. You can't drop all of these things and end up with something generally useful.

Why not? TLS 1.3 is dropping those algorithms.

See how much of the Internet you can talk to if you only support TLS 1.3.

Re: BearSSL – Smaller SSL/TLS

#124

Post by conradev »

rthille wrote: post #121
stavros wrote: post #110

Earlier quoted context omitted.

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secre…

Wouldn't signing each release with a private key be the simplest solution here?

(that can take many forms, but that general idea is how most software updates currently work)

Re: BearSSL – Smaller SSL/TLS

#125

Post by israrkhan »

Seems like it is trying to replace PolarSSL (now called mBed TLS). It even dervies the name from PolarSSL (Polar Bear). It is nice to have multiple options, however it can make the vulnerability management a nightmare. How many more SSL libraries do we need (OpenSSL, LibreSSL,S2N,GnuTLS), not to mention native SSL libraries (Secure Transport, SChannel)?

Re: BearSSL – Smaller SSL/TLS

#127

Post by andrewstuart2 »

StavrosK wrote: post #108
skykooler wrote: post #79

Earlier quoted context omitted.

And it seems the firewall here has made a clbuttic mistake, as that page is blocked due to the url containing "porn".

So you're pretty much out of luck if you want to visit a page that contains some analysis?

Well, presumably, if the author's last name is Pornin and your spam filter is pretty basic (or overzealous).

Re: BearSSL – Smaller SSL/TLS

#128

Post by captn3m0 »

skykooler wrote: post #79
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,…

And it seems the firewall here has made a clbuttic mistake, as that page is blocked due to the url containing "porn".

security.se works over HTTPS, might bypass your firewall: https://security.stackexchange.com/users/655/thomas-pornin

Re: BearSSL – Smaller SSL/TLS

#129

Post by captn3m0 »

rthille wrote: post #121
stavros wrote: post #110

Earlier quoted context omitted.

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secre…

Not a very good idea, for the very reasons you point out. Signed releases with public keys, as conradev points out below is the far better approach.

Re: BearSSL – Smaller SSL/TLS

#130

Post by wolf550e »

byuu wrote: post #60
oconnor663 wrote: post #34

Earlier quoted context omitted.

> 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/elliptic-cur... https://gitlab.com/higan/hi…

To me, C++ with operator overloading looks scary. I think a reviewer would choose to review the generated binary instead of the source code.
Post reply on HN