3 ms·

Let's say talking directly to the internet.

by suf 9y ago

lvh 9y ago
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!
- suf 9y ago
  Thanks, yeah embedded systems are always an exception that makes for strange design.
  - lvh 9y ago
    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".
- Cyph0n 9y ago
  What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.
  - bsder 9y ago
    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.
  - lvh 9y ago
    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 9y ago
      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.
      - lvh 9y ago
        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?

Let's say talking directly to the internet.

by suf 9y ago

Let's say talking directly to the internet.

lvh 9y ago

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!

suf 9y ago
Thanks, yeah embedded systems are always an exception that makes for strange design.
- lvh 9y ago
  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".
Cyph0n 9y ago
What's wrong with PolarSSL/Mbed TLS? It is designed for low-end ARM processors and is directly backed by ARM.
- bsder 9y ago
  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.
- lvh 9y ago
  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 9y ago
    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.
    - lvh 9y ago
      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?