finally might be able to handle SSL requests on memory-constrained Arduino / ESP-8266 projects?! Yes please!
BearSSL – Smaller SSL/TLS
91–100 of 206 posts
Re: BearSSL – Smaller SSL/TLS
#92Libraries like this are almost invariably a terrible idea: none of the more recent alternatives to OpenSSL I've seen have avoided resurrecting crypto bugs OpenSSL fixed years ago. But: Thomas Pornin! So, this is pretty neat. I hope lots of crypto people take a very hard look at it.
Yeah, the general wisdom is, basically, "if you don't know what you're doing, leave the crypto to the experts". I don't know the guy but, from what I gather, he is considered to one of these experts, yes? (Edit: If I would have read further comments before replying, I would've found the answer to my question.)
Yep!
Re: BearSSL – Smaller SSL/TLS
#93The 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,…
> The last thing the world needs is another immature SSL/TLS implementation
Here's an interesting thought: you don't become mature without starting somewhere.
Re: BearSSL – Smaller SSL/TLS
#94The 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,…
"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.
Re: BearSSL – Smaller SSL/TLS
#95I 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.
> with the eventual goal of being pure Rust No, being pure Rust is not the goal. It aims to use Rust as much as possible for the parts that Rust is good at. But core crypto algorithms generally need to be written in assembler, to avoid various timing attacks that could be introduced by optimization. And for things that would require large amounts of `unsafe` in Rust, there's less reason to port that to Rust, and leav…
> to avoid various timing attacks that could be introduced by optimization
Assembler only goes so far. Until you figure out how the processor's front end will decode the machine code and run the underlying RISC program, or how the hypervisor will schedule your program on some shared machines (e.g. in EC2) you're susceptible to a different class of side-channel attacks.
Re: BearSSL – Smaller SSL/TLS
#96I 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.
> with the eventual goal of being pure Rust No, being pure Rust is not the goal. It aims to use Rust as much as possible for the parts that Rust is good at. But core crypto algorithms generally need to be written in assembler, to avoid various timing attacks that could be introduced by optimization. And for things that would require large amounts of `unsafe` in Rust, there's less reason to port that to Rust, and leav…
> to avoid various timing attacks that could be introduced by optimization
Assembler only goes so far. Until you figure out how the processor's front end will decode the machine code and run the underlying RISC program, or how the hypervisor will schedule your program on some shared machines (e.g. in EC2) you're susceptible to a different class of side-channel attacks.
Re: BearSSL – Smaller SSL/TLS
#97The 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.
Why not? TLS 1.3 is dropping those algorithms.
Re: BearSSL – Smaller SSL/TLS
#98The 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,…
What sorts of applications are written for OS-less systems that require a TLS library?
EDIT: Thanks for the sincere responses. In retrospect my question might have appeared smarmy, but that wasn't my intent and I really appreciate the responses.
Re: BearSSL – Smaller SSL/TLS
#99The 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.
While those algorithms all have weaknesses they are not yet completely broken and are still in wide (if declining) use. TLS 1.0 is most affected by BEAST but all modern clients have mitigations that have proven to be effective against it. The biggest issue with 3DES is its use of 64-bit blocks making it vulnerable to the SWEET32 attack, however that requires a huge amount of traffic under the same key (100s of gigabytes). SHA1 has been shown to be weak but as far as I know there are no practical attacks against it yet.
These algorithms should obviously only be used in fallback to stronger ones but they are not broken to the point where they should never be used as SSL3, RC4, and MD5 have been.
Re: BearSSL – Smaller SSL/TLS
#100Oh man, can't wait for the docs. TLS 1.2 on an ESP8266 would make it possible to use them with AWS IoT.