Comment by mythz | Hacker News Reader

Comment by mythz | Hacker News Reader

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, BearSSL will automatically use a couple more system calls to access the OS-provided clock and random number generator.)

> On big desktop and server OS, this feature still offers an interesting characteristic: immunity to memory leaks and memory-based DoS attacks. Outsiders cannot make BearSSL allocate megabytes of RAM since BearSSL does not actually know how to allocate RAM at all.

Edit: Just discovered what makes this an even more interesting one to watch, it's the work of this Wizard: http://security.stackexchange.com/users/655/thomas-pornin

> The last thing the world needs is another immature SSL/TLS implementation...

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"

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.

Implying you have the resources to do so correctly. Which was the issue with OpenSSL.

Completely unrelated but:

https://tls.mbed.org/

Another small footprint ssl/tls library, very readable code and a pleasure to work with.

I'm not sure that was the issue with OpenSSL. According to the libressl folks the OpenSSL team were spending massive amounts of time on FIPS support at the expense of known serious issues the OpenBSD team had raised.

And it seems the firewall here has made a clbuttic mistake, as that page is blocked due to the url containing "porn".

So you're pretty much out of luck if you want to visit a page that contains some analysis?

Well, presumably, if the author's last name is Pornin 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

Or your name is "Olivia Gray". (True story, corporate mail filter blocked all that person's email)

Why? 50 Shades? Something else?

Remove the space from her name and then look for a word in the middle that is commonly associated with spam emails.

"contains some analysis"

security.se works over HTTPS, might bypass your firewall: https://security.stackexchange.com/users/655/thomas-pornin

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.

probably could be useful in some small "internet of things" device

This. Internet of Things especially can benefit from adding TLS.

However you would often want DTLS there, which is for example what CoAP (HTTP-like IoT protocol which is based on UDP) uses.

i would imagine as some sort of secure-boot or trusted hardware process.

Reasons for SSL:

• Security

• The server you speak with requires SSL

Reasons for no general purpose OS:

• Limited power (battery, solar)

• Extreme cost pressures (linux needs about $5 of hardware)

• Security (smaller code to audit)

• Extreme reliability requirements

So anything that ticks a bullet in each category is a candidate.

• Remote sensors

• Radio gateway, say LoRa to an internet server

• A device which keeps a secret for you and provides it to a server on command, perhaps something in a 2FA vein.

• Remotely triggerable actuators (door locks, parking lot lights)

I very badly need a TLS library in my embedded firmware so I can accept new firmware updates over HTTP.

You don't need TLS for that, you could simply use an HMAC and a shared secret, assuming you're not worried about people with physical access (and ability to get the secret) being able to create updates. Of course if you've got multiple instances of the device (not some hobby thing where they are all owned by you), then the secret for each device should be different so someone can't buy the device, determine the secret and then push updates to other people's devices.

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?

Yup you are right.

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

Not a very good idea, for the very reasons you point out. Signed releases with public keys, as conradev points out below is the far better approach.

Besides of what was already mentioned:

Many automotive or industrial communication buses are currently unencrypted, but could surely benefit from encryption.

Lots of things with microcontrollers.

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

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.

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

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

Stack usage is also much, much, much easier to characterize. In systems where stack depth is well-controlled (i.e. most embedded systems that don't have dynamic process/thread creation), very simple analysis will suffice to identify places where you blow your stack.

Not using the heap != everything is allocated on the stack. In situations where you want to avoid dynamic allocation, memory for most things that would otherwise have been dynamically allocated ends up being statically allocated at compile time.

Absolutely none of this is immune to buffer overflows.

No, but you're a lot more likely to be able to overwrite the return address via a stack-based buffer overflow, and that is generally a much more serious kind of attack.

Exploiting systems without dynamic memory is pretty meh.. that's some NSA level Stuxnet bespoke shit.

But no, judging from the code, you just give it one big fat I/O buffer that will usually come from .bss

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

Many real time systems and applications disallow heap usage, because they have formal verification requirements that can't be met with dynamic memory that may "run out" depending on run time state.

Exactly this.

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.

That question doesn't make any sense. They don't do the same thing, so you can't compare their relative performance. What's faster: an Intel i7 or a BMW i8?

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.

Reply on news.ycombinator.com