That.
When will they ever learn…
But surely this problem can be easily solved by jailing those who pointed out the flaws in security.
My experience is they do learn. Next time, it will be an entirely different bunch of idiots. Still, I’ve seen how difficult it can be to persuade management to allow a complete review of a design by a gang of untrusted strangers whose sole qualification is that they claim they’re experts in the field.
The trouble with a starting point of zero knowledge is that you don’t know what you don’t know, and even when you do know what you don’t know, you don’t know which expert is an expert and which is going to take you for a ride. Same for credentials, etc.
There is a lot of ignorance when it comes to crypto, even among those who find themselves comparably smart.
There is a saying that if you think some crypto can not be decrypted, one is not very smart.
Depends. If it is well-implemented, side channels are guarded, and the key is secure, the crypto can be non-decryptable for all practical meanings. But then, such conditions are a rather tall order, specs-wise.
There are a very few circumstances when simple crypto is a good idea. One is where you are sending low security messages internally to an organisation but you just don’t want the IT department reading them. The US DMCA makes it an offense to decrypt your protocol, so if anyone copies it you can sue. It’s like the padlocks electricians put on circuit breakers when working on the circuit; a child could circumvent them with a bolt cutter, but that isn’t the point.
I did this once for a messaging system where the simply crypto was combined with a system for detecting malicious messages. The actual messages were wrapped in SSL. We supplied it to one company where the IT department promptly set up a MITM attack to read our messages in transit. They then had the gall to complain that having done this, they still couldn’t read the messages because they didn’t follow any of the protocols for which they had attacks.
The point is that if you are protecting really valuable assets (and the Smart Grid is one of these, no excuses, point finger and laugh at the idiots) this approach is no good. But in everyday circumstances where you are only collecting low security data, you are likely to come up against people who are basically IT script kiddies but wouldn’t know where to start on a key based translation cypher relying on a mangled code module for which the source code is literally locked in a physical safe.
It’s true that there are cases where it isn’t that bad, but even in those case there is no good reason not to build your solution from standard parts (but possibly at a lower level.)
When will these uptight crypto-snobs stop? I suppose next they’ll be telling me that the ingenious 8-bit XOR cipher I designed won’t cut it for encrypting private data. Sure- you Tesla-driving, kale-eating, I’m-too-good-to-eat-hot-pockets-and-play-CoD fancy boys can afford phones that can handle bigger keys without slowing down, but I’m building apps for Joe Sixpack here! 128 bits uses, like, 11 times more memory than 8 bits!
Especially when libcrypt/libcrypto/libssl has so easy interface, is free, and virtually no hassle.
One of the most singular characteristics of the art of deciphering is the strong conviction possessed by every person, even moderately acquainted with it, that he is able to construct a cipher which nobody else can decipher. I have also observed that the cleverer the person, the more intimate is his conviction.
– Charles Babbage, 1864
You’re forgetting something; if you have an internal solution, as I was describing, the IT department has access to the keys at both ends. Having performed a MITM attack on your outer SSL, they can now simply clone the keys, and emulate your receiver thus reading the messages. They can easily use a debugger to see what standard modules your code is calling.
Think about the situation like this: two people communicate using a one time pad. Highly secure, unless the bad guys happen to have a copy of the pad.
Sometimes security through obscurity is the only way if you don’t want people easily reverse engineering your protocol. A good example to my mind is HASP. How do you embed the keys so as to make them very hard to reverse engineer? That’s their trade secret.
Or do it the hardware way, and put your bet on tamper-resistance. When the attack requires microprobing silicon, you’re ahead of most adversaries.
Of course, in my ideal world a SEM/FIB station is in every garage, but…
Very few companies allow you to put custom silicon in their servers. As for VMs, there’s a problem with that.
Around the test lab we use special UICCs that merely XOR everything with \x000102030405060708090A0B0C0D0E0F. With a little practice you can read the ciphertext, like with ROT13.
Of course, the public network uses Rijndael and does not recognize test UICCs.
As with GSM’s original roll-your-own crypto, the question is whether to attribute it to malice or just incompetence. (In GSM’s case, I suspect both - having 10 of the 64 key bits always set to 0 looks like malice, but the algorithms themselves could have been either.)
There’s a lot to be said for the “1. Invent Bass-O-Matic crypto. 2. Get shown how trivial it is to break. 3. Use mathematically-sound crypto. 4. Have somebody break your data encapsulation formats. 5. Okay, fix those too.” process that PGP used.
That is an excellent quote that I have never read.
“I can write an s box algorithm, so my crypto must be secure!!”
Pfft, amateur. Real pros xor everything with \xDEADBEEF
It is a good quote; even better, it’s p’bly real : -) Found it in James Gleick’s The Information. Full cite: Charles Babbage, Passages from the Life of a Philosopher (London: Longman, Green, Longman, Roberts & Green, 1864), p.235
Ever get that tingly feeling when someone you know about is a bad ass, and they casually, off the cuff up their bad assness? Yeah, that is what I feel now.
