2 ms·

You did claim they could write secure software, at least that's what you wrote. If that's not what you meant, then I understand.

Nursie 12y ago
I think we must be miscommunicating here, I'm genuinely not seeing where I said that (it would not be the first time I have been hilariously unobservant though). The nearest I can see to that is where I said - "With fairly minimal training one can learn to use existing, secure constructions." - which I think I've qualified/explained now?
- tptacek 12y ago
  He's misunderstood you, and then run away with his misunderstanding, perhaps because he thinks it's a more interesting back-and-forth to bounce around than what you actually said. My reading of what you wrote is: it doesn't take much training to use Libsodium. To the extent that providing cryptographic security is important, you can solve the problem by delegating it to the Nacl designers and Sodium implementors. That's mostly true. I did not see you making an argument about how simple the entire security problem was to solve.
  - diminoten 12y ago
    Precisely this. "It's not hard to learn to use a crypto library" is not an interesting conversation, and so I actively tried to have a more interesting conversation about "it's actually pretty damn hard to implement crypto software". Since when is learning a single crypto library the end-all solution to writing good crypto software?
    - Nursie 12y ago
      >> I actively tried to have a more interesting conversation about "it's actually pretty damn hard to implement crypto software". You might have said that! >> Since when is learning a single crypto library the end-all solution to writing good crypto software? It's not, but it's a start, a start which all of these stories that hit HN and get torn to pieces are missing. -- edit -- When I made my comment that you can learn to use existing things with minimal training I should have padded it out by telling you the reason I was saying that - learning to use well-understood crypto primitives, and (if you can) pre-provided crypto implementations is far from all you need to make secure software. But it's a start. "Hey, come and look at our neat new crypto, it's awesome!" is a big red flag, and it's a red flag with a subtext that reads: We don't know what we're doing. Software that does use good constructions and good implementations can still be done very badly, it's true. To go back to your first comment, you say there's this gap between the way crypto people work and the way developers develop - that may well be so, but in most of the messaging apps we see here on HN the developer hasn't really even attempted to bridge that gap. Think about it like cooking a meal - you're asking what it takes to become a top chef but in the case we're discussing they didn't even start their marinara sauce with tomatoes.
pharrington 12y ago
There is infinitely more to writing secure software than correctly using secure cryptographic constructs.
- Nursie 12y ago
  This is what I should have said a few messages up the chain! Writing secure software is hard and covers a lot more than your choice of ciphers, protocols etc. It's possible to make all the right choices and still make insecure software for so many reasons. OpenSSL was referenced up-thread - simple buffer overruns/lack of bounds checking is one way in which that failed (heartbleed). In order to write secure software one needs first to define what we're aiming at, what does secure mean in the domain in which we operate? And that's non-trivial in itself. But by choosing well-known constructions and (hopefully) well tested implementations we can minimise some classes of potential problems.

Nursie 12y ago

I think we must be miscommunicating here, I'm genuinely not seeing where I said that (it would not be the first time I have been hilariously unobservant though). The nearest I can see to that is where I said - "With fairly minimal training one can learn to use existing, secure constructions." - which I think I've qualified/explained now?

tptacek 12y ago
He's misunderstood you, and then run away with his misunderstanding, perhaps because he thinks it's a more interesting back-and-forth to bounce around than what you actually said. My reading of what you wrote is: it doesn't take much training to use Libsodium. To the extent that providing cryptographic security is important, you can solve the problem by delegating it to the Nacl designers and Sodium implementors. That's mostly true. I did not see you making an argument about how simple the entire security problem was to solve.
- diminoten 12y ago
  Precisely this. "It's not hard to learn to use a crypto library" is not an interesting conversation, and so I actively tried to have a more interesting conversation about "it's actually pretty damn hard to implement crypto software". Since when is learning a single crypto library the end-all solution to writing good crypto software?
  - Nursie 12y ago
    >> I actively tried to have a more interesting conversation about "it's actually pretty damn hard to implement crypto software". You might have said that! >> Since when is learning a single crypto library the end-all solution to writing good crypto software? It's not, but it's a start, a start which all of these stories that hit HN and get torn to pieces are missing. -- edit -- When I made my comment that you can learn to use existing things with minimal training I should have padded it out by telling you the reason I was saying that - learning to use well-understood crypto primitives, and (if you can) pre-provided crypto implementations is far from all you need to make secure software. But it's a start. "Hey, come and look at our neat new crypto, it's awesome!" is a big red flag, and it's a red flag with a subtext that reads: We don't know what we're doing. Software that does use good constructions and good implementations can still be done very badly, it's true. To go back to your first comment, you say there's this gap between the way crypto people work and the way developers develop - that may well be so, but in most of the messaging apps we see here on HN the developer hasn't really even attempted to bridge that gap. Think about it like cooking a meal - you're asking what it takes to become a top chef but in the case we're discussing they didn't even start their marinara sauce with tomatoes.

pharrington 12y ago

There is infinitely more to writing secure software than correctly using secure cryptographic constructs.

Nursie 12y ago
This is what I should have said a few messages up the chain! Writing secure software is hard and covers a lot more than your choice of ciphers, protocols etc. It's possible to make all the right choices and still make insecure software for so many reasons. OpenSSL was referenced up-thread - simple buffer overruns/lack of bounds checking is one way in which that failed (heartbleed). In order to write secure software one needs first to define what we're aiming at, what does secure mean in the domain in which we operate? And that's non-trivial in itself. But by choosing well-known constructions and (hopefully) well tested implementations we can minimise some classes of potential problems.