Hacker News new | comments | show | ask | jobs | submit login

Overall, I think this talk best applies as a starting point for learning about crypto. Take Colin's recommendations as signposts to underlying research. Why would he dislike DSA? Hint: it requires a secure RNG at signing time while RSA only requires one at key generation time.

http://rdist.root.org/2009/05/17/the-debian-pgp-disaster-tha...

However, I don't think he achieved the stated goal of teaching you enough to become a crypto implementer in 1 hour. I disagree with a lot of his conclusions. But you'd have to learn more than the slides hint at to have a discussion on the details why.

Some specific comments on the slides.

### Common failures and their causes (2):

I find it interesting that he characterized a timing attack in Keyczar as "stupidity" while a cache-based timing attack with HTT was "unusual environment". Same thing with SSL renegotiation. I think all of these were subtle flaws and easy to overlook. The SSL bug was around for at least 10 years. HMAC timing attacks were not as widely published as they are now, but instead were part of common lore to cryptographers.

The WEP vulnerability was almost certainly not "unusual environment". Sure, there were power and cost constraints in the WEP design, but what was unusual about it was that the crypto was obviously designed by a group with no crypto experience and no public review. Using a varying key with RC4, something it was known to be weak to, was an example of "using a tool wrong" and more similar to the AWS v1 signature bug you found.

The only "unusual environment" was that the specialized and closed field of IEEE wifi design led to non-cryptographers designing crypto. There was nothing unique to the environment that a good crypto person would have had an inherent problem with.

I don't think this list is a good categorization of types of crypto bugs.

### Authentication/Signing (5)

Confusing terminology. I use "integrity protection" or "authenticator" for MAC and "signature" only for public-key signatures. They are two very different processes, even though they share some goals.

### Hashes (8)

It was funny to see SHA-1 in the "don't use" list next to MD4, for example. I agree it's best not to use it for new designs, but there's a world of difference between SHA1 and MD4, especially if you have to use SHA1 for legacy compatibility.

### Symmetric authenticators (10)

I think CBC-MAC should be on a "don't use" list, not "avoid". If you put SHA1 on the "don't" list, it's even more important that CBC-MAC be put there. Which will be broken sooner: HMAC-SHA1 or an arbitrary CBC-MAC implementation or use?

### CTR mode (17)

Based on his previous comments, I think Colin advocates CTR mode due to its supposed resistance to side channel attacks. However, it is not a panacea. See this paper by Josh Jaffe on how to use side channel attacks against CTR mode. It's quite interesting how AES's structure makes it more vulnerable to his particular attack.

http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.93.6...




By citing CBC-MAC as "DONT USE", do you include CCM mode (which is popular)?

I see clear practical reasons to avoid CBC-MAC (there's an incredibly easy and devastating keying mistake to be made with it). But you have more insight into the theoretical problems than I do.




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: