Everything you need to know about cryptography in 1 hour

http://www.bsdcan.org/2010/schedule/attachments/131_crypto1hr.pdf

by cperciva • 16 years ago

254 130 16 years ago

cperciva34• 16 years ago

On Thursday afternoon I gave my talk 'Everything you need to know about cryptography in 1 hour' at BSDCan'10. Two HNers (as far as I know -- there might be more?) came to hear me speak, but several other people here have said that they would like to see talk but couldn't attend; so here's my talk slides.

I understand that a recording will go online somewhere at some point, but I'm not entirely sure of the details about that.

rs• 16 years ago

Thanks Colin. Very informative.

johkra4• 16 years ago

Since I've only the slides, I have a question about the following point:

> DON’T: Put FreeBSD-8.0-RELEASE-amd64-disc1.iso and CHECKSUM.SHA256 onto the same FTP server and think that you’ve done something useful.

I take it the FTP got compromised and people simply regenerated the checksum for a modified image?

Wouldn't signing the checksum file solve the problem? Using different FTP servers for distributing the image and the checksums makes mirroring probably difficult.

cperciva34• 16 years ago

I take it the FTP got compromised and people simply regenerated the checksum for a modified image?

I'm not aware of any problems with FreeBSD FTP mirrors being compromised recently. I wanted an example of data-adjacent-to-hash and most of the audience was FreeBSD people, so I figured that I'd go with an example close to home.

Wouldn't signing the checksum file solve the problem?

Yes. Or just relying on the FreeBSD release announcements, which contain SHA256 hashes and are signed.

va_coder• 16 years ago

Why did you choose to publish your slides in PDF when PDF documents are a main tool for security attacks?

Update: If PDFs are a major source of security attacks, and author cares about security, and author publishes document in PDF form, then why would you downvote this question?

jodrellblank• 16 years ago

Because it's a completely nonsensical question.

If balaclavas are used in bank robberies, and you care about the safety of your money, why would you wear a balaclava on a mountain climbing expedition?

PDFs are not a tool for security attacks because they are PDFs, they are a tool for security attacks because of vulnerabilities in Adobe Reader. Any given PDF is not a danger, only PDFs with exploits are dangerous.

And including a buffer overflow exploit, rootkit and phone-home code isn't something you're going to do accidentally while publishing your talk slides, is it?

Xurinos• 16 years ago

I do not have the power to downvote, and I hate when people downvote because of disagreement but do not explain their stance -- I learn nothing from it; I can give you my perspective on your comment. (It would be nice to have a personal downvote message feature or something; the anonymity helps us avoid embarrassment, I guess.)

First, your point is irrelevant. Whatever the medium, this discussion is about cryptography. There is not a real case of hypocrisy here. Cryptography is certainly related to security, but as far as I can tell, that is not the thrust of this discussion.

Second, while the technology can be abused, as you point out, that is a far cry from this particular author abusing it and using it as a security attack. The author's PDF is fine.

I am not agreeing or disagreeing with you, btw.

In other words, I can see that this comment was downvoted because it did not meaningfully add to the discussion. I usually see downvotes on posts that include offtopic personal axe grinding. I may receive the same, myself, for this post, but I just wanted to help you avoid it in the future.

JoachimSchipper5• 16 years ago

Could you expand a bit on your comments about Poly1305 ("too difficult to implement" - but Bernstein has a library, right?) and Blowfish ("DON'T use")?

cperciva34• 16 years ago

Yes, Bernstein has written code for Poly1305; but bus factors are bad. If you decide to use Poly1305, at some point you're going to want to use it on a new CPU or in a different language, and you'll find that DJB's code won't work for you.

You should avoid blowfish because it has a 64-bit block size.

JoachimSchipper5• 16 years ago

Okay, I can see that. Most of Bernstein's crypto work falls in that category, probably.

Forgive my ignorance, but why is having a short block size especially bad? You don't want to subject 64 bits to a birthday attack, but something like CTR mode should work, right? (I still wouldn't recommend Blowfish - AES is used more widely and works perfectly well - I'd just like to understand your reasoning).

agl• 16 years ago

Poly1305 is a fundamentally different class of authenticator than HMAC-SHA256: the addition of an nonce into the function makes it unsuitable for some environments. But given Intel's new instructions, GCM is looking like a more attractive polynomial MAC these days.

lisper5• 16 years ago

What does "bus factors are bad" mean?

And as long as I'm asking questions, what about bcrypt for password hashing?

gduffy6• 16 years ago

I don't suppose you're planning to tie these recommendations up into an open source C99 library with an NaCl-like crypto_box interface? Oh, and can I have a pony too? :)

NateLawson9• 16 years ago

Better, add AES and SHA-256 support to NaCl. With your insight into preventing side channel attacks, it would be a great combo.

gduffy6• 16 years ago

I could be wrong, but I don't think NaCl is portable anywhere but x86 or x86_64. ARM needs good crypto too. Though I suppose we could ask for ARM support in NaCl too since we're asking for ponies :)

Also, does NaCl support signing? I think crypto_box offers "authentication" which is a slightly different promise.

beloch2• 16 years ago

One point I think crypto-people need to hammer home to non-crypto audiences is that they should not encrypt and transmit anything that will remain sensitive for more than 5-10 years via any form of encryption relying on factoring, one-way hashes, etc.. (Pretty much everything classical short of one-time-pads exchanged in person.) Credit card transactions? Fine. Affairs? State secrets? Not fine. If you're interesting enough, your coded messages will be archived and cracked within a decade or two (or less).

A lot of crypto algorithm's are theoretically secure for thousands of years (or longer) assuming an eavesdropper has access to existing algorithms and classical hardware with Moore's law scaling. Unfortunately, it's currently non-existing attack algorithms you really need to worry about. Advances are relentless. Then there are things on the horizon like quantum computing...

cperciva34• 16 years ago

Quantum computing is overrated. So far all it has told us is that 15 = 3 * 5 with high probability.

While Shor's algorithm demonstrates that integer factorization is in BQP, there are very good reasons to believe that many other problems are not; a large enough quantum computer may break RSA, but it won't break everything.

beloch2• 16 years ago

My point was that you don't need Quantum computing to break all existing crypto algorithms within a couple decades. QC just makes matters that much worse.

(Downplaying Quantum Computing ostrich-style is very popular in classical crypto circles for some reason, but that's a topic for another day!)

reikonomusha• 16 years ago

Wrong. We have made them do very fast Fourier transforms now. See http://physics.aps.org/pdf/10.1103/PhysRevLett.104.180501.pd... for details.

notauser• 16 years ago

I once wrote a Crypto plug-in for mIRC that relied on one time pads distributed by floppy disk. (Someone created the masters and mailed them out.)

A floppy disk worth of IRC chat is actually quite a lot but it also had a 'degraded mode' which used the last chunk of the random data as a symmetric cypher key. That would keep things going until the next disk arrived in the post.

This just goes to show that if you are stupid enough to tell a geek what the best answer is then there is a pretty good chance that they will confuse it with the right answer.

My only hope is that our inane chats about movies are, even now, causing cycles to be burned on a NSA supercomputer somewhere :-)

fhars• 16 years ago

If you were interesting to them, they would just have copied the disks while they were in the mail system. An OTP transmitted over a vulnerable channel like the postal service is not that strong, you have to exchange it in person.

natch2• 16 years ago

How is this good code?

x |= MAC_computed[i] − MAC_computed[i];

Shouldn't one side or the other (of the minus operation) be MAC_received[i]?

cperciva34• 16 years ago

Yes, that's a typo. Sorry.

(Lesson learned: LaTex is not the best language to write code in.)

natch2• 16 years ago

DO: Do what Bruce Eckel does, and have all code in a publication run through automated tests before releasing it. ;-). And... you're welcome?

Robin_Message• 16 years ago

Also,

      x |= MAC received[i] − MAC computed[i];

Is making me twitchy, I mean I'm sure we're on two's complement machines and there is no C compiler in the world where those two could be unequal but still subtract to zero* , but still, how about one of

      x |= (MAC received[i] != MAC computed[i]);
      x |= (MAC received[i] ^ MAC computed[i]);

Otherwise, Good stuff!

* Possible break: If we have a separate sign bit, then we might have 0 and -0, which would subtract to give 0. Don't know of any machine/compiler that does that though.

yread• 16 years ago

And why is the original way of not completing the for cycle for some keys wrong? Is the difference between checking the whole array and checking only lets say first byte measurable? Especially when considering that this would probably be done over a network?

cperciva34• 16 years ago

Yes, it is measurable. Remote timing attacks are scarily practical -- even a single cycle difference can be a problem, because an attacker can many many attempts and compute the average time in order to kill the noise.

tptacek15• 16 years ago

The current state of the art in remote measurement (which is in its infancy; the first papers to apply basic signal processing on measurement over IP networks are just coming out) suggest that the timeable thresholds are in the tens of microseconds over a WAN.

But that doesn't matter, because over switched "local" networks (read: from one end of a data center to another), the thresholds are in nanoseconds; everything is timeable. Attackers will spend the $30 to get a machine in the same hosting center as you as soon as the other attacks get less trivial.

mukyu• 16 years ago

Timing attacks like this have been successfully used against a few gaming consoles.

johkra4• 16 years ago

DO: Use a 2048-bit RSA key, a public exponent of 65537, SHA256, and MGF1-SHA256.

How can I set the public exponent when generating a key? man gpg wasn't helpful.

And why this particular number? I can see that it's 2^16+1, but I don't understand the advantage of this number compared to others. (Although I've been taught that people prefer small values for e now.)

cperciva34• 16 years ago

That was explained in the audio part of the talk. :-)

Short answer: A long list of attacks in the past have been much harder with large public exponents; using 2^16+1 instead of 3 is a bit slower but is likely to make you safer if someone else gets smart in the future.

johkra4• 16 years ago

Thanks for answering my curious questions so far. =)

Since I messed up formatting earlier, my first question about generating keys with this particular exponent was hidden:

Do you know how to generate such a key pair using gpg (or another tool)? Or is this done automatically?

d0mine• 16 years ago

There is a typo "which which" on the 2nd "Side channel attacks" slide.

cperciva34• 16 years ago

Thanks! That slide was written somewhere around 5 AM...

ableal2• 16 years ago

Slide 5, line 2: "The ciphertext is the data we evil people get to see." [emphasis added]

(Admission that there is something to the beef with the old BSD logo ? ;-)

cperciva34• 16 years ago

Oops. Freudian slip, I guess. :-)

Thanks!

lsc4• 16 years ago

>Don't even dream about storing your user's passwords on your server. No, not even if they are encrypted.

While I always follow this when it comes to ssh logins, how do you suggest doing this for webapp logins? force everyone to use client certificates? mod_auth_kerberos? (hell, for that matter, kerberos keeps user passwords on the keyserver)

I'm working on bringing my web bits up to snuff, and I'm seriously considering forcing the use of client certificates. That, or just saying 'fuck it' and writing a ncurses billing app that you ssh into. no web interface at all.

Both of those solutions might work okay for me because I have a highly technical userbase, and my marketing is strong enough (or rather, I have other bottlenecks that are bad enough) that I can turn away some customers, but I don't see them working for most web applications.

mootothemax• 16 years ago

I think he's saying don't store the users' actual passwords, store salted hashes instead :)

gduffy6• 16 years ago

Well, more explicitly PBKDF2 or scrypt. Some people might take "salted hash" as MD5(password+salt) or something.

geoffc• 16 years ago

The manifestation of this crisp thinking is tarsnap. The best linux backup product I have ever seen.

cperciva34• 16 years ago

Thanks!

anagri• 16 years ago

http://www.norvig.com/21-days.html

there ain't anything called learn it in x hrs/days

Groxx2• 16 years ago

Am curious as to why to use "x |= MAC_computed[i] − MAC_received[i];" instead of the block-wise comparison. Wouldn't the x |= approach be less secure, because two (or more) differences may cancel each other out? (am assuming that |= == ||= in Ruby, or a bitwise OR)

gjm112• 16 years ago

No, not possible for differences to cancel. The bitwise OR of a bunch of things is zero only if all of the individual things are zero. The difference between two things is zero only if they're equal. Therefore, the final value of x is zero only if all the elements of MAC_computed and MAC_received match.

(And -- the main point here -- how long it takes to do the calculation should be totally independent of what's actually in the arrays: no early termination, no operations that take different amounts of time depending on how many elements match, etc.)

Groxx2• 16 years ago

ah, bitwise or, was thinking incorrectly for some reason. And early termination makes sense, thanks! Didn't think of that.

shin_lao2• 16 years ago

Great slides, some comments though.

I feel they focus too much on "use process X and algorithm Y".

The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place. In other words: threat modeling. There isn't a single slide about threat modeling, unless I'm mistaken.

If your error boils down to using SHA-1 instead of SHA-256, that's trivial to fix and you won't be exposed to real world attacks anytime soon.

Talking about side channel attacks on a hyperthreaded core is just going to confuse the audience. This is a very sophisticated attack that require the attacker to be able to run code on the target machine. If that's your only vulnerability, consider yourself happy.

cperciva34• 16 years ago

The difficulty is not to choose the algorithm or the process, but to understand what kind of problem you're dealing with in the first place.

I agree, up to a point. But there's no way you can teach that sort of understanding in 1 hour. :-)

The purpose of this talk was to provide a checklist for developers of what they should and should not be doing.

tptacek15• 16 years ago

But, for instance, you recommended CTR-mode AES-256, but didn't discuss:

* How to set the counters so that counter/IV can't collide and destroy your security

* What metadata your messages need to include to make them not replayable

* How to canonicalize your messages so that the process of packing, authenticating, encrypting, decrypting, and unpacking doesn't change the intent of a message.

I think that may be what the grandparent comment is getting at.

shin_lao2• 16 years ago

That's where we disagree. I think checklists are not the way one should approach a problem.

You don't want developers to follow a checklist, you want them to use their intelligence.

One hour is enough to make developers realize they know nothing about cryptography. Once they reach that point, they will be on the right path (ie really learn about the topic or ask someone who knows).

The most common error isn't improperly used algorithms or techniques, it's improperly used cryptography.

Example: securing a file with AES-CTR and having the password hardcoded in the binary.

moserware• 16 years ago

> * SSL requires that you decide which certificate authorities you want to trust.

One subtle point is that governments can force seemingly great certificate authorities to give them a certificate so that they can do man-in-the-middle attacks and still have a reasonable "trust chain" that you can look at in your browser. More details of this "compelled certificate creation attack" at http://cryptome.org/ssl-mitm.pdf

If I had to bet, I'd say most serious attackers aren't bothering to break crypto math or even weak implementations but are rather focusing on this approach by getting a CA to give them a good cert to spoof another site and it'd go practically undetected.

Ultimately with crypto (or anything else) you have to implicitly trust somebody (e.g. Mozilla Foundation) or something (your processor to correctly execute a program or your quantum crypto box to not behave maliciously). As long as this is the case, you can't have perfect security.

Great paper of "Reflections on Trusting Trust" : http://cm.bell-labs.com/who/ken/trust.html

yannis2• 16 years ago

Slides look great and so is the presentation. May I ask what you used to prepare them?

cperciva34• 16 years ago

LaTex beamer, with the Warsaw theme.

eru3• 16 years ago

Seems to have become the standard in mathematical circles.

yannis2• 16 years ago

Thanks will give it a go.

Nelson69• 16 years ago

What's wrong with Elliptical curves?

Seriously, are there some known attacks against ECDSA? And what of DSA2?

gjm112• 16 years ago

I'm neither Colin nor a cryptographer, but I think elliptic curve cryptography (1) involves more complicated ideas and code (which might therefore be easier to get wrong), and (2) is subject to more patent claims, than its rivals, without any obvious big benefit to outweigh those facts. [EDIT: oh, and because of 1 and 2 ECC is used less, and therefore your implementation mightn't have had its bugs and design flaws so thoroughly shaken out.]

Certicom has ~130 ECC-related patents. You probably don't want to have to crawl through them all making sure that your code, or someone else's code that you're using, doesn't infringe (and won't be found to infringe by a not-necessarily-infallible jury if you get sued anyway).

[EDIT again: actually, ECC does have a claimed big benefit, namely not needing such long keys. But one might reasonably be worried by the possibility that an algorithmic breakthrough some day might suddenly make longer keys necessary...]

tptacek15• 16 years ago

ECC is extremely well studied and implemented almost by default in embedded settings. There are providers of it other than Certicom.

The reality is, you need to consult a cryptographer before you implement any public key system. RSA and vanilla DSA are also spectacularly easy to screw up.

cperciva34• 16 years ago

From the audio part of the talk: Elliptic curves are considerably harder to implement correctly than RSA. DSA has expensive signature verification, and you're far more likely to create one signature and verify it many times than vice versa.

EDIT: Also, elliptic curves are heavily patented. I mentioned this in my talk (the audio portion, not the slides) but forgot when I woke up and started answering questions here this morning. :-)

hackermom• 16 years ago

I found some of the information in this presentation to actually be wrong. The guy repeats himself, and at two points he even contradict himself. I also didn't like that a very large portion of it was presented with a very fervent zeal, replacing actual knowledge of why and why not with useless favorism and indoctrination; the guy is a zealot, and that's a very, very bad ingredient in any serving of important information.

I would not recommend this particular presentation to anyone.

add.: Thanks for the downvote, Colin :D Oh boy...

cperciva34• 16 years ago

at two points he even contradict himself

Where are those?

replacing actual knowledge of why and why not with useless favorism and indoctrination

I provided some explanation of why and why not in the talk. Slides != transcript.

EDIT: And no, the downvote didn't come from me.

Deestan• 16 years ago

Please remember that this wasn't a book chapter or a blog posting, but presentation slides.

As presentations are normally held, the slides are just key excerpts from the one hour talk he was holding while the slides whizzed by.

khafra4• 16 years ago

Hackermom, you sound confused about the downvotes. To provide a bit of background: Colin Percival has a doctorate in computer science from Oxford, has won the Putnam, has been FreeBSD's security officer for years, and discovered the hyperthreading leak noted in this presentation. Most people who've been on Hacker News for a while trust his judgement.

I'd like to think we would all--cperciva included--welcome specific criticisms or errors, but by claiming they exist without naming them, you're asking us to take your word over his. Your score reflects the fact that you haven't earned that.

tptacek15• 16 years ago

Careful. Colin Percival isn't David Wagner or Dan Boneh or even Daniel Bernstein. He wrote a paper on a side channel attack during a window of time when everyone was writing papers on microarchitectural side channel attacks, wrote a pretty cool paper on a password derivation function, and, like the authors of SSH, Tor, and DESLogin (none of them professional cryptographers), built a bunch of cryptography into a well-understood Unix networking problem.

I very much respect Colin and fully expect him to kick my ass in arguments, but, in particular, I find a good portion of his advice does not square with my professional experience; in other words: he's saying things that lay developers have already heard, and, empirically, lay developers produce very bad crypto.

caf2• 16 years ago

I'll be interested to hear the thoughts behind the "Probably Avoid" recommendation on DSA and EC signatures. They're both attractive in some situations because they produce much shorter signatures than RSA.

The recommendation for AES-256 over AES-128 runs contrary to Schneier's advice. It makes it hard for the non-experts when the experts can't agree...

cperciva34• 16 years ago

DSA and EC both have benefits in some rare circumstances. That's the 1% of the time when you ought to consult a cryptographer.

I'm aware that my advice concerning AES does not match Schneier's advice. I don't think he takes side channel attacks seriously enough.

tptacek15• 16 years ago

He also thought "cube cryptanalysis" was going to break most modern ciphers. Do you think he's a serious practitioner? I think he's a pundit.

carlhaagen• 16 years ago

i kinda found this presentation to be chock full of "i am right, you are wrong" "i know better than you" et cetera. it's as if he's trying to coerce people into using what -he- thinks is best and what -he- prefers, but not really caring for sorting out the facts or explaining the details to give people a big enough picture to make educated choices of their own. "just go with this and that, trust me it's the best". no question actual knowledge is in there, the guy knows cryptology, but this seems to be a slide for indoctrinating people into sharing his preferences in crypto, not for teaching, and i personally find it to be the completely wrong approach.

cperciva34• 16 years ago

i know better than you

Well, I do know better than my audience. That's why they came to my talk. :-)

robryan• 16 years ago

Given a one hour overview though there has to be some of this. No time for the history of cryptography and the pros and cons of all the methods employed. It seems he wanted the audience to take away some key points that if without any other knowledge should prevent the majority of attacks.

tptacek15• 16 years ago

The repeated advice in this talk not to use block cipher modes that provide both encryption and authentication (which also follows from the advice not to use CBC-MAC) is contrary to a lot of professional best practice advice, very much including NIST, and represents Colin's opinion more than it does a consensus on the issue.

It is easier to get something wrong when it has more moving parts. You are less likely to screw up EAX-mode AES --- presuming your library "just does it" for you --- than you are to screw up CTR-mode AES and HMAC-SHA256.

The rest of the talk looks great, although I flinched when I saw the CTR recommendation, because CTR is also really easy to screw up.

Obviously, the comments about SSL are crazy. But you expect that going in to a Colin talk.

cperciva34• 16 years ago

CTR is also really easy to screw up

That recommendation wasn't about avoiding 'easy to screw up'. That one was about avoiding 'almost impossible to avoid having your key stolen via a side channel attack'.

Obviously, the comments about SSL are crazy.

Do you disagree with either of the following two pieces of advice?

  DO: Use SSL to secure your website, email, and
  other public standard Internet-facing servers.
  DO: Think very carefully about which certificate
  authorities you want to trust.

tptacek15• 16 years ago

I disagree with the assertion that SSL is a bad protocol. It's an ugly protocol, but that's because things that are elegant are rarely secure.

And, of course, I disagree with your reasoning about authenticated encryption. You're saying, "you're exposing your block cipher to direct attack by overloading it to both encryption and authentication". But it's probably exposed to side-channel attacks either way. Meanwhile, the implementation flaws that people end up with in naive HMAC systems break far more systems.

I suspect this is another example of the impedance mismatch between your academic approach to this and my "having to slog through people's terrible crypto on a monthly basis" approach.

jasonkester• 16 years ago

As somebody who's not already a crypto expert, I found those slides next to worthless by themselves. I suspect that the speaker put a lot of extra explanation into them during the talk to explain why TLA1 is better than TLA2, but it doesn't come across at all in the text.

As an example, I'd read an article about timing attacks, so I knew what the author was getting at in the slide about rewriting that loop. If I saw the slide without any background, I'd have been left scratching my head since it doesn't make any attempt to explain the actual issue.

Let us know when the audio is available. I'll keep the slides around until then.

cperciva34• 16 years ago

I suspect that the speaker put a lot of extra explanation into them during the talk to explain why TLA1 is better than TLA2, but it doesn't come across at all in the text.

Yep. There's a practical limit to how much text you can put into slides and have them still be useful; I decided that it was more useful to have the recommendations in the slides and the reasoning orally than vice versa.

khafra4• 16 years ago

Is the audio of the talk available online? A cursory googling of bsdcan sources didn't yield anything.

tptacek15• 16 years ago

I think I can sum up the fundamental difference between my take on crypto (run away!) and Colin's ("use OAEP padding instead of PKCS!").

When Colin thinks of crypto he thinks of things like Tarsnap, which was built and designed to embrace cryptography; cryptography is part of the reason it exists. It is not an afterthought.

When I think of crypto, it's about all the places crypto pops up in normal non-secure CRUD-webapp situations. Like the guy who uses crypto to effect single-signon without sharing databases between apps. Or the team that encrypts URLs instead of implementing access control. Or the team that uses AES to "secure" a viewstate cookie.

If your goal is to produce a system like Tarsnap, which from day one is going to receive attention from security people because it is a security tool, I have less of a problem with Colin's recommendations.

But if you're trying to build client-side database-free single signon (ab)using crypto as a tool, this slide deck is terrible. Follow every piece of advice in it and you will very likely still produce a system that is easier to break than if you hadn't used crypto.

NateLawson9• 16 years ago

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...

tptacek15• 16 years ago

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.

Everything you need to know about cryptography in 1 hour

Related Stories