Should developers learn crypto?
Over the weekend, Paul Maher posted an article in which he asked if developers needed to understand cryptography.
I responded in his comments, but it needs a bit more detail than I provided in the comments.
I'm all for developers learning about crypto. But developers also need to understand that it's all well and good for them to understand crypto, as long as they don't ever actually attempt to IMPLEMENT crypto.
Because if they do attempt to implement crypo, they're going to get it wrong.
There have been WAY too many examples of this. From the initial Microsoft PPTP implementation, to Netscape's SSL implementation (I can't find the reference right now, but the original Netscape SSL implementation used an easily discovered initialization vector which rendered the encryption essentially useless), to the authentication scheme for Dark Age of Camelot, the list goes on. All of the above issues have long been fixed, but that doesn't matter, because they all share a common flaw.
The root cause of each of these failures was a developer that thought they understood crypto but didn't REALLY understand it.
Whenever a developer decides that they can implement crypto, they need to stop and rethink what they're doing, because they ARE going to get it wrong.
It makes sense for a developer to understand the relative strengths and weaknesses of different crypto solutions, to understand why SHA-1 is better than MD5, etc.
But developers also need to understand that doing cryptography right requires special skills that most developers don't have.
Instead of attempting to roll their own crypto, they should rely on the cryptographic solutions that are built into the platform (CryptoAPI is your friend). If you stick to existing implementations, you're less likely to mess it up.
And whatever you do, don't attempt to roll your own authentication scheme - for every way you can mess up crypto, there are a dozen ways you can mess up authentication. See this wonderful dialog (I've referenced it before) for an example of the kind of pitfalls you can hit designing an authentication system.
So it makes sense for a developer to LEARN crypto. But developers shouldn't believe that they can IMPLEMENT crypto. Because (with very few exceptions) they can't.
So feel free to learn about crypto - there's a lot of great stuff there. I highly recommend Simon Singh's "The Code Book" (or the YA version of the same book) And of course Schneier's Applied Cryptography is a classic.
But recognise that just because you've read a couple of books about cryptography, in general you're not competent to actually implement cryptography.
Comments
- Anonymous
July 05, 2005
Oooo Harsh!
But sooo true. - Anonymous
July 05, 2005
Even with developers not implementing their own cryptography routines, they still need to learn that cryptography != security. I hear way too often "just use some certificate to encrypt the data" when this is not the solution. - Anonymous
July 05, 2005
JimBob, that is SO true. I'd forgotten about that one :)
If I hear "We're secure, we use 128 bit crypto" one more time...
1024 bit crypto with a weak password is just as insecure as 40bit crypto. - Anonymous
July 05, 2005
Microsoft seems to favor S/MIME crypto (certificates, etc.) over PGP / GPG -style crypto (public keys, private keys)
Is there a reason for this? I find PGP / GPG to be more appealing, as the keys can be easily and freely generated / stored by the end-user, without requiring a Certificate Authority.
Can I request enhanced support for PGP / GPG in future Crypto API's? - Anonymous
July 05, 2005
Maurits, I have no idea on this one, but my guess is that S/MIME is an open standard, while PGP/GPG isn't (just because there's an open source implementation doesn't mean that the encryption is open).
There may also be other legal issues associated with GPG/PGP, but IANAL, and wouldn't dream to speculate as to the reasons. - Anonymous
July 05, 2005
Another good book to read is "Security Engineering" by Ross Anderson. It's not primarily a crypto book (though it covers it) but deals with the implementation of security in real-world systems. It's full of fascinating stories (R.A. is a professor of computer security at Cambridge University) and it will teach you not to treat cryptography as a panacea. - Anonymous
July 05, 2005
DO NOT IMPLEMENT is not full clause. There are so many ways to loose security even by standard way.
As you know, Whidbey introduces SecureString. Just think about how passwords used before Whidbey: they was simple strings!
Don't you think GC shuffles string objects around and fills all the heap with your password? Oh, you should think so. Because GC really does shuffles password strings around the heap. And you get in trouble even you are not trying to IMPLEMENT any crypto!
So really working clause is: don't know what you not know.
In other words, not trying to play with security is much more secure than randomly adding security to some places. - Anonymous
July 05, 2005
FYI: Bruce Schneier has reported that SHA-1 has been effectively broken:
http://www.schneier.com/blog/archives/2005/02/cryptanalysis_o.html
Probably time to find a stronger algorithm... - Anonymous
July 05, 2005
The comment has been removed - Anonymous
July 05, 2005
The comment has been removed - Anonymous
July 05, 2005
Agreed. Most of us are not mathematicans of that particular field so we should not mass with the job that requires real experts. - Anonymous
July 05, 2005
The comment has been removed - Anonymous
July 05, 2005
Sushant:
You're not being harsh.
There's a lot of added support in Whidbey. I realize that doesn't help you now, but lots of folks here in Redmond had problems with what was previously offered in System.Security.Cryptography. We had to recommend that developers use Capicom to round out the missing functionality. P/Invoking all the Win32 APIs would be incredibly painful.
That said (DevDiv is gonna hate me), if you write something you want government employees (nice market to grab) to run you're better off coding to the Win32 APIs. They either have or will soon (depending on OS and I've lost track of where each one is) meet Common Criteria. I haven't seen .Net do that.
I should really start my own blog instead of spending my time responding to people in Larry's comments. Oh well. - Anonymous
July 05, 2005
The comment has been removed - Anonymous
July 05, 2005
Spot on - developers should learn the basics of cryptography & when to use it & never implement it themselves. But they should also learn which algorithms have flaws and which ones they should be using depending on the situation.
For instance, if you're looking for a hashing algorithm, and you're using .net you'll have the choice of MD5 and SHA1 through SHA512. But MD5 isn't as secure as previously thought... so you'd generally want to avoid using it in favour of SHA256 or SHA512, depending on the situation...
The same goes for 2-way encryption. DES is obsolete, but you might still unwittingly use it in .NET... - Anonymous
July 06, 2005
The comment has been removed - Anonymous
July 06, 2005
I see the comment against PPTP, so your recommendation is L2TP then, for VPN? - Anonymous
July 06, 2005
As far as i know, there are no issues with PPTP, and there should be no issues with it's use.
The original PPTP version was developed by deveopers, not cryptographers. Then we had the cryptographers review the protocol and found problems. So we fixed them. Bruce Schneier reviewed the V1 of the protocol and found the same issues we had found. The only current complaints that Schneier has about the protocol is that it's as secure as the user's password - if the user has a strong password, it's ok, if they don't, it's not.
Mike, rand() isn't cryptgraphically secure. To my knowledge, no C runtime libraries version of rand() is cryptographically secure.
If you want crypto-grade random numbers, try CryptGenRandom(). - Anonymous
July 07, 2005
I can't agree with you more Larry. The best way to go about these kind of things is to understand what you are implementing (and why) and then use what the experts build for you.
I wrote something similar to this a while ago concerning multithreading here:
http://www.geekswithblogs.net/pstathakos/archive/2005/06/17/44086.aspx
Hope the URL doesn't get shredded... - Anonymous
June 16, 2009
PingBack from http://workfromhomecareer.info/story.php?id=20541