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

191–200 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#191

Post by duneroadrunner »

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…

If you're using modern C++ you might consider using SaferCPlusPlus[1] for improved memory safety. Safe, fast compatible direct substitutes for C++'s unsafe elements (pointers, arrays, vectors, even references are technically unsafe). Small, easy to use, no dependency risk, and can be optionally "disabled" with a compile-time directive. It's the best answer to the Rust crowd who (justifiably) point out the inevitability of memory bugs in large enough C++ code bases.

[1] shameless plug: https://github.com/duneroadrunner/SaferCPlusPlus

Re: BearSSL – Smaller SSL/TLS

#192

Post by School-Cotton »

pcwalton wrote: post #187
falcolas wrote: post #186

Earlier quoted context omitted.

> There are so many variables here that using the benchmarks game will not give you an accurate picture. Hence the comment "With all the usual disclaimers about the inaccuracy of benchmarks". But it still gives a good, practical starting point for discussions. You're welcome to provide a counter data set to further the discussion. > Any function you call from some other library can call malloc under the hood. We're d…

> Hence the comment "With all the usual disclaimers about the inaccuracy of benchmarks". But it still gives a good, practical starting point for discussions. You're welcome to provide a counter data set to further the discussion. There is nothing you can do in C++ that you can't do in Rust as far as memory is concerned. The compiler backends are even identical! You can drop libstd if you want in Rust, which you proba…

If Rust and C are in fact "isomorphic" then what's the advantage of using Rust over C?

Re: BearSSL – Smaller SSL/TLS

#193

Post by pcwalton »

School-Cotton wrote: post #192
pcwalton wrote: post #187

Earlier quoted context omitted.

> Hence the comment "With all the usual disclaimers about the inaccuracy of benchmarks". But it still gives a good, practical starting point for discussions. You're welcome to provide a counter data set to further the discussion. There is nothing you can do in C++ that you can't do in Rust as far as memory is concerned. The compiler backends are even identical! You can drop libstd if you want in Rust, which you proba…

If Rust and C are in fact "isomorphic" then what's the advantage of using Rust over C?

I don't mean "isomorphic" in that every Rust feature has a corresponding C feature. I mean that you can replicate every runtime C feature in Rust, and vice versa. The advantage of Rust is that you get a lot more safety guarantees and ergonomic features out of the compiler than you would with C.

Re: BearSSL – Smaller SSL/TLS

#194

Post by savara »

DasIch wrote: post #65
savara wrote: post #53

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.

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.

Sure, I agree -- but that's not what the page claims. It says "insecure protocol versions and choices of algorithms are not supported, by design" -- the protocols and modes that I listed are known to have various insecurities, and it still supports them. I agree that to be useful it's necessary to support old, less secure or even insecure modes, but this is at odds with the above stated goal.

My point is about the imprecise description.

Re: BearSSL – Smaller SSL/TLS

#195

Post by fdr »

nwmcsween wrote: post #112
dimman wrote: post #61

Earlier quoted context omitted.

No really he should not. A separate translation layer is free for anyone to write though. The OpenSSL design from an API perspective is basically as far from "user friendly" as possibly possible. Having a hard-to-use API means that it's hard to get things right. If things are hard to get right it leads to more bugs. You get where I'm going with this. A clean, simple to use, or rather hard-to-use-in-a-wrong-way API is…

I don't really know what you mean about a hard-to-use api as openssl compat would just wrap the bearssl api and not make any difference to consumers of bearssl.

The problem is that OpenSSL's API itself is quite complicated and probably not in an entirely necessary way. As but one concrete example, there's almost no particularly satisfying way to handle the "error queue" in a world with imperfect software. I also recently found how how insanely impractical it is in practice to perform one's own certificate validation (e.g. so I could interpret the CN field) if a TLS connection is abstracted even a tiny bit (e.g. in a database driver).

Little doubt that someone would find it useful, but it is An Undertaking, to preserve something which is not that desirable.

Re: BearSSL – Smaller SSL/TLS

#196

Post by DasIch »

savara wrote: post #194
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.

Sure, I agree -- but that's not what the page claims. It says "insecure protocol versions and choices of algorithms are not supported, by design" -- the protocols and modes that I listed are known to have various insecurities, and it still supports them. I agree that to be useful it's necessary to support old, less secure or even insecure modes, but this is at odds with the above stated goal. My point is about the im…

You're right technically but don't you think that's a little bit pedantic?

If your goal is to truly improve the state of the art in the ecosystem, dropping anything that is even remotely insecure is appealing I get that and I do believe the people behind BearSSL would love to do that. However to truly improve anything you need two things: Popularity and improve security.

There is a conflict there because popularity requires, at least some, compatibility to what already exists. You need to balance out security and compatibility. I think there is room for discussion about where precisely that balance is. You could further tilt it towards security by helping users of the library get a sense of what they need to support. Ultimately though you can't just blindly drop everything that's somehow not perfectly secure. Doing so would not improve security at all.

It's a small sacrifice to have one library be a little bit less secure than it could be, if that helps to make everything more secure it all.

Re: BearSSL – Smaller SSL/TLS

#197

Post by bandrami »

pcwalton wrote: post #193
School-Cotton wrote: post #192

Earlier quoted context omitted.

If Rust and C are in fact "isomorphic" then what's the advantage of using Rust over C?

I don't mean "isomorphic" in that every Rust feature has a corresponding C feature. I mean that you can replicate every runtime C feature in Rust, and vice versa. The advantage of Rust is that you get a lot more safety guarantees and ergonomic features out of the compiler than you would with C.

Are any of those safety guarantees important to a crypto project, though? Even heartbleed wasn't a "buffer overrun" in the memory safety sense of that word: the client was asking for and receiving the contents of memory that the server had every right, from a safety standpoint, to read from.

Re: BearSSL – Smaller SSL/TLS

#198

Post by nailer »

kakwa_ wrote: post #139
st3fan wrote: post #94

Earlier quoted context omitted.

"The last thing the world needs is another immature SSL/TLS implementation" Are you saying we should live forever with the established SSL libraries? The only way software can mature, is to write it, release it, ship it, fix it, repeat.

Implying you have the resources to do so correctly. Which was the issue with OpenSSL. Completely unrelated but: https://tls.mbed.org/ Another small footprint ssl/tls library, very readable code and a pleasure to work with.

I'm not sure that was the issue with OpenSSL. According to the libressl folks the OpenSSL team were spending massive amounts of time on FIPS support at the expense of known serious issues the OpenBSD team had raised.

Re: BearSSL – Smaller SSL/TLS

#200

Post by ConroyBumpus »

nailer wrote: post #199
jamhan wrote: post #174

Earlier quoted context omitted.

Or your name is "Olivia Gray". (True story, corporate mail filter blocked all that person's email)

Why? 50 Shades? Something else?

Remove the space from her name and then look for a word in the middle that is commonly associated with spam emails.
Post reply on HN