I have now posted slides for the talk I gave yesterday at Yahoo Security Week (see below). I also took this opportunity to upload the previous talks I have given since 2004 to Slideshare.
The talk was mostly an in-depth list of attacks against various crypto implementations. The good news is that developers seem to have gotten the message not to design their own ciphers. Now, we’re trying to get the message out that you shouldn’t be implementing your own crypto protocols or constructions, using low-level crypto libraries.
Instead, developers should work at a higher level, using libraries like GPGME, Keyczar, or cryptlib. You wouldn’t write a web application in assembly language. Why take the risk of implementing your own crypto constructions?
If you do end up designing/implementing your own construction, it is really important to get it reviewed by a third party. Since it can be expensive and time-consuming to gain assurance, it’s better in nearly all cases to use a high-level library. The alternative is a potential root key compromise. Are you willing to take that chance?
8 thoughts on “When Crypto Attacks! slides posted”
Nice write up and links. Thank you.
Nice site/submission handling with lynx browser. Thank you.
OpenSSL, seems a bit like bind and dns. Sure, negotiation is a fundamental part in IT balances, but still…
GPG is going more modular. Sure would be nice if OpenTLS existed. OpenSSL 1.0 is coming, but, still, OpenSSL is just like a beta in a fast moving stream = fish in trouble, seek shelter.
If only DJB could make more changes to the security industry, like he wanted. If only some would fund up some new changes. Perhaps google will. The ARM arch is getting interesting. Best wishes overall, you have a great blog.
Ahh nice! Too bad I missed this!
Here are a couple of other practical cases that may be useful:
SSH protocol 1.5 session key recovery vulnerability and
Vulnerability Report for MySQL Authentication
So, talking about slide 8,
does it mean that the following library (and similar) is not secure and should not be used?
Perhaps you can explain what problem the Java applet is solving that is not already solved by SSL.
See wiki http://en.wikipedia.org/wiki/End-to-end_encryption
Some financial web applications such as internet banking required to encrypt user data on a client side (using java applets for now), pass it through web-app-etc—> db in encrypted format.
Anton, I almost don’t know where to begin in explaining why that is not secure.
2. If the code is sent over plain http, it can be replaced with attacker code, right? Thus, you have to send the code over https.
3. But if the code is arriving over https, then why can’t you upload the data over https?
Comments are closed.