7 ms·

I think I do understand what you're saying Dan, but do you really believe that cryptographic software isn't something you can gradually improve on? How do you

by zainny 13y ago

I think I do understand what you're saying Dan, but do you really believe that cryptographic software isn't something you can gradually improve on? How do you explain the fact that the majority/all of the crypto libraries we rely on today have been gradually improved over time, fixed as bugs have been found, etc? I think you've severely mischaracterised the way crypto software is developed. You fix the bugs and you move on. That's the only way to progress, and that's exactly what the developers have been doing. I can't fault them for that.

jmgao 13y ago
There is a difference between starting with a reasonably well written core and fixing issues that are discovered, and starting with a product that demonstrates essentially no understanding of cryptography beyond the bare minimum and trying to debug a working cryptosystem into existence. It's bad enough to try that with regular software, but doing it with crypto is insane.
tptacek 13y ago
He's not mischaracterizing the way crypto software is developed. You are.
- windexh8er 13y ago
  Please characterize the proper way for us of the uninformed...
  - tptacek 13y ago
    All software has bugs. There's no piece of real-world general-purpose software that you can't look at and say "this was improved incrementally as bugs were found". But not all software has the same sensitivity. In the weeks before Netscape Navigator shipped in the mid-90s, Jamie Zawinski slept under his desk at work trying to make it reliable. The builds from the night before launch crashed! Nobody thought they'd make it. That's a story anyone on a commercial dev team can probably tell you; it's the oldest story in product development. That kind of incremental development works fine when you're shipping the first web browser, or even the first version of a new web browser. It does not work when you are shipping cryptography. Nate Lawson is fond of saying, "plan to budget 10x for the validation of a new cryptosystem as you to implementation". You probably can't actually be doing that when your whole cryptosystem changes 4 times in 2 years. The difference is between handling bugs and expecting bugs. Netscape expected bugs. Crypto software can't do that.
    - saosebastiao 13y ago
      You haven't explained anything about how crypto software is developed. You have told us how other software is developed and then told us that it isn't okay for crypto software.
      - tptacek 13y ago
        Spend 10x the resources on verification as on implementation. Spend 10x the resources on design as on implementation. Nobody does this with normal software.
        jbri 13y ago
        And ultimately the biggest thing to do is that when you find a bug, don't just fix that one bug and call it a day. If you find a bug in your crypto code through your testing and validation, that means your development process screwed up and allowed that bug to slip through. What you need to do is figure out how that bug got through your development process, change your development process so it wouldn't slip through next time, and then have a thorough audit of your already-written code to make sure no other bugs have slipped through the same way. Developing must-not-fail critical software is the exact opposite of the traditional launch-fast-and-iterate model that most people use to produce web applications and such. This is a big reason that when web app developers try their hand at developing critical software like cryptography, they get it horribly wrong.
        nekopa 13y ago
        This seems similar to way the people who developed the software for the space shuttle worked. Finding a bug was a huge deal, as it meant something was wrong in their process. It wasn't just fix the bug, but fix what caused the bug, and look to see where that faulty process may have caused other bugs. Google 'they write the right stuff' for a good article on it.
        IsThisObvious 13y ago
        Another domain where you have things like this is embedded systems related to safety, ie, the micro-controller managing pressure equipment.
JoachimSchipper 13y ago
Note that, assuming the security model proposed by cryptocat, every time it's broken a few hundred peaceful protesters against a brutal regime end up against the wall. The brutal regime obviously doesn't bother to tell the world to stop using the software in question. (In reality, it's not that bad because quite a lot of people distrust cryptocat. Still, "patch and move on" doesn't cut it for critical software, which almost all crypto software is.)
cantos 13y ago
My knowledge of this topic is limited but I believe if you are saying that the majority of crypto libraries have had major bugs, in the sense that they are made trivial to break, that you are overreaching. On the other hand if you are including minor bugs, that have a low impact on security, then you are surely right but this doesn't mean much. Minor bugs get caught even in audits of the code for nuclear power plants.

by zainny 13y ago

jmgao 13y ago

There is a difference between starting with a reasonably well written core and fixing issues that are discovered, and starting with a product that demonstrates essentially no understanding of cryptography beyond the bare minimum and trying to debug a working cryptosystem into existence. It's bad enough to try that with regular software, but doing it with crypto is insane.

tptacek 13y ago

He's not mischaracterizing the way crypto software is developed. You are.

windexh8er 13y ago
Please characterize the proper way for us of the uninformed...
- tptacek 13y ago
  All software has bugs. There's no piece of real-world general-purpose software that you can't look at and say "this was improved incrementally as bugs were found". But not all software has the same sensitivity. In the weeks before Netscape Navigator shipped in the mid-90s, Jamie Zawinski slept under his desk at work trying to make it reliable. The builds from the night before launch crashed! Nobody thought they'd make it. That's a story anyone on a commercial dev team can probably tell you; it's the oldest story in product development. That kind of incremental development works fine when you're shipping the first web browser, or even the first version of a new web browser. It does not work when you are shipping cryptography. Nate Lawson is fond of saying, "plan to budget 10x for the validation of a new cryptosystem as you to implementation". You probably can't actually be doing that when your whole cryptosystem changes 4 times in 2 years. The difference is between handling bugs and expecting bugs. Netscape expected bugs. Crypto software can't do that.
  - saosebastiao 13y ago
    You haven't explained anything about how crypto software is developed. You have told us how other software is developed and then told us that it isn't okay for crypto software.
    - tptacek 13y ago
      Spend 10x the resources on verification as on implementation. Spend 10x the resources on design as on implementation. Nobody does this with normal software.
      - jbri 13y ago
        And ultimately the biggest thing to do is that when you find a bug, don't just fix that one bug and call it a day. If you find a bug in your crypto code through your testing and validation, that means your development process screwed up and allowed that bug to slip through. What you need to do is figure out how that bug got through your development process, change your development process so it wouldn't slip through next time, and then have a thorough audit of your already-written code to make sure no other bugs have slipped through the same way. Developing must-not-fail critical software is the exact opposite of the traditional launch-fast-and-iterate model that most people use to produce web applications and such. This is a big reason that when web app developers try their hand at developing critical software like cryptography, they get it horribly wrong.
        nekopa 13y ago
        This seems similar to way the people who developed the software for the space shuttle worked. Finding a bug was a huge deal, as it meant something was wrong in their process. It wasn't just fix the bug, but fix what caused the bug, and look to see where that faulty process may have caused other bugs. Google 'they write the right stuff' for a good article on it.
      - IsThisObvious 13y ago
        Another domain where you have things like this is embedded systems related to safety, ie, the micro-controller managing pressure equipment.

JoachimSchipper 13y ago

Note that, assuming the security model proposed by cryptocat, every time it's broken a few hundred peaceful protesters against a brutal regime end up against the wall. The brutal regime obviously doesn't bother to tell the world to stop using the software in question. (In reality, it's not that bad because quite a lot of people distrust cryptocat. Still, "patch and move on" doesn't cut it for critical software, which almost all crypto software is.)

cantos 13y ago

My knowledge of this topic is limited but I believe if you are saying that the majority of crypto libraries have had major bugs, in the sense that they are made trivial to break, that you are overreaching. On the other hand if you are including minor bugs, that have a low impact on security, then you are surely right but this doesn't mean much. Minor bugs get caught even in audits of the code for nuclear power plants.