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

71–80 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#71

Post by moduspwnens14 »

stompin wrote: post #63
bluejekyll wrote: post #57

Earlier quoted context omitted.

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.

At a high level, isn't this like implementing your own "malloc" and "free" that just pulls from your process's own memory pool instead of the OS? Or is there more to it than that?

Re: BearSSL – Smaller SSL/TLS

#72

Post by pornin »

stompin wrote: post #62
pornin wrote: post #38

Earlier quoted context omitted.

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

Certificates and handshake messages are nested structures, and I want to process them in a streamed fashion (e.g. I don't buffer a complete certificate, I don't have the RAM for that; BearSSL can decode certificates and messages that are larger than the total RAM is uses), so without coroutines, I would still need some sort of decoder with a stack of states, so I just accepted it and pushed the idea to its logical conclusion.

Despite the horrors implied by a Forth syntax, this actually made writing the code easier. As a bonus, it turns out that T0-generated code is very compact, so I could pack more behaviour into less bytes.

Re: BearSSL – Smaller SSL/TLS

#73

Post by hbbio »

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.

And you are Dmitry! We use your TweetNacl-js implementation for https://github.com/wallix/PEPS!

Re: BearSSL – Smaller SSL/TLS

#74

Post by clarry »

moduspwnens14 wrote: post #71
stompin wrote: post #63

Earlier quoted context omitted.

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

At a high level, isn't this like implementing your own "malloc" and "free" that just pulls from your process's own memory pool instead of the OS? Or is there more to it than that?

No, it's just placing the appropriate structs and buffers on the stack (when not provided by the caller).

It does eliminate a certain couple classes of errors, and makes some others less likely.

I didn't read all the code, but I don't think it's using alloca or the like. So the stack allocation sizes are known at compile time, and bounded unless there's some recursion going on (which is unlikely).

Re: BearSSL – Smaller SSL/TLS

#76

Post by pilif »

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.

IMHO you're converting your heap buffer overflows into stack buffer overflows which are even easier to exploit.

Re: BearSSL – Smaller SSL/TLS

#77

Post by steveklabnik »

falcolas wrote: post #35
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 .

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

Isn't the "more memory intensive" thing mostly due to jemalloc? How are you getting this data?

Re: BearSSL – Smaller SSL/TLS

#78

Post by steveklabnik »

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

In general, the versions of Rust end up being most of them, rather than being pinned to one specific version.

As my sibling mentions, if LLVM can target it, then we can, but generally anything There's a whole group dedicated to working on this: https://github.com/rust-embedded/

Re: BearSSL – Smaller SSL/TLS

#79

Post by skykooler »

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

Re: BearSSL – Smaller SSL/TLS

#80

Post by vvanders »

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?

Almost always. Any sane implementation/system is going to need to zero memory so you're going to write 2x to it at a minimum.
Post reply on HN