3 ms·

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, > a commercial airplane, a bridge, or a rad

by rkangel 13y ago

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, > a commercial airplane, a bridge, or a radiation therapy machine. Couldn't agree more. The problem is that for any bridge that gets used, every structural engineer signing off is going to have been educated and experienced to the extent that they are Chartered (or equivalent), the plans for the bridge have to be approved by planning authorities and a thorough documentation and review process has been gone through, before the first drop of concrete has been poured. And once its up, it's tested, and inspected regularly. As every engineer on the project has necessarily been educated they know how hard it is and what the pitfalls are. Bad crypto results from the fact that there is no need for any of the above requirements to be met. Any old engineer might think they can produce a good implementation, design it, put it into production and have systems secured by it, without being aware of the potential problems they're causing. The free world of the internet is a wonderful thing, but regulation isn't entirely a bad thing either.

jacquesm 13y ago
How will regulation take care of bad crypto? Even experts get it wrong with some regularity (of course not as often as noobs, but still).
- jerf 13y ago
  The problem with regulation is that one must first establish who is capable of regulating correctly. There's no such thing as abstract regulation that simply exists. The entities that would most likely do the regulating already exist, but I'm unconvinced any of them would actually improve the situation. For instance, see http://blog.cr.yp.to/20140411-nist.html http://blog.cr.yp.to/20140411-nist.html . What real group of people could really regulate cryptography? What real group of people's regulations could actually bring benefits to the field, rather than rubber stamping, government meddling for the NSA, and an emphasis on quantity over quantity? If you can't answer that, I'd suggest staying away from a reflexive "regulation" standpoint.
  - rkangel 13y ago
    I failed to express myself well. I'm not suggesting that all crypto is immediately regulated, that is completely infeasible. I'm just point out that regulation in general, over all domains, isn't inherently bad. There is actually some regulation in this space. FIPS compliance, PCI DSS etc.. It's just not as wide reaching as something like the FAA for aeroplanes.
    - stcredzero 13y ago
      The FAA, NTSB, and aerospace industry do an effective job of solving problems and taking concrete steps to prevent disasters from happening again. The industry is economically motivated to do so, and those in power want to fly safe, so things get done. The programming field just keeps making the same old mistakes again and again. We're even economically motivated to keep things this way, because we get paid to fix things when they go wrong. Roads in Germany come with a warranty, so the contractors make sure to build them correctly. Roads in the US and Italy keep getting fixed, because that's how those companies get paid.
    - jerf 13y ago
      "I'm just point out that regulation in general, over all domains, isn't inherently bad." Very few people seriously argue that. (Non-zero, but very few.) I'm a libertarian and I wouldn't seriously argue that. It's mostly a strawman. (I advise anyone who makes routine use of that strawman to stop, and read more carefully whenever they feel tempted to use it again, but that's another post.) My point is that we aren't talking about "regulation in general", we're talking about "regulation in cryptography", and it's a logical and/or cognitive error to fall back to a general case when one is trying to consider a specific case. If we're going to regulate cryptography, how are we going to regulate it? "In the general case regulators" don't exist. The closest entities we have now that would almost certainly become the regulators show few to no signs of being worthy of the task. This is a serious problem to be addressed without falling back to "general cases".
logicallee 13y ago
> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine. I disagree with you completely and absolutely. Your bridge in Boston isn't going to collapse the moment a researcher sitting in his bathtub in Tel Aviv has a eureka moment. But if that eureka moment results in a preimage collision in a secure hashing algorithm, that hashing algorithm is broken for everyone all over the world forever. (Practically, as soon as the collision is public knowledge). Cryptographers have to actively seek out this information. That's why MD5 is deprecated, even though the weakness is weaker than the one I've just stated. (It's just a chosen prefix collision that can be done today - a preimage [chosen hash] attack still takes nearly the full search space.) Security is applied mathematics, the way engineering is applied physics. But the laws of physics don't change on an annual basis, or the way in which they change is too low-level to apply to engineering, whereas the laws of applied mathematics do. Systems administrators have to keep up to date on an even more active basis, in some cases needing to patch any system within 48 hours of a public disclosure. So I simply disagree that as an engineering endeavor implementation of cryptosystems is in any way similar to any other form of engineering. In fact, for the particular example I used in the above case (a hash), the very existence of the operation is an open problem. ("The existence of such one-way functions is still an open conjecture", Wikipedia.) What other branch of engineering relies on laws that may well be false?
- austinz 13y ago
  While it is true that fundamental weaknesses in cryptographic theory may be discovered at any time, the implementation of cryptosystems is, I would assert, still very much like engineering. Broken theory is distinct from broken implementation, although broken theory does end up breaking implementations as well. Maybe some mathematician will prove AES is broken tomorrow. In terms of the analogy, I don't care. The most qualified, fastidious engineer building the most correct implementation of AES is going to have an insecure system on their hands at the end of the day if that's true, and there is nothing we can do about that on the implementation side. This is distinct from some programmer reading "Learn Crypto in 24 Hours", building a bad implementation of an otherwise secure cryptosystem due to inexperience or carelessness, and then screwing people over because that bad cryptosystem goes into production code.

by rkangel 13y ago

jacquesm 13y ago

How will regulation take care of bad crypto? Even experts get it wrong with some regularity (of course not as often as noobs, but still).

jerf 13y ago
The problem with regulation is that one must first establish who is capable of regulating correctly. There's no such thing as abstract regulation that simply exists. The entities that would most likely do the regulating already exist, but I'm unconvinced any of them would actually improve the situation. For instance, see http://blog.cr.yp.to/20140411-nist.html http://blog.cr.yp.to/20140411-nist.html . What real group of people could really regulate cryptography? What real group of people's regulations could actually bring benefits to the field, rather than rubber stamping, government meddling for the NSA, and an emphasis on quantity over quantity? If you can't answer that, I'd suggest staying away from a reflexive "regulation" standpoint.
- rkangel 13y ago
  I failed to express myself well. I'm not suggesting that all crypto is immediately regulated, that is completely infeasible. I'm just point out that regulation in general, over all domains, isn't inherently bad. There is actually some regulation in this space. FIPS compliance, PCI DSS etc.. It's just not as wide reaching as something like the FAA for aeroplanes.
  - stcredzero 13y ago
    The FAA, NTSB, and aerospace industry do an effective job of solving problems and taking concrete steps to prevent disasters from happening again. The industry is economically motivated to do so, and those in power want to fly safe, so things get done. The programming field just keeps making the same old mistakes again and again. We're even economically motivated to keep things this way, because we get paid to fix things when they go wrong. Roads in Germany come with a warranty, so the contractors make sure to build them correctly. Roads in the US and Italy keep getting fixed, because that's how those companies get paid.
  - jerf 13y ago
    "I'm just point out that regulation in general, over all domains, isn't inherently bad." Very few people seriously argue that. (Non-zero, but very few.) I'm a libertarian and I wouldn't seriously argue that. It's mostly a strawman. (I advise anyone who makes routine use of that strawman to stop, and read more carefully whenever they feel tempted to use it again, but that's another post.) My point is that we aren't talking about "regulation in general", we're talking about "regulation in cryptography", and it's a logical and/or cognitive error to fall back to a general case when one is trying to consider a specific case. If we're going to regulate cryptography, how are we going to regulate it? "In the general case regulators" don't exist. The closest entities we have now that would almost certainly become the regulators show few to no signs of being worthy of the task. This is a serious problem to be addressed without falling back to "general cases".

logicallee 13y ago

> I see the implementation of cryptosystems as an engineering endeavor little different than designing, for example, a commercial airplane, a bridge, or a radiation therapy machine. I disagree with you completely and absolutely. Your bridge in Boston isn't going to collapse the moment a researcher sitting in his bathtub in Tel Aviv has a eureka moment. But if that eureka moment results in a preimage collision in a secure hashing algorithm, that hashing algorithm is broken for everyone all over the world forever. (Practically, as soon as the collision is public knowledge). Cryptographers have to actively seek out this information. That's why MD5 is deprecated, even though the weakness is weaker than the one I've just stated. (It's just a chosen prefix collision that can be done today - a preimage [chosen hash] attack still takes nearly the full search space.) Security is applied mathematics, the way engineering is applied physics. But the laws of physics don't change on an annual basis, or the way in which they change is too low-level to apply to engineering, whereas the laws of applied mathematics do. Systems administrators have to keep up to date on an even more active basis, in some cases needing to patch any system within 48 hours of a public disclosure. So I simply disagree that as an engineering endeavor implementation of cryptosystems is in any way similar to any other form of engineering. In fact, for the particular example I used in the above case (a hash), the very existence of the operation is an open problem. ("The existence of such one-way functions is still an open conjecture", Wikipedia.) What other branch of engineering relies on laws that may well be false?

austinz 13y ago
While it is true that fundamental weaknesses in cryptographic theory may be discovered at any time, the implementation of cryptosystems is, I would assert, still very much like engineering. Broken theory is distinct from broken implementation, although broken theory does end up breaking implementations as well. Maybe some mathematician will prove AES is broken tomorrow. In terms of the analogy, I don't care. The most qualified, fastidious engineer building the most correct implementation of AES is going to have an insecure system on their hands at the end of the day if that's true, and there is nothing we can do about that on the implementation side. This is distinct from some programmer reading "Learn Crypto in 24 Hours", building a bad implementation of an otherwise secure cryptosystem due to inexperience or carelessness, and then screwing people over because that bad cryptosystem goes into production code.