| |||||||||||||
Security quotes of the weekSecurity quotes of the weekPosted Oct 25, 2012 12:50 UTC (Thu) by tpo (subscriber, #25713)Parent article: Security quotes of the week
I am surprised, that the paper cited here - "The most dangerous code in the world: validating SSL certificates in non-browser software" [0] - gets a mere "Security quotes of the week" mention.
I think its findings are devastating.
Also I found Adam Langley's recent article "NIST may not have you in mind" [1], especially the papers from 2005(!) [2][3] mentioned there, earth shattering. Until I read that article I was under the impression that AES is secure and did not know that there are practical attacks against AES(' implementations).
Not being a crypto expert myself, this leaves me with the feeling, that the crypto currently in use in mainstream software is mainly security theater: we - or maybe rather the experts among us - know it doesn't work but are still relying on the attacker not being very clever.
[0] http://www.cs.utexas.edu/~shmat/shmat_ccs12.pdf
(Log in to post comments)
Security quotes of the week Posted Oct 25, 2012 13:53 UTC (Thu) by jake (editor, #205) [Link]
> gets a mere "Security quotes of the week" mention
we just spotted it after the edition was already "put to bed" for the week, so that seemed like a quick and easy way to get something in for the weekly. more coverage does seem required as you note. stay tuned ...
jake
Security quotes of the week Posted Oct 25, 2012 15:36 UTC (Thu) by wahern (subscriber, #37304) [Link]
Timing attacks are well known and popular crypto libraries like OpenSSL take them into account. Newer algorithms and implementations are designed with timing attacks in mind. (They were known before DJB's paper, but it wasn't until around that time that public proof of concepts were published.)
The fact that cryptographic protocols can be commonly circumvented by bugs and laziness in the employing applications is also not new. But it usually takes proofs of concepts to catch people's attention.
I wouldn't call common protocols security theater. Security theater usually refers to tactics and procedures which are fundamentally insecure, or at least not based in any rigorous methodological science. The characteristics of cryptographic algorithms and protocols, OTOH, are quantifiable, and you can reason about them, including making assessments about the difficulty of their use.
Security quotes of the week Posted Oct 25, 2012 15:43 UTC (Thu) by wahern (subscriber, #37304) [Link]
Also, FWIW, newer Intel and AMD chips have instructions for implementing GCM in hardware.
Security quotes of the week Posted Oct 25, 2012 18:04 UTC (Thu) by tpo (subscriber, #25713) [Link]
> FWIW, newer Intel and AMD chips have instructions for implementing GCM in hardware.
As far as I understand Langley's article GCM is only one part of the problem. Is the other part of the problem also resolved by those machine instructions?
In case it would be, would that mean that as long as your SW runs on "newer" machines and actually uses those instructions for AES, you're safe and protected against known sidechannel attacks in software?
Also, as far as I understood OpenSSL is *still* doing table lookups but have reduced the table sizes so as not to cause that much cache churn. Would that have made the attack harder or impossible? Harder by several orders of magnitude or by several factors?
And what about the current typical SW stack? If I do a "cat /proc/memory | grep AES", how many of the typical processes running there actually use safe AES implementations? Does the kernel?
Security quotes of the week Posted Oct 25, 2012 20:48 UTC (Thu) by wahern (subscriber, #37304) [Link]
All of those concerns--if borne out--fall short of security theater. OpenSSL probably still has buffer overflows, like most other complex crypto stacks, lurking somewhere. Granted, that's different than the timing attacks, which arguably could be considered design flaws in the algorithm. But none of those mean that they're unusable, they're just far from perfect.
On the other hand, the process of checking people's shoes at the airport isn't merely suboptimal. It's not like we're doing it wrong. It's that we have no evidence its worthwhile at all, and it may even be counterproductive. It's a stretch to argue that ripping out AES and similar algorithms would improve the state of network security.
|
|||||||||||||