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

31–40 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#31

Post by banach »

seibelj wrote: post #18
Perceptes wrote: post #8

> written in C Stopped reading there.

What would be a better language for creating a small, portable crypto library that works on embedded systems? Would you really put your trust in a brand new language?

Given that this is a reasonably small code base (compared to, say, an OS kernel), an idea would be to use a language that provides strong guarantees about correctness the implementation. For example, Spark Ada can be used to do that. Alternatively, keeping the implementation in C, a similar level of assurance could be achieved by developing the library along with a specification, and requiring any extensions to pass some kind of correctness proof based on this specification.

Re: BearSSL – Smaller SSL/TLS

#32

Post by mythz »

dchest wrote: post #25
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?

I was skeptical, but then saw: author Thomas Pornin Yeah, "should not implement your own crypto" doesn't apply to him.

Definitely, most of my crypto searches ends up landing on one of his answers :)

Re: BearSSL – Smaller SSL/TLS

#33

Post by adrianN »

user5994461 wrote: post #23
oconnor663 wrote: post #21

Earlier quoted context omitted.

A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .

Only because they don't know Ada and they wanna reinvent the wheel again /s

I agree that Ada is a lot better than C, but the guarantees Ada provides are different from the guarantees Rust provides.

Re: BearSSL – Smaller SSL/TLS

#34

Post by oconnor663 »

near wrote: post #24
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.

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/

Re: BearSSL – Smaller SSL/TLS

#35

Post by falcolas »

oconnor663 wrote: post #21
bandrami wrote: post #17

Earlier quoted context omitted.

Why? Crypto in a memory-managed language is not just a bad idea but a horrifically bad idea because you expose yourself to every single bug in the runtime's memory management.

A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .

Rust can't target the same platforms C can. Rust is also (generally) more memory intensive than C for similar programs. This makes its use in embedded situations a non-starter (at least for now).

Re: BearSSL – Smaller SSL/TLS

#36

Post by unwind »

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.

Re: BearSSL – Smaller SSL/TLS

#37

Post by oconnor663 »

mbanzi wrote: post #28
oconnor663 wrote: post #21

Earlier quoted context omitted.

A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .

Are there mature versions of rust for the hundreds of microcontrollers that people are in production right now? Most of them have a decent GCC port and C works on all of them..

Rust uses LLVM on the backend, so it gets a lot of platform support for free. Not sure how mature that stuff is yet though. Maybe someone who's used Rust for embedded can jump in and comment?

Re: BearSSL – Smaller SSL/TLS

#38

Post by pornin »

seibelj wrote: post #18
Perceptes wrote: post #8

> written in C Stopped reading there.

What would be a better language for creating a small, portable crypto library that works on embedded systems? Would you really put your trust in a brand new language?

Actually, C is a horrible language in many respects, but it is also the only language that can achieve any kind of decent compatibility in embedded systems, which is why I used it.

Also, when I say that BearSSL is written in C, it is partly a lie: some of it (especially X.509 certificate decoding, and handling of handshake messages) is done in T0, a new Forth-like language that I invented for the task (compiler is provided, and produces C code), specifically to have coroutines (incidentally, it means that most of that code read things byte by byte, with relatively few accesses to buffers, thus less potential buffer overflows).

Re: BearSSL – Smaller SSL/TLS

#40

Post by eganist »

drzaiusapelord wrote: post #15
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…

Doesn't matter anymore -- the credibility of the person leading the project is thoroughly established, so I'm retracting my comment.

But generally, "says who" is answerable as "says any reputable applied cryptographer, established audit/research team, etc. who's thoroughly cut their teeth on crypto and security in general."

Post reply on HN