"you cannot expect a person working in academia to be held to the same standards as professionals working in the industry for many years"
This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.
If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
Isn't the problem that cryptography, solid protocol design and secure software development are actually almost unrelated disciplines that just happen to overlap in some applications?
I don't see why an OpenSSL developer would need either of the first two skillsets at all. Ideally, yes, but not necessarily.
I disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes anything except the "ideal" case dangerous.
I'm not sure that you're actually disputing my statement at all.
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
I may have been unclear: I am claiming that you cannot be a good protocol designer without sufficient expertise in cryptography AND you cannot be a good implementer without sufficient expertise in protocol design (I have updated my OP to add an instance of an implementation bug caused by insufficient knowledge about protocol design as well: TLS timing attack).
You could make the argument that if the implementer has to know anything about why the protocol or crypto works then the spec is poorly specified.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
In any other field, I would agree with that assessment. In the world of crypto, with side-channel attacks on the sound of your keyboard as you type, I think that having domain knowledge is essential for any implementer.
You could make that argument, but I will join with mehrdada in disagreeing with it.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.
Comments
"you cannot expect a person working in academia to be held to the same standards as professionals working in the industry for many years"
This is absolutely BS, especially in security and cryptography. Most security related code written by most so-called "professional" software developers is astonishingly terrible (e.g. ECB mode encryption, storing encryption key in code, reusing encryption keys, relying on (unauthenticated) encryption for authenticity, reusing IVs, linear time MAC verification, ...). Most cryptographers are academics. Also, anecdotally, the poisonous "demo an exploit or it doesn't happen" attitude in response to hints at a flawed system design is much more prevalent among "professional software developers" than in academia.
If anything, we should encourage more security experts in academia to engage in implementation, verification, and improvement of security code, not the other way around.
(Not that most academics write good code either, but this is not an academia/industry issue. It is a security expert/non-expert issue.)
Security experts write bad code. Non-security experts write bad code. Code, by default, should be assumed to be bad -- you're right far more often than you are wrong. That's why stringent review and re-review of code (both at the micro and macro level) are required to actually end up with a decently secure product.
I'm a huge fan of setting up adversarial teams for this. If you have two product teams in a company, have each team breaking the other's product; the closer you are to something, the less likely you are to see the bugs, so this model works phenomenally.
In my experience, security training (even up to the level of expert) helps people write better code only in terms of the most low-hanging fruit (SQLi, CSRF, basic XSS). But due to how close the author is to the code, it's nigh impossible for them to see the really bad bugs. But if you train your developers to break things and then point them at other teams' products, you're going to end up with a far more secure company.
Isn't the problem that cryptography, solid protocol design and secure software development are actually almost unrelated disciplines that just happen to overlap in some applications?
I don't see why an OpenSSL developer would need either of the first two skillsets at all. Ideally, yes, but not necessarily.
I disagree with the premise of your question. I think the overlap is larger than it looks like on the surface. I have come to believe that you cannot do solid secure protocol design without a firm grasp of the basics of encryption schemes. You don't need to be a full fledged cryptographer, but to quote Phil Rogaway, "Reading [Schneier] does not qualify one to do cryptographic design." [1]. In fact, the context in which he wrote "Problems with Proposed IP Cryptography"[1] is a perfect evidence of this: IETF committee designing IPsec, back in 1995, which I think is fair to think of as mostly "professional software developers", was clearly warned about potential consequences of some of their design choices[2] (like using Encrypt-then-MAC), but they reacted quite harshly to his comments and did not take them as seriously as they should have, and actual attacks were demonstrated on those issues years later[3]. For me, reading the mailing list is enough evidence that it is very dangerous to draw the line between secure protocol design and other things. Similarly, I believe the lack of understanding of the reasons behind design choices in a protocol specification will surface as implementation bugs done by purely "secure software development" experts (e.g. "optimization" of random data generation at the beginning of the protocol to use in place of an invalid input by reordering the operations leading to a timing attack in TLS). There is enough historical evidence that makes anything except the "ideal" case dangerous.
[1]: http://www.cs.ucdavis.edu/~rogaway/papers/draft-rogaway-ipse...
[2]: http://www.sandelman.ottawa.on.ca/ipsec/1995/04/msg00148.htm...
[3]: http://www.isg.rhul.ac.uk/~kp/CCSIPsecfinal.pdf
I'm not sure that you're actually disputing my statement at all.
Your main case there is software developers failing to do protocol design, which is exactly what I'm saying is a bad idea if they don't happen to be independently expert in it.
The reality is these situations would be a whole lot easier to resolve if people actually respected the expertise of each other. This works in all directions, but recent bugs show a definite weakness in terms of respect given towards relatively basic software engineering practices.
I may have been unclear: I am claiming that you cannot be a good protocol designer without sufficient expertise in cryptography AND you cannot be a good implementer without sufficient expertise in protocol design (I have updated my OP to add an instance of an implementation bug caused by insufficient knowledge about protocol design as well: TLS timing attack).
You could make the argument that if the implementer has to know anything about why the protocol or crypto works then the spec is poorly specified.
Certainly it helps to have a minimum of appreciation of the other parts of the domain, but I think you greatly overestimate how important that is for the kinds of problem we've been seeing lately.
In any other field, I would agree with that assessment. In the world of crypto, with side-channel attacks on the sound of your keyboard as you type, I think that having domain knowledge is essential for any implementer.
You could make that argument, but I will join with mehrdada in disagreeing with it.
It's possible that more vulnerabilities are caused by programming errors than by protocol misimplementation, but the latter do happen and are just as bad.