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.
I understand that a recording will go online somewhere at some point, but I'm not entirely sure of the details about that.
> 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.
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.
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?
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?
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.
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.
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.
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.
Funny, my experience has been exactly the opposite.
But [your block cipher] probably exposed to side-channel attacks either way.
Exposed, yes. Exposed to attackers who don't hold the MAC key, no. Exposed to chosen-ciphertext side channel attacks, no. These distinctions matter.
having to slog through people's terrible crypto on a monthly basis
I do this too. But I try to educate people so that they write slightly less crypto.
The other thing that makes it ugly are the huge numbers of cipher suites and reliance on certificates (and thus usually centralized CAs.) The cipher suite growth came about because of export controls and then Internet-standards groups not seeing a problem with adding vanity modes. The reliance on CAs can be worked around with using your own cert store or using TLS-SRP for authentication, which is sorely underused.
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.
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.
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.
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.
* 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.
Put another way: find me one crypto library or application implementing CTR mode that got all the above issues right but used a poor block cipher (not AES or 3DES).
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.
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...
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.
(Downplaying Quantum Computing ostrich-style is very popular in classical crypto circles for some reason, but that's a topic for another day!)
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 :-)
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
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.
So PBKDF2 or scrypt just slows down the process of checking a users password against a hash, right? That does make sense in that it does slow down an attacker (and combined with a strong user password it seems like it could be secure) but it doesn't solve the essential problem that humans are not good at remembering random things, and there is a limit to how slow your 'check password' function can be in production. your attacker can almost always be assumed to have more computing resources than you do.
Additionally, salts protect against attacks that use pre-calculated tables.
I haven't read Colin's scrypt paper, so I'm not sure if its strategy differs.
I'm not saying that slowing down the checking of a password has no value; Clearly it has much value. Without it, even a strong password would be brute forced quickly. I'm just saying, I am missing how it solves the problem of weak passwords.
The real problem here is that I know I can't remember a sufficient degree of entropy. Sure, there are all sorts of ways to fake it; take the first letter of every word in a sentence, but that's not exactly random, either. I know a guy who, for a pass phrase, would use a 24 line block of text from some project Gutenberg title. I doubt that was any more secure than 4 or 5 random characters.
10000 * 1s = ~2 hours cpu time, but that's a terrible password -- common words plus 3 digits means 1000 * 10000. 26^6 * 1s = ~10 years CPU time -- a few thousand bucks on EC2 -- that's getting better for what is still a pretty weak password. In any case, straight MD5s are super-fast. At 1e5-1e6 MD5s/second or more on a modern CPU, paying the compute cost for a 1 cpu-second KDF can be several orders of magnitude stronger than MD5(password+salt).
Can you tell me more about allowing the user to cache the derived key within the context of web applications? that would mitigate the limitation I was describing (where how slow you made the password check was limited by what delay a user would tolerate when logging in.)
Also, does NaCl support signing? I think crypto_box offers "authentication" which is a slightly different promise.
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.)
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.
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?
openssl genrsa -f4 2048
x |= MAC_computed[i] − MAC_computed[i];
Shouldn't one side or the other (of the minus operation) be MAC_received[i]?
(Lesson learned: LaTex is not the best language to write code in.)
x |= MAC received[i] − MAC computed[i];
x |= (MAC received[i] != MAC computed[i]);
x |= (MAC received[i] ^ MAC computed[i]);
* 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.
Relevant portion of assembly (no optimizations):
cmpl $1, -20(%rbp)
movzbl %al, %eax
orl %eax, -4(%rbp)
Most other architectures have one of:
1) condition codes that you can use to predicate an "or $r1, $r1, 1" (e.g., ARM)
2) compare instructions that put a 1 or a 0 in a result register, which can be directly ORed in. (e.g., MIPS)
Of course, that code only works if you are either not writing in C89 or if your compiler and ISA conspire to always return exactly one from true boolean expressions. It is my understanding that the C89 standard only requires "nonzero," so you might need "a |= (b != c) ? 1 : 0;*" instead.
YMMV depending on compiler and architecture, but the 2 or 3 platforms I tried without passing any opti flags were branchless.
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.
You should avoid blowfish because it has a 64-bit block size.
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).
And as long as I'm asking questions, what about bcrypt for password hashing?
I'm a little confused though. S-crypt seems to be a symmetric encryption algorithm and to store passwords you need a one-way hash. I'm obviously missing something. What is it?
Yes, I can figure all this out by reverse engineering the code. But is that really what you intend people to do? Even just a couple of sentences of documentation would save a lot of people a lot of head-scratching, e.g.:
"The scrypt key generation function itself is called crypt_scrypt. Its signature is in lib/crypto/crypto_script.h. The reference implementation is in crypo_script-ref.h. There are two optimized implementations, one for CPUs that have SSE support, and another for ones that don't. You don't have to call any initialization functions before calling crypto_scrypt."
Or something like that. If your goal is really for people to use this I think you'd see a pretty large ROI from the effort it would take you to write a paragraph like that and stick it in a README file in the distro.
Just a suggestion.
I thought you were asking where the function itself was defined -- which, as I said, is in the paper.
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...
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.
(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.)
Seriously, are there some known attacks against ECDSA? And what of DSA2?
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. :-)
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...]
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.
Unusual environments need special treatment.
Where I know we do disagree: public key crypto is a threshold over which I would not be OK implementing a custom cryptosystem. If I need public key, it's GPG or nothing. I am terrified of public key crypto.
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.
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.
(Admission that there is something to the beef with the old BSD logo ? ;-)
(And Muphry struck me too - it's in page 6. I double checked the number and then typed the wrong one ...)
I would not recommend this particular presentation to anyone.
add.: Thanks for the downvote, Colin :D Oh boy...
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.
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.
Even that is more than required by the fundamental message I'd hoped to convey; which is "making something and sharing it can be useful; giving non-specific criticisms from a noncommitted, unassailable position is not useful." Reputation is simply bayesian evidence with which one can weight an otherwise-unsupported claim.
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.
As presentations are normally held, the slides are just key excerpts from the one hour talk he was holding while the slides whizzed by.
Well, I do know better than my audience. That's why they came to my talk. :-)
there ain't anything called learn it in x hrs/days