Crypto-guru slams 'NSA-proof' tech, says today's crypto is strong enough History is filled with companies shamed by their shoddy cryptography implementations – even though the underlying maths is bang on. In a presentation titled "Crypto Won't Save You" at the AusCERT conference on Australia's Gold Coast, respected cryptographer Peter Gutmann of the University of Auckland took security bods through …
"We don’t need any new NSA-proof protocols. Any well-designed, appropriately-deployed protocol is NSA-proof."
Or so the NSA would have us believe. Even as far back as Caesar, there has been a conflict between the codemakers and the codebreakers. It's in the NSA's interest to have people believe there are NSA-proof protocols. Codemakers should keep trying to push the state-of-the-art in encryption. If they aren't, they're not doing their jobs.
I think the point of the article is that effort spent on developing new protocols would be wasted when they are implemented in ways that allow a (relatively) easy work-around.
Far better to improve implementation of current techniques so that they can be relied on.
The current situation has us creating hardened steel locks with millions of combinations and then using them on chipboard doors attached to plasterboard partition walls.
Of course, a hardened crypto environment that's relatively immune to attack through software compromise is also exactly what is required for secure Digital Rights Management. Once we've reinforced the doors and the walls, we have to be careful which side we fix the lock...
Naaah.
The fallacy with DRM is that the user needs to have the keys to decode the content to view it!
It's irrelevant how secure your crypto is - the goal of DRM is not to protect data in transit, but to deny user-controlled access to the data, which it ultimately can't do.
Encryption does not stop access to information, it can only delay access.
Properly installed crypto with strong keys can delay access much more effectively. Enigma in WW2 cracked the codes, but they had a devil of a time getting into U-Boat traffic because the Kriegsmarine stuck to proper protocols. "Oyster" traffic was never broken by Bletchley Park as a result.
The enigma was effectively unbreakable by the technology of the time.
It was broken because of poor security procedures. Choosing weak keys (the famous AfrikaKorp signaller who used "HIT" "LER" as the code group everyday for the entire war) retransmitting the same message with incremented code settings, or sending identical daily weather reports in enigma and weak civilian code.
The British navy had a less complex but reasonably secure book cypher. Unfortunately they also had an admiral in Halifax who sent the same message "nothing to report" with a long long florid greeting and sign off signature every morning using that days code.
From people in the community I've talked to I believe the self-encoding flaw wasn't that serious in itself. It was opsec failures that led to it's downfall, especially sending the same message in different codes and using long stock phrases and greetings.
Ironically the major break in the 4 rotor U boat system was due to attempts to tighten security. Rules requiring that all rotors be changed every day and no rotor be re-used within a certain time etc greatly reduced the keyspace - especially if you had broken a recent setting.
Worth bearing in mind when you create password rules the word must be a certain length, must have a capital, can't have two numbers next to each other etc etc....
The presentation is well worth reading and showing to others.
Interestingly enough, it only mentions OpenSSL in the context of Dual_EC_DRBG and does not mention Heartbleed, which IMHO is prime example of cryptographic product blown by poor implementation. I wonder why could this be ?
One point the Reg story doesn't make quite clear is that Peter isn't saying that we don't need strong crypto. He isn't saying that weak crypto is good enough. If we had good security practices and weak crypto, they'd attack the crypto. He's saying that we need strong crypto AND good security practices.
re HeartBleed: just too recent to have made it into the slides, I think, since it's such a perfect illustration of his point.
(I wasn't at AUScert but I have heard the talk previously. It's ROTFL material.)
@ Michael Hawkes - the difference between then and now is that we have the maths:
http://en.wikipedia.org/wiki/Integer_factorization.
@ NoneSuch - no idea where you get your information from. "Enigma" was the name of the machine, as given to it by the manufacturers. The main problem with U-boat traffic was the introduction of the fourth rotor. I've never heard it referred to as "Oyster". Wikipedia is over there -->.
Bletchley code names (rather than the German code names) for Enigma code versions: "Dolphin was the main naval cipher. Oyster was the officer’s variant of Dolphin." There was even one called "winkle" :-)
The guy is absolutely right. I don't know how many web sites I've worked on where they secure the passwords but utterly fail to secure the actual data that when stolen would cause the most harm.
Password schemes are all over the place but that's only one small piece of the puzzle. You have to look at the entire system.
"FIPS 140 doesn’t allow you to fix things. We did specifically ask if we had any discretion at all in the choice of points and were told that we were required to use the compromised points [...] if you want to be FIPS 140-2 compliant you MUST use the compromised points"
But wouldn’t the FIPS validation have caught the fact that the OpenSSL implementation didn’t work? Not only the original validation but many subsequent validations have successfully passed the algorithm tests ... several hundred times now. That’s a lot of fail [...] the FIPS 140-2 validation testing isn’t very useful for catching real-world problems
“Flaw in Dual EC DRBG (no, not that one)”, Steve Marquess
IPsec: It can’t have got that bad by accident
IPsec was a great disappointment to us [...] virtually nobody is satisfied with the process or the result [...] the documentation is very hard to understand [...] the ISAKMP specifications [the NSA’s main overt contribution to IPsec] contain numerous errors, essential explanations are missing, and the document contradicts itself in various places [...] none of the IPsec documentation provides any rationale for any of the choices that were made [...] the reviewer is left to guess [...]
“A Cryptographic Evaluation of IPsec”, Niels Ferguson and Bruce Schneier, from the first 5 pages of 28
This post has been deleted by its author
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
