You are dangerously bad at cryptography
happybearsoftware.com
You are dangerously bad at cryptography
1–10 of 174 posts
Re: You are dangerously bad at cryptography
#2Saying stuff is hard is easy, and as far as I can tell, very correct about cryptography.
More useful would be actual suggestions to enable average developers to do more things with some degree of confidence. In other words, libraries, recipes and other documentation, and so on.
"Hire an expensive security guy" is probably not a feasible solution for many small startups, nor very scalable in any case.
Also, out of curiosity, in his timing attack example, the difference in time caused by the string being equal seems like it'd get absolutely swallowed up by the random nature of the universe - do those things actually work in the real world, on real servers with varying loads and numbers of users and network traffic?
Re: You are dangerously bad at cryptography
#3When he is saying
>Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right.
I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend an MD5ed string and keep the original MD5 value. Then again, I know that MD5 isn't a secure cryptographic hash function so I wouldn't have used it from the start. Nice to know why thats the case.
Re: You are dangerously bad at cryptography
#4Saying stuff is hard is easy, and as far as I can tell, very correct about cryptography. More useful would be actual suggestions to enable average developers to do more things with some degree of confidence. In other words, libraries, recipes and other documentation, and so on. "Hire an expensive security guy" is probably not a feasible solution for many small startups, nor very scalable in any case. Also, out of cur…
Hi, author here. I would have liked to have made useful suggestions, but having made so many errors with cryptography in the past, I don't really feel qualified to do so.
I do however recommend getting in touch with tptacek and co and doing the crypto challenges. I mentioned this at the bottom of the post.
Edit: re: timing attacks, it helps if you're in the same data centre. I've never personally implemented a timing attack, so I'm hesitant to make any assertions further than that either way.
Re: You are dangerously bad at cryptography
#5When he is saying >Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right. I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend a…
Is there a repository or central location of the established and well tested solutions for developers to use? Where does one start?
Re: You are dangerously bad at cryptography
#6When he is saying >Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right. I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend a…
Is there a repository or central location of the established and well tested solutions for developers to use? Where does one start?
Wikipedia perhaps?
Re: You are dangerously bad at cryptography
#7So, sure. I'll admit that I'm bad at cryptography.
You win!
But the problem is, the world needs more, not less, crypto. We need to integrate crypto into more places, not run and hide and declare it too hard every time we come across it.
Is it easy to screw up? Sure. So is manually allocating memory. But we use higher level languages to help protect us from ourselves.
So too can we use higher-level libraries to help protect us from some mistakes we can make with crypto.
I'm working on an app which uses crypto heavily- In initial versions, I used manual RSA keys, but I recognize that no matter how smart I think I am (not very), it's easy to mess stuff up.
I can screw up the padding, I can screw up the implementation. Other clients which interop with me can screw up...
So Instead, I've swapped to using GPG keys. Is it perfect? Heck no! But it reduces the code that I have to get right. It outsources the parts that are most likely to be screwed up to a place where they're more likely to be reviewed, more likely to be written by non-fuckups.
There are lots of higher level libs, gpg is just one of them. keyczar, etc are also ways to solve this problem.
But we shouldn't run in fear everytime someone mentions the word Crypto, just because we have a chance of messing up.
Re: You are dangerously bad at cryptography
#8When he is saying >Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right. I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend a…
Hi, author here, I'm glad you found it useful!
> I didnt know for example that you can basically extend an MD5ed string and keep the original MD5 value
Thank tptacek for that knowledge, I think I picked it that up in a talk he did that's somewhere on Vimeo (will link to it).
> Then again, I know that MD5 isn't a secure cryptographic hash function so I wouldn't have used it from the start. Nice to know why thats the case.
Nope! I was going to mention in this in the post but removed it to keep things simple: This particular vulnerability is not due to MD5 collisions or MD5 being cryptographically insecure. It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends. Even if MD5 were cryptographically secure, this vulnerability would still present itself if used in the way I described.
Don't mean to nitpick, but with crypto small misunderstandings lead to big vulnerabilities. Hope that makes sense :)
Re: You are dangerously bad at cryptography
#9When he is saying >Save yourself the trouble. Don't use cryptography. It is plutonium. There are millions of ways to mess it up and precious few ways of getting it right. I am sure he means don't use your own homegrown cryptography solution. Use something established and well tested. Good advice, probably can't be repeated enough. I liked the exampled he gives, I didnt know for example that you can basically extend a…
Doesn't matter if it's MD5 or SHA512. You can extend either hash function in the exact same way (http://en.wikipedia.org/wiki/Length_extension_attack)
Re: You are dangerously bad at cryptography
#10> This means that as long as you have one example of a signed message, you can forge signatures for that message plus any arbitrary request parameters you like and they will authenticate under the above described scheme.
If all requests are made over HTTPS, how could a third party intercept a signed message? How is this any greater of a risk than a third party intercepting user login information? (This is a serious question; I'm not being flippant or saying 'gotcha')