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

[asd2r23dasd]

Ah cheers for the link. Yeah a proof at the level of abstraction up from a single pattern would be lovely. I don't really have 'concerns' as such: it's just if your risk profile is the thing that has kicked you away from TLS towards Noise then you need a good justification (notwithstanding, a proof of security for a new AKE should really be par for the course).

IMO the interesting aspect with the development of Noise will be if it can avoid bloat. From the mailing list I can see that there's solid awareness of that risk (would assume Trevor is aware anyway), but it will be interesting to see how the simplicity of pattern API will handle things like signatures, when they're inevitably added. I see at least one Noise-using project has already made the leap on that front.

[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?

[asd2r23dasd]

I would definitely agree, yeah. Notwithstanding the legacy protocol core, Noise has great potential to allow people to step away from the asn1, X509 etc TLS cruft.

Comparing between those two options is a question of appetite for risk, your threat model, and the level of competency you have available. On the latter note, _at the moment_, I think the subset of people who are capable of taking advantage of Noise would be largely similar to the same subset you could safely task with designing and implementing a custom AKE+messaging protocol from scratch anyway. I think the level of competency you need available is on the very far end of the spectrum. Edit: and on the risk point, even if the library has been eyeballed less, at least you know with mbedTLS that if a bug drops you'll get a patch pretty quickly. If you goof up your Noise impl you're on your tod.

[lvh]

Appetite for risk, threat model, competency available _and_ platform constraints, IMO. I think we're in violent agreement: you should only do this if you have someone on board who knows what the hell they're doing, and you literally can't afford a decent TLS stack on that device.

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