5 ms·

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

by austinz 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. In all cases you have a system whose failure can result in anything from monetary loss to death (for an example of the latter, faulty cryptographic software used by dissidents in repressive countries). In all cases you use a combination of rigorous testing and analysis from first principles to try and isolate potential weaknesses. In all cases you want to ensure the people who worked on the system knew what they were doing and put the right amount of due diligence into ensuring the system works correctly. Unfortunately, not even widely used, highly trusted implementations work right all the time. A out-of-bounds memory bug introduced by an insufficiently vetted commit opened up a serious flaw in OpenSSL. On a much, much smaller scale, I once had the misfortune of working with an old version of Microchip's PIC18 AES library, which had some serious issues that made it nonfunctional for anything more complex than the toy sample app it shipped with. But with enough exposure these problems are eventually exposed and fixed. Would a world where everyone rolled their own bespoke, ad-hoc SSL implementations be more secure? I doubt it. In the end, I think there needs to be a cultural shift. People shouldn't be discouraged from building their own crypto for fun and learning, but they should be discouraged from deploying it for any application where real security is required - at least not before undergoing rigorous analysis. One of the first things Dan Boneh teaches in his Crypto I class is that you should think very long and hard before implementing your own cryptosystems (i.e. don't do it), because getting it right is hard, and getting it even the slightest bit wrong tends to make it useless. And when you consider that people's livelihoods (their personal information, their money) and even lives might be jeopardized, taking responsibility as an engineer becomes of paramount importance. Crypto just doesn't lend itself to a "build an MVP, get it working, move fast and break things" mindset.

lkozma 13y ago
The reason why crypto might be even harder than the other engineering tasks you mention is that in those the "adversary" is indifferent, not actively trying to exploit every loophole you might have left. You might build a bridge that has some small weakness, but no-one will come and stack weights in the exact pattern that exploits the weakness and makes the bridge collapse.
- dasil003 13y ago
  Beyond that, failure of a bridge or an airplane is not likely to go unnoticed. Every failure will be investigated, documented and studied. Crypto failure by contrast can just easily be silent, deadly, and continuously unnoticed for extended periods of time.
- jasonlotito 13y ago
  Engineering does have to deal with real adversarial threats. Just on example I've found: https://www.nae.edu/Publications/Bridge/Terrorism/AnEngineeringResponsetoTerrorismeditorial.aspx https://www.nae.edu/Publications/Bridge/Terrorism/AnEngineer... "The second relates to the design of structures. It is time for engineers and architects to get together to devise new structural forms that offer a higher degree of protection not only against terrorist attack, but also against other hazards. There is much to be learned from what happened in Nairobi and Dar es Salaam, in Oklahoma City, and at the World Trade Center. Similarly, retrofitting of existing structures needs to be studied systematically, as it can reduce, at modest or virtually no cost, the potential for damage."
- jessaustin 13y ago
  Yes gravity and metal are more predictable than a creative adversary: http://wondermark.com/406/ http://wondermark.com/406/
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
izacus 13y ago
Well, the lack of good documentation for libraries is also hugely problematic. For example, I'd call OpenSSL documentation "criminally bad" to the point where it actively tries to coax the user into making a mistake - there is no central point of good practices for common use cases (e.g. sending a AES256-CBC encrypted block of data securely with shared key, using pub/private key, etc.) and the docs regulary don't mention the proper way of initializing different datastructures and modules (like RNGs) when they're mentioned. Even finding out how to properly initialize everyting to do a standard PBKDF#2 password derivation is a huge chore that requires reading through tons of badly formatted documents (or copying a random piece of code from StackOverflow which may or may not be secure). That makes even highly secured libraries a minefield where you can easily introduce huge security flaws without even knowing that you did so. And as long as the excuse for that is "well, you just need few years of studying all crypto background" we'll be seeing security breaches everywhere - developers mostly just aren't prepared to spend so much time learning the crypto field or spend alot of money on security experts. In the big picture that's a huge issue - too many devs just opt to copy random pieces of code from StackOverflow, which can have very glaring security flaws or are simply not secure for the devs usecase.
a8000 13y ago
What I don't understand why most crypto libraries are then implemented in an inherently unsafe language. I feel something like the secure subset of Ada would have been much more apropriate.
- phpnode 13y ago
  Because to be usable it needs to be fast (and portable), and for a long time those constraints basically meant C - possibly not any more. But let's not kid ourselves, reimplementing a library the size of OpenSSL in a new language, or even the same one, is not a trivial matter. We're talking about a $10m+ investment, who's going to pay?

by austinz 13y ago

lkozma 13y ago

The reason why crypto might be even harder than the other engineering tasks you mention is that in those the "adversary" is indifferent, not actively trying to exploit every loophole you might have left. You might build a bridge that has some small weakness, but no-one will come and stack weights in the exact pattern that exploits the weakness and makes the bridge collapse.

dasil003 13y ago
Beyond that, failure of a bridge or an airplane is not likely to go unnoticed. Every failure will be investigated, documented and studied. Crypto failure by contrast can just easily be silent, deadly, and continuously unnoticed for extended periods of time.
jasonlotito 13y ago
Engineering does have to deal with real adversarial threats. Just on example I've found: https://www.nae.edu/Publications/Bridge/Terrorism/AnEngineeringResponsetoTerrorismeditorial.aspx https://www.nae.edu/Publications/Bridge/Terrorism/AnEngineer... "The second relates to the design of structures. It is time for engineers and architects to get together to devise new structural forms that offer a higher degree of protection not only against terrorist attack, but also against other hazards. There is much to be learned from what happened in Nairobi and Dar es Salaam, in Oklahoma City, and at the World Trade Center. Similarly, retrofitting of existing structures needs to be studied systematically, as it can reduce, at modest or virtually no cost, the potential for damage."
jessaustin 13y ago
Yes gravity and metal are more predictable than a creative adversary: http://wondermark.com/406/ http://wondermark.com/406/

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

izacus 13y ago

Well, the lack of good documentation for libraries is also hugely problematic. For example, I'd call OpenSSL documentation "criminally bad" to the point where it actively tries to coax the user into making a mistake - there is no central point of good practices for common use cases (e.g. sending a AES256-CBC encrypted block of data securely with shared key, using pub/private key, etc.) and the docs regulary don't mention the proper way of initializing different datastructures and modules (like RNGs) when they're mentioned. Even finding out how to properly initialize everyting to do a standard PBKDF#2 password derivation is a huge chore that requires reading through tons of badly formatted documents (or copying a random piece of code from StackOverflow which may or may not be secure). That makes even highly secured libraries a minefield where you can easily introduce huge security flaws without even knowing that you did so. And as long as the excuse for that is "well, you just need few years of studying all crypto background" we'll be seeing security breaches everywhere - developers mostly just aren't prepared to spend so much time learning the crypto field or spend alot of money on security experts. In the big picture that's a huge issue - too many devs just opt to copy random pieces of code from StackOverflow, which can have very glaring security flaws or are simply not secure for the devs usecase.

a8000 13y ago

What I don't understand why most crypto libraries are then implemented in an inherently unsafe language. I feel something like the secure subset of Ada would have been much more apropriate.

phpnode 13y ago
Because to be usable it needs to be fast (and portable), and for a long time those constraints basically meant C - possibly not any more. But let's not kid ourselves, reimplementing a library the size of OpenSSL in a new language, or even the same one, is not a trivial matter. We're talking about a $10m+ investment, who's going to pay?