This is the first post of a series that talk about cryptography and security. First, a few references to set the context.
https://www.usenix.org/conference/usenixsecurity12/life-target%E2%80%94welcome-club
Dickie George
[I really recommend to listen to the whole thing if you have the time.]
The things that haven’t changed are the basics tenets of security. Build it right, be careful, watch for the adversary. Know that the adversary is looking for you to make a mistake. (…)
You can evaluate the heck out of a crypto logic so that you know that design is really good. And then somebody is going to implement it, and they may not implement it exactly way you think they were going to. And they could introduce a problem.
And then you got other things. You’ve got a crypto period. You are counting on these people to use that crypto very well for some length of time. It could a message, could last a week, could be a month, could be 20 years. (…) 20 years is like in a satellite. Because try to go up and change the crypto in there. It just doesn’t happen, it’s hardwired in.
around 31:00
Good guys are defensers, bad guys are attackers (…) Guys who are trying to defend the world are good guys.
around 46:00
Defense always wins (…). There’s no problem with sharing if we can get security out of it.
around 58:20
https://www.imperialviolet.org/2012/10/21/nist.html
Adam Langley
In a NIST paper about the selection of AES they state: “table lookup: not vulnerable to timing attacks.” Oops. If you’re building your own hardware, maybe.¹ (…) But a generation or more of cryptographers from that world are probably comfortable with features that were chosen with hardware in mind.
¹ Many side-channel timing attacks exists on [AES](http://cr.yp.to/antiforgery/cachetiming-20050414.pdf, there’s more attacks than links on the first Google results page.
https://lkml.org/lkml/2012/10/21/75
Linus Torvalds
(…) here’s the #1 thing to keep in mind about firmware: - firmware is always buggy.
It’s that simple. Don’t expect anything else. Firmware is written by people who have lost the will to live (why? Because they do firmware development for a living), and the only thing keeping them going is the drugs. And they’re not the “fun” kind of drugs. The end result is predictable. In their drug-induced haze, they make a mess.
So saying “ACPI is buggy” is like saying “water is wet”. Deal with it. (…) Untested code written by monkeys on crack - what did you expect?
http://dev.chromium.org/developers/tech-talk-videos/release-process
Marc-Antoine Ruel
Security can be viewed as making sure that no action is done on a user’s behalf by a third party that could go against his will. (…) Always look for the easiest [subversion] path, that’s what crooks do. They are willing to invest a significant amount of time in searching to figure out holes in the security mechanisms. And once they find something, they will use it fast to affect as many people as they can.
How do we address that? (…) That’s simple. Put your bits out as fast as you can.