4 ms·

I guess am sorry that we ended up in bitter ends of a pointy discussion. For what's worth, I was not trolling. I stand by anything that I said (specially the "s

I guess am sorry that we ended up in bitter ends of a pointy discussion. For what's worth, I was not trolling. I stand by anything that I said (specially the "sprinkle of crypto fairy dust", which I have seen IRL more often that I wish). If I am ignorant or not, I am by definition unqualified to tell. Other than that, if you prefer to have non combative discussions, please stop bossing professionals around and tell them what to do. Specially if they are not providing a service you paid money for.

diminoten 12y ago
I am a professional and I "boss" other professionals around on this topic (admittedly, mostly other topics, but this specific one does come up) for a living. But it's funny, because what you're saying here (don't "boss" people around) is similar to what I am saying, with regard to experimental crypto software. The crypto experts need to let the developers develop, and find a constructive way to contribute to that process, rather than chicken-little every time a bug appears. Imagine software that comes out, stating: "This software is not meant to do anything other than hide your porn from your mother. Please do not use this software to do anything other than protect yourself against a threat who has limited understanding of computers and software." As that software matures, the disclaimer could expand to, "This software is not meant to do anything other than protect information against low-level criminal activity. Please do not use this software to do anything other than to protect your information from larceny or identity theft. This software will not protect you against a sophisticated or well-resourced actor." Eventually expanding to, "This software has been tested by a community of crypto experts. While there is currently no known reason why this software won't protect your information from all bad actors, there is no guarantee in place that your information is absolutely safe. Always exercise extreme caution when protecting your data from sophisticated actors." The idea being that, once an experimental piece of software becomes "good enough", it can be used to protect against a more diverse threat model. The idea that you have to ship an NSA-proof product on day 1 is completely unfeasible and will never happen, and the crypto scientists out there need to realize that.
- deleted 12y ago
  [deleted]
- crpatino 12y ago
  You keep talking about bugs and therefore you keep missing the point. As a matter of fact, I tend to agree with you that the Infosec community would benefit enormously by adopting some of the best practices that we lowly programmers take for granted. There would arguably be less bug and less high-profile bugs that way. What I am trying to point out is that you cannot fix a flawed Security Design by incremental improvements. I am not talking about individual coding defects or even desirable features that have been left temporarily unimplemented on purpose. I am talking about Stupid!Ideas that get implemented because there was nobody around that recognized them as such, and then the usual traits of human nature (denial, previous investment bias, rationalization, etc) prevents the incumbents from scrapping those ideas until insurmountable evidence is assembled. The article in question talks about using One Time Pads (OTPs) to conceal secrets. This is an idea that sounds good, OTP is mathematically proven to be "unbreakable" and all that... The problem is when theory meets practice and nobody asks the hard question: How are sender and receiver going to share the OTP prior to sending the real message. This is not a trivial question to ask, giving the fact that OTP must have the same amount of bits as the message it is protecting. You can also not "recycle" a single OTP for many messages (that would be a Many Time Pad, which by definition violates the very preconditions that make OTP secure). So, you end up with the scheme used in spy movies (I have no idea how real spies worked during the Cold War). Each spy carries around a code-book of OTPs that he received in hand by a trusted contact. The fact of being in possession of such book is itself a proof of being a spy so he was to take great care to hide it, which is hard because it is a whole book (OTP, lots a lots of messages). Also, the spy agency will have the cumbersome work of providing a different code-book to each spy (because otherwise, when the enemy catches one spy, they could theoretically run the OTP on all previous communications from suspected spies and have each one of them rounded and shot before the word comes out that the first spy was in prison). This example also serves to illustrate another point. Maybe a Bad!Idea can be made to work in a limited way, if need is dire and resources are plenty. But any organization which kept secrets of real importance and tried to rely on this kind of solution would end up eaten alive by any adversary that had heard the words "asymmetric cryptography" spoken together.

diminoten 12y ago

I am a professional and I "boss" other professionals around on this topic (admittedly, mostly other topics, but this specific one does come up) for a living. But it's funny, because what you're saying here (don't "boss" people around) is similar to what I am saying, with regard to experimental crypto software. The crypto experts need to let the developers develop, and find a constructive way to contribute to that process, rather than chicken-little every time a bug appears. Imagine software that comes out, stating: "This software is not meant to do anything other than hide your porn from your mother. Please do not use this software to do anything other than protect yourself against a threat who has limited understanding of computers and software." As that software matures, the disclaimer could expand to, "This software is not meant to do anything other than protect information against low-level criminal activity. Please do not use this software to do anything other than to protect your information from larceny or identity theft. This software will not protect you against a sophisticated or well-resourced actor." Eventually expanding to, "This software has been tested by a community of crypto experts. While there is currently no known reason why this software won't protect your information from all bad actors, there is no guarantee in place that your information is absolutely safe. Always exercise extreme caution when protecting your data from sophisticated actors." The idea being that, once an experimental piece of software becomes "good enough", it can be used to protect against a more diverse threat model. The idea that you have to ship an NSA-proof product on day 1 is completely unfeasible and will never happen, and the crypto scientists out there need to realize that.

deleted 12y ago
[deleted]
crpatino 12y ago
You keep talking about bugs and therefore you keep missing the point. As a matter of fact, I tend to agree with you that the Infosec community would benefit enormously by adopting some of the best practices that we lowly programmers take for granted. There would arguably be less bug and less high-profile bugs that way. What I am trying to point out is that you cannot fix a flawed Security Design by incremental improvements. I am not talking about individual coding defects or even desirable features that have been left temporarily unimplemented on purpose. I am talking about Stupid!Ideas that get implemented because there was nobody around that recognized them as such, and then the usual traits of human nature (denial, previous investment bias, rationalization, etc) prevents the incumbents from scrapping those ideas until insurmountable evidence is assembled. The article in question talks about using One Time Pads (OTPs) to conceal secrets. This is an idea that sounds good, OTP is mathematically proven to be "unbreakable" and all that... The problem is when theory meets practice and nobody asks the hard question: How are sender and receiver going to share the OTP prior to sending the real message. This is not a trivial question to ask, giving the fact that OTP must have the same amount of bits as the message it is protecting. You can also not "recycle" a single OTP for many messages (that would be a Many Time Pad, which by definition violates the very preconditions that make OTP secure). So, you end up with the scheme used in spy movies (I have no idea how real spies worked during the Cold War). Each spy carries around a code-book of OTPs that he received in hand by a trusted contact. The fact of being in possession of such book is itself a proof of being a spy so he was to take great care to hide it, which is hard because it is a whole book (OTP, lots a lots of messages). Also, the spy agency will have the cumbersome work of providing a different code-book to each spy (because otherwise, when the enemy catches one spy, they could theoretically run the OTP on all previous communications from suspected spies and have each one of them rounded and shot before the word comes out that the first spy was in prison). This example also serves to illustrate another point. Maybe a Bad!Idea can be made to work in a limited way, if need is dire and resources are plenty. But any organization which kept secrets of real importance and tried to rely on this kind of solution would end up eaten alive by any adversary that had heard the words "asymmetric cryptography" spoken together.