4 ms·
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 eno
by 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 agoI'm trying to understand how you could possibly think I've been talking about "Bad!Idea" at all. I really can't find in anything I've written where I talked about writing a "bad" piece of crypto software. In fact, I've been talking about a potentially "good" piece of crypto software that isn't getting written because no software is perfect, but that's what crypto experts are demanding out of the gate. Can you more succinctly sum up what you're trying to say? Do you think software shouldn't be written in the crypto space unless it's perfect from v0.0.0? I can't imagine you think that, so I'm wondering what exactly it is you're arguing here.