@pornin
Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices.
[invalid issue removed]
BearSSL – Smaller SSL/TLS
161–170 of 206 posts
Re: BearSSL – Smaller SSL/TLS
#162The 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.
Besides of what was already mentioned:
Many automotive or industrial communication buses are currently unencrypted, but could surely benefit from encryption.
Re: BearSSL – Smaller SSL/TLS
#163Seems like it is trying to replace PolarSSL (now called mBed TLS). It even dervies the name from PolarSSL (Polar Bear). It is nice to have multiple options, however it can make the vulnerability management a nightmare. How many more SSL libraries do we need (OpenSSL, LibreSSL,S2N,GnuTLS), not to mention native SSL libraries (Secure Transport, SChannel)?
> It even dervies the name from PolarSSL (Polar Bear
I thought it was a play on 'bare' - e.g. only the basic features needed.
Re: BearSSL – Smaller SSL/TLS
#164@pornin Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices. [invalid issue removed]
q starts out larger than len, but is decremented inside the inner for loop.
Re: BearSSL – Smaller SSL/TLS
#165Earlier quoted context omitted.
Well, presumably, if the author's last name is Porn in and your spam filter is pretty basic (or overzealous).
I wonder how it would cope with Scunthorpe
For anyone unaware: https://en.wikipedia.org/wiki/Scunthorpe_problem
Re: BearSSL – Smaller SSL/TLS
#166@pornin Thanks, we definitely need a secure and reputable TLS implementation with small footprint for IoT devices. [invalid issue removed]
q starts out larger than len, but is decremented inside the inner for loop.
Thanks, it seems the separate from variable decrease operator (q --) broke my "internal parser" as I completely missed it somehow. I'll edit my post to remove the noise.
Re: BearSSL – Smaller SSL/TLS
#167The 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.
This. I recently worked on updating an embedded TLS implementation from TLS 1.0 to TLS 1.2. I was told that it didn't need to implement TLS 1.0 or TLS 1.1, but once deployed we found a lot of non-HTTPS servers still using TLS 1.0. In particular, Microsoft's Hotmail/MSN SMTP servers and multiple RADIUS servers on WPA/WPA2 Enterprise networks. It now allows for client connections to TLS 1.0 servers, but will only serve TLS 1.2 itself.
Re: BearSSL – Smaller SSL/TLS
#168The 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.
Lots of things with microcontrollers.
Re: BearSSL – Smaller SSL/TLS
#169Earlier quoted context omitted.
> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]
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.
Re: BearSSL – Smaller SSL/TLS
#170Earlier quoted context omitted.
> Rust can't target the same platforms C can. I keep seeing this argument, but nobody actually names those platforms. Name one platform you need to run a TLS stack on that LLVM doesn't have support for. > Rust is also (generally) more memory intensive than C for similar programs [citation needed]
> Name one platform you need to run a TLS stack on that LLVM doesn't have support for. MPC55xx there's no proper support even in GCC and we need to work with expensive WindRiver compiler for this target. personally I don't need TLS for my firmware, but someone might - as there's static without runtime alloc implementation available.
> MPC55xx
Google suggests that this is essentially PowerPC. Is that not true?