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

181–190 of 206 posts

Re: BearSSL – Smaller SSL/TLS

#181

Post by conradev »

adrianN wrote: post #146
conradev wrote: post #124

Earlier quoted context omitted.

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)

Verifying a signature is not the simplest thing to do on hardware that doesn't even support a normal OS.

I see, that makes sense. Let's say you implement verification as:

1. Hashing the incoming data

2. Decrypting an attached signature

3. Verifying the decrypted and calculated hash are the same

Even though Step 2 would involve RSA or ECC, wouldn't Step 1 be the most expensive part regardless?

Re: BearSSL – Smaller SSL/TLS

#182

Post by erichocean »

revelation wrote: post #176
conradev wrote: post #124

Earlier quoted context omitted.

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)

RSA means big integer which means unhappy performance on devices that often don't even have floating point in hardware. I think elliptic curve could be faster?

> I think elliptic curve could be faster?

Yes, EdDSA is faster, with 64 byte signatures. Recommended.

https://en.wikipedia.org/wiki/EdDSA

Re: BearSSL – Smaller SSL/TLS

#183

Post by nwmcsween »

pilif wrote: post #76
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.

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

It depends, does malloc have some form of hardening? does the compiler insert stack canaries?

Re: BearSSL – Smaller SSL/TLS

#184

Post by bandrami »

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 .

But rust has the exact same problem: if it's "safe", it's ironically not "secure" because the algorithm no longer controls its own memory operations. If you can't say, for instance, that the key is never swapped out, then it's not secure. But if you can say the key is never swapped out, you're at a level of direct memory control that is no longer "safe".

Re: BearSSL – Smaller SSL/TLS

#185

Post by oconnor663 »

pcwalton wrote: post #169
oconnor663 wrote: post #147

Earlier quoted context omitted.

Maybe falcolas means that in the same way that C++ is more memory intensive than C for similar programs, because both C++ and Rust encourage a lot of Vecs/Strings that implicitly allocate on the heap?

Rust doesn't encourage that.

I suppose everything's a continuum with this stuff, but here's one library I ran into where I was a little disappointed to find a heap allocation: https://dnaq.github.io/sodiumoxide/sodiumoxide/crypto/secret...

Re: BearSSL – Smaller SSL/TLS

#186

Post by falcolas »

pcwalton wrote: post #177
falcolas wrote: post #175

Earlier quoted context omitted.

> [citation needed] With all the usual disclaimers about the inaccuracy of benchmarks: https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... As a side note, can you guarantee you are not allocating memory (calling malloc) with Rust? I know how to do it in C, but Rust has another layer of indirection. > Name one platform you need to run a TLS stack on that LLVM doesn't have support for. Have a look yourself:…

> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... . There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks…

> 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 discussing low level libraries which aren't really calling out to other libraries, allowing you to quite easily control your memory allocation. It's also fairly easy to grep for 'malloc' in a C codebase, or inspect a compiled library for the malloc syscall.

I took a few minutes and looked at the current state of Rust with memory allocation as well, and it certainly does seem possible to remain within the stack only, by avoiding Box, Vec, String, and the various reference counted containers. Great to see.

There do seem to be some lingering limitations with stack-based data primitives and generics, but it's nothing you couldn't work around if you wanted to.

> unless people actually need those architectures

Like ATMega? If an architecture is supported in modern versions of GCC, there's a good chance that it's needed by somebody. And that doesn't count the dozens of specialized C compilers for other non-standard architectures. Modern banks are still running Cobol on mainframes, after all, and microcontrollers are everywhere.

> AVR support is coming along well.

Mind pointing me at a reference on, say, LLVM's roadmap? I see a fairly constant level of activity on the avr-llvm github repo, but nothing that appears to state it's ready for inclusion in LLVM in any defined timeframe.

Also curious about MSP430 moving out of experimental, Microchip's PIC, the Intel 8051, Hitachi's SuperH...

> make Rust a "non-starter", any more than it makes OpenSSL a "non-starter".

Wait, you're comparing a programming language to a heavy duty crypto library? Quite the literal version of comparing apples and oranges. Or apples and an Orange Julius.

There are other plenty of other crypto libraries that are aimed at microprocessors that aren't OpenSSL; wolfSSL as an example.

Ultimately, with enough time and money, Rust is capable of competing with C for the embedded space, making a lot of embedded developers happy. But not in the forseeable future.

Re: BearSSL – Smaller SSL/TLS

#187

Post by pcwalton »

falcolas wrote: post #186
pcwalton wrote: post #177

Earlier quoted context omitted.

> https://benchmarksgame.alioth.debian.org/u64q/compare.php?la... . There are so many variables here that using the benchmarks game will not give you an accurate picture. You may well just be benchmarking jemalloc vs. glibc's allocator. jemalloc is tuned for speed of allocation in threaded contexts (with e.g. TLABs), not minimum memory usage. If you want, you can use the system allocator with Rust; for the benchmarks…

> 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 probably would in the microcontroller use case. You can even translate C to Rust [1], which should result in virtually identical LLVM IR!

That's what's so frustrating about throwing out benchmarks game numbers: the languages are isomorphic, so you end up ultimately comparing things like jemalloc implementations.

> Like ATMega? If an architecture is supported in modern versions of GCC, there's a good chance that it's needed by somebody. And that doesn't count the dozens of specialized C compilers for other non-standard architectures. Modern banks are still running Cobol on mainframes, after all, and microcontrollers are everywhere.

Why is COBOL on mainframes relevant? We're talking about C++ here. (Anyway, if you want to bring up mainframes, IBM has a working SystemZ backend for LLVM.)

Talking about "microcontrollers" is too broad of a brush. A lot of microcontrollers are ARM (or MIPS, etc.). Rust runs just fine on those.

> Ultimately, with enough time and money, Rust is capable of competing with C for the embedded space, making a lot of embedded developers happy. But not in the forseeable future.

This is again way too strong of a statement, because we have people using Rust right now for embedded IoT use cases (including some at Mozilla!) It all depends on what you need. If LLVM supports your architecture (which is probably does) then great! If it doesn't, then let's talk about the specific architecture you need and what you need it for, rather than making blanket "Rust is a non-starter for embedded use" statements.

We're never going to get support for every architecture anyone can come up with that C has ever run on. But who cares? What matters is whether Rust runs on a platform you were seriously considering using Rust for. If it doesn't, then we can get that fixed; chances are if you want that architecture, someone else using LLVM does too.

[1]: https://github.com/jameysharp/corrode

Re: BearSSL – Smaller SSL/TLS

#188

Post by nine_k »

throwawayReply wrote: post #12
keymone wrote: post #10

Earlier quoted context omitted.

this might give people false sense of security. implementing own crypto exposes you and those few souls that bought into your story. implementing bug-free "proven crypto" is near impossible task, but "proven crypto" part sells much better and so exposes many more un-expecting victims.

Nobody gets fired for linking openssl.

...yet. Not sure about 10 years from now.

Re: BearSSL – Smaller SSL/TLS

#189

Post by bluejekyll »

Sir_Cmpwn wrote: post #143
bluejekyll wrote: post #56

I love the idea of a zero allocation crypto library, but isn't the fact that this is also in C going eventually lead down a similar path as that of OpenSSL? I'm personally really excited for this: https://github.com/briansmith/ring It's a Rust oxidization of the BoringSSL library, meaning that parts of BoringSSL are being rewritten in Rust, with the eventual goal of being pure Rust.

The problem with OpenSSL is less about the language it's written in and more about the age of the project, discipline of the developers, quality of the codebase, and its prevalance - which leads to its vulnerabilities having a high impact. OpenSSL's code is a heap of trash and that's why it's vulnerable, not neccessarily because it's written in C.

Sure. Though, C does nothing to help prevent you from creating that same garbage again.

So while there are excellent examples of C projects out there, there are many more that show why it's important to provide developers (even the good ones) with guard rails.

Re: BearSSL – Smaller SSL/TLS

#190

Post by [deleted] »

bandrami wrote: post #184
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 .

But rust has the exact same problem: if it's "safe", it's ironically not "secure" because the algorithm no longer controls its own memory operations. If you can't say, for instance, that the key is never swapped out, then it's not secure. But if you can say the key is never swapped out, you're at a level of direct memory control that is no longer "safe".

[deleted]
Post reply on HN