[lvh]

Disclaimer: I'm not 'tptacek but I'm one of the Latacora principals and co-edited this document.

Embedded crypto gets weird fast. General recommendations are a little tricky, but: is that device talking to the internet directly or some kind of IoT hub or whatever?

[suf]

Let's say talking directly to the internet.

[lvh]

If it's on the raspi side of powerful, just use OpenSSL, or maybe Go's TLS stack, again, assuming you can get away with it.

On smaller systems, things get weird. If you can't afford go/openssl, there aren't a lot of things I'm very confident in. BearSSL near the top of the list. That's still double-digits kilobytes of RAM though, so maybe I just ate all your budget. You might be in one of the cases where a NOISE protocol instance is in fact the right answer; depends a little on what else the box is doing and how frequently.

Sorry, I get that it's not a satisfying answer :-) It's complicated!

[Cyph0n]

What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.

[lvh]

Their history of implementation issues leads me to believe that the general upside of TLS doesn’t necessarily weigh up to the upside (and cost!) of a light bespoke implementation. That’s contingent on having someone around who won’t mess this up; failing that, an embedded TLS stack is still a good idea.

I would have told you something differently before NOISE and NaCl, particularly Curve25519. We could have done AESCTRHMACSHA256 a long time ago and be basically a good as XSalsa20-Poly1305, but Curve25519 was a huge leap compared to the DH2048 you were likely to do before.

[asd2r23dasd]

I don't think you can deem mbedTLS too risky on one hand, and then on the other recommend Noise, with it's slew of unfinished and largely unverified libraries. Outside of the WireGuard RHUL effort for a specific 'pattern' AFAIK the Noise core hasn't really seen any formal analysis either. Commoditizing the DH operation means you can build an enormous amount of AKEs, and even people like Trevor Perrin can make mistakes there.

Noise is potentially very interesting, particularly for the embedded space, but it'll be a while before it's safe to use.

[zx2c4]

There's another paper besides the RHUL one, which preceded it, using tamarin: https://git.zx2c4.com/wireguard-tamarin/tree/wireguard.m4 https://www.wireguard.com/papers/wireguard-formal-verificati... There are other groups who are also currently working on similar and better proofs. I think the end goal is to get proofs of the general pattern language of Noise rather than just the WireGuard handshake (IKpsk2), which will probably then satisfy your concerns with Noise. The Noise project itself is also working on things like NoiseSocket which will be more of an easily pluggable "right answer".

[lvh]

You’re not wrong; it’s at least a close call.

You’re right that they’ve gotten less scrutiny, but they also need less scrutiny. (I’m not saying more isn’t better.) TLS carries a lot baggage from phlogiston era crypto and is significantly more complex than a dumb NOISE impl.

Note that I qualified my suggestion to “you need to have someone around for that” and that I also mentioned low cost. Specifically, I imagine you’d instantiate NOISE with some boring primitives, ideally in a memory safe language, and spend some time and money pointing Tamarin at it, for example. If you don’t have that, fine, get a tiny TLS stack. I’m just saying that a priori I can’t tell you I have less faith in random mbedTLS-containing ROM vs NOISE-with-reasonable-implementor. (I appreciate that we’re comparing apples to oranges with a concrete ROM vs an abstract protocol.) I also happily appreciate that we’re in territory where the constraints are too restrictive to make blanket recommendations.

Let me rephrase: would you agree that there are platforms that actually shipped with garbage crypto where it’s plausible that they could’ve made NOISE work but didn’t embed a TLS stack because size/perf?

[bsder]

SSL/TLS isn't very well suited for cheap embedded devices. It seems like you have to chew up almost 64K of RAM to make a compliant stack.

mbed TLS also doesn't seem to be particularly well vetted and has had a number of compromises due to implementation issues.

[suf]

Thanks, yeah embedded systems are always an exception that makes for strange design.

[lvh]

Yeah. Unfortunately this cuts both ways: I've also heard "you don't understand, we are on an embedded platform" when they mean "we're on a raspi".