131–140 of 206 posts
Oh man, can't wait for the docs. TLS 1.2 on an ESP8266 would make it possible to use them with AWS IoT.
https://github.com/SuperHouse/esp-open-rtos/blob/master/exam...
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).
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]
Earlier quoted context omitted.
A lot of people are arguing that new projects like this should use Rust. Like https://github.com/ctz/rustls .
Only because they don't know Ada and they wanna reinvent the wheel again /s
Obviously, being able to call malloc without a GC is a nice to have for TLS on embedded systems.
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,…
No, they world needs as many of those as it can get (if they are tagged as such). And then all the authors need to discuss with each other what they learned from the implementation. And then they compare their code with existing code bases and discuss differences. They review their patches, as well as patches from other projects.
They discuss the diffs, learn from others and bring in new ways too look at things.
All bugs are shallow given enough eyes, and yet one of our biggest mantra's sole purpose is to limit the number of eyes. We need people that are familiar with crypto codebases and its subtleties, because we need the reviewers for our established projects. And for this reason, we need people to write and publish crypto related code. Not so we can push another new, excitingly half-baked TLS stacks into a product, but to foster the code review process we all rely on.
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?
Malloc is potentially troublesome for two reasons. First, its performance is potentially unpredictable. It depends on the current state of the heap at the time of the call, which you can't know in advance except in some very rare situations. It can also fail entirely, and that is likewise unpredictable.
memcpy and memmove, ultimately being byte-copying loops, don't suffer from these problems. Their performance is consistent and they always succeed if your pointers and lengths are valid.
On PCs these days, the troubles of malloc don't matter much. You have so much performance margin that occasional slow calls don't matter, and virtual memory with a big address space means that it almost never fails. If it does fail, it's OK if the program crashes and you have to restart it. But many systems are much more constrained.
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,…
"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.
Completely unrelated but:
Another small footprint ssl/tls library, very readable code and a pleasure to work with.