5 ms·

So if I understand correctly, this is a framework to design your own secure protocol for your applications? Kind of a higher-level building block instead of wo

by saganus 10y ago

So if I understand correctly, this is a framework to design your own secure protocol for your applications? Kind of a higher-level building block instead of working directly with NaCL and such? If I'm missing something, can someone explain it to me please?

lvh 10y ago
Yes. There are a few "layers" of crypto in most modern applications: - Low-level primitives, like AES, ChaCha20. - Usefully combined primitives, like AES-OCB, NaCl secretbox... - High-level protocols like TLS and Noise. - (sometimes) crypto spoken over the encrypted protocols, often for E2E crypto e.g. GPG over SMTPS, or CloudFlare blinded CAPTCHA tokens over HTTPS This matters because people sometimes think that they're not doing homebrew crypto because they are using e.g. AES. Noise builds on many of the things available in libsodium, including Curve25519 DH, ChaCha20, BLAKE2 et cetera.
- malingo 10y ago
  Is Noise the right answer to any of these crypto "questions"? https://news.ycombinator.com/item?id=9593916 https://news.ycombinator.com/item?id=9593916
  - tptacek 10y ago
    Not yet. It will be the best answer to the last of those questions, and it is a great case study for how the preceding questions are best answered. (Those questions, by the way, originally come from Colin Percival; I didn't choose them, and wouldn't say they're the best questions). What we're waiting for is good Noise-primitive implementations in enough languages. The Noise protocols themselves are probably the best secure channel protocols we're going to get for awhile.
  - lvh 10y ago
    Generally speaking: they're not the same kind of thing, and no. For two reasons: most of these recommendations are at a lower level; they talk about primitives, not about protocols. Secondly, most applications still want TLS, probably with limited ciphersuite support, although you could do a lot worse than Noise. TLS is much better understood, and better supported. Noise is great if you care about implementing protocols with new properties, like indistinguishability, or over novel transports, or denaibility, or...
- saganus 10y ago
  Aha. Awesome! thanks for the answers everyone. This looks very interesting. However... I guess the "don't roll your own cryptography" still applies for this? I mean, I know better than trying to "design" my own algorithms. I even know that I shouldn't try to implement anything below what NaCL provides. But how about this? Could I use this to deploy my own secure protocol for my own projects? Obviously I have no formal cryptography training so I'm leaning towards "no, you are not qualified to implement anything", but just out of curiosity, is there some point at which we can build something securely without the need to either outsource this to a security team or getting actual training on security stuff? Or, put in another way, what amount of security training/knowledge should I have to properly use this while avoiding doing something universally stupid? is it still "you need to be actually trained for this" or is it enough to have some idea and being able to follow some best practices?
  - lvh 10y ago
    Well, this is where it gets tricky. Higher-and-higher level tools like libsodium and now Noise keep propelling us forward, making it easier and easier to design applications that use cryptography. I think one of the biggest challenges we have remaining is two-fold: appropriately communicate the tradeoffs between different options (e.g. repudiation vs non-repudiation, post-quantum secure KEX vs regular KEX, fast symmetric nonce-using crypto vs nonce-misuse resistant crypto, et cetera), and making alien technology (SNARKs, MPC...) more approachable. For most applications, you probably still want TLS instead of Noise. But if you want Noise, you really, really, really want Noise. If for some reason it is necessary to set up a tunnel with a pre-shared key, for example, I'd probably suggest you use one of Noise's PSK modes over TLS. So, it still depends what you're doing. But noise implementations and "toolkits" bring us closer to a future where applications for which TLS isn't appropriate have a decent chance at a secure protocol too.
gjkood 10y ago
Don't know whether you had a chance to read the Noise Protocol Specification available on the site yet. If not please read chapter 14 (Rationale). The information is very valuable even if you don't use Noise specifically. I found that and Chapter 13 (Security Considerations) very useful in general.

by saganus 10y ago

lvh 10y ago

Yes. There are a few "layers" of crypto in most modern applications: - Low-level primitives, like AES, ChaCha20. - Usefully combined primitives, like AES-OCB, NaCl secretbox... - High-level protocols like TLS and Noise. - (sometimes) crypto spoken over the encrypted protocols, often for E2E crypto e.g. GPG over SMTPS, or CloudFlare blinded CAPTCHA tokens over HTTPS This matters because people sometimes think that they're not doing homebrew crypto because they are using e.g. AES. Noise builds on many of the things available in libsodium, including Curve25519 DH, ChaCha20, BLAKE2 et cetera.

malingo 10y ago
Is Noise the right answer to any of these crypto "questions"? https://news.ycombinator.com/item?id=9593916 https://news.ycombinator.com/item?id=9593916
- tptacek 10y ago
  Not yet. It will be the best answer to the last of those questions, and it is a great case study for how the preceding questions are best answered. (Those questions, by the way, originally come from Colin Percival; I didn't choose them, and wouldn't say they're the best questions). What we're waiting for is good Noise-primitive implementations in enough languages. The Noise protocols themselves are probably the best secure channel protocols we're going to get for awhile.
- lvh 10y ago
  Generally speaking: they're not the same kind of thing, and no. For two reasons: most of these recommendations are at a lower level; they talk about primitives, not about protocols. Secondly, most applications still want TLS, probably with limited ciphersuite support, although you could do a lot worse than Noise. TLS is much better understood, and better supported. Noise is great if you care about implementing protocols with new properties, like indistinguishability, or over novel transports, or denaibility, or...
saganus 10y ago
Aha. Awesome! thanks for the answers everyone. This looks very interesting. However... I guess the "don't roll your own cryptography" still applies for this? I mean, I know better than trying to "design" my own algorithms. I even know that I shouldn't try to implement anything below what NaCL provides. But how about this? Could I use this to deploy my own secure protocol for my own projects? Obviously I have no formal cryptography training so I'm leaning towards "no, you are not qualified to implement anything", but just out of curiosity, is there some point at which we can build something securely without the need to either outsource this to a security team or getting actual training on security stuff? Or, put in another way, what amount of security training/knowledge should I have to properly use this while avoiding doing something universally stupid? is it still "you need to be actually trained for this" or is it enough to have some idea and being able to follow some best practices?
- lvh 10y ago
  Well, this is where it gets tricky. Higher-and-higher level tools like libsodium and now Noise keep propelling us forward, making it easier and easier to design applications that use cryptography. I think one of the biggest challenges we have remaining is two-fold: appropriately communicate the tradeoffs between different options (e.g. repudiation vs non-repudiation, post-quantum secure KEX vs regular KEX, fast symmetric nonce-using crypto vs nonce-misuse resistant crypto, et cetera), and making alien technology (SNARKs, MPC...) more approachable. For most applications, you probably still want TLS instead of Noise. But if you want Noise, you really, really, really want Noise. If for some reason it is necessary to set up a tunnel with a pre-shared key, for example, I'd probably suggest you use one of Noise's PSK modes over TLS. So, it still depends what you're doing. But noise implementations and "toolkits" bring us closer to a future where applications for which TLS isn't appropriate have a decent chance at a secure protocol too.

gjkood 10y ago

Don't know whether you had a chance to read the Noise Protocol Specification available on the site yet. If not please read chapter 14 (Rationale). The information is very valuable even if you don't use Noise specifically. I found that and Chapter 13 (Security Considerations) very useful in general.