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?
rdist 
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?
http://www.clipperz.com/open_source/javascript_crypto_library
Instead of asking about the security of a particular implementation of ECC and AES in Javascript, how about explaining a situation where Javascript crypto solves a problem? And doesn’t introduce new weaknesses?
Ok, the reason why I’m asking about it is that many web apps (like internet banking) uses java applets to encrypt the data and provide end-to-end encryption on the top of SSL. Do you think it’s possible to replace such applets with javascript code only and keep the security on the same level?
Thank you.
SSL is end-to-end encryption. So it’s unclear what a Java applet adds on top of that. My point is that the language (Java, Javascript, DHTML) is irrelevant. With web-based content, the root-of-trust is the server, no matter how you try to dress it up differently.
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.
So the question was can such applets be replaced with javascript (using such libraries) and what is the risk?
Anton, I almost don’t know where to begin in explaining why that is not secure.
1. Whether you use Java or Javascript, the code has to come from somewhere (your server).
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?
QED