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

61–70 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#61

Post by dimman »

nwmcsween wrote: post #39

Please make a openssl compat api if possible, its incredibly hard porting n programs to $ssl.

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 very much needed (and there are some libraries that are nice to use but not very proven).

Re: BearSSL – Smaller SSL/TLS

#62

Post by stompin »

pornin wrote: post #38
seibelj wrote: post #18

Earlier quoted context omitted.

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 pr…

do you really need coroutines for cert decoding and handling of handshake messages? It's not like you can parallelize these things and do something else in the meantime...

Re: BearSSL – Smaller SSL/TLS

#63

Post by stompin »

bluejekyll wrote: post #57
stompin wrote: post #55

Earlier quoted context omitted.

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.

and moves and copies won't have potential for other memory management bugs? You'll still have memory management overhead and now additional complexity.

Re: BearSSL – Smaller SSL/TLS

#64

Post by DasIch »

stompin wrote: post #54

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 p…

This just looks like someone who is aware of the complex legal history associated with cryptography and has considered embedded devices in the design of the library.

Considering the recent events around IoT having good crypto libraries for that seems like it could be useful.

Re: BearSSL – Smaller SSL/TLS

#65

Post by DasIch »

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.

Re: BearSSL – Smaller SSL/TLS

#66

Post by ajross »

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?

Many real time systems and applications disallow heap usage, because they have formal verification requirements that can't be met with dynamic memory that may "run out" depending on run time state.

Re: BearSSL – Smaller SSL/TLS

#68

Post by seibelj »

pornin wrote: post #38
seibelj wrote: post #18

Earlier quoted context omitted.

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 pr…

Thanks for your response! I'm going to shoot you an email, I would be interested in helping you with this project.

Re: BearSSL – Smaller SSL/TLS

#70

Post by unwind »

pornin wrote: post #38
seibelj wrote: post #18

Earlier quoted context omitted.

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 pr…

Here's a link to the first T0 code I found, for the interested readers out there: https://bearssl.org/gitweb/?p=BearSSL;a=blob;f=src/x509/x509....
Post reply on HN