Live data from Hacker News

You are dangerously bad at cryptography

happybearsoftware.com

11–20 of 174 posts

Re: You are dangerously bad at cryptography

#11

When 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?

Some ideas, depending on what you need (I can't say how good these are):

http://www.keyczar.org

http://nacl.cr.yp.to

https://github.com/jedisct1/libsodium

http://www.gnupg.org

Re: You are dangerously bad at cryptography

#12
post #2

Saying 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…

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

You could make each request many times, and then average them together. I don't know how many requests you'd have to make to overcome the random fluctuations though -- probably a lot.

Re: You are dangerously bad at cryptography

#13

When 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?

One of the problems with cryptography is that "solutions" are not as generally applicable as one might want. There are a lot of assumptions that are made, and violating those assumptions is usually a disaster.

For example, when it comes to encryption, it is typically assumed that all messages are the same length. If your application does not make this guarantee, encryption may not provide you with any security. You could wind up in this situation:

https://news.ycombinator.com/item?id=2661890

Think of it this way: asking for a list of tried-and-true crypto solutions is like asking for a list of tried-and-true database schemas. There might be cases where it will work, but for the most part you need to put some thought into what you are doing.

Re: You are dangerously bad at cryptography

#14
Then there is the question; Is your app likely to ever be attacked at all? By someone good? With a lot of time?

If not, perhaps hiring a cryptography expert is overkill, and you are better off just using whatever your framework offers, or integrate some library yourself. You are not a bank.

Re: You are dangerously bad at cryptography

#15
post #7

So, 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 p…

What we really need is a cryptography language, to do for cryptography what SQL does for databases. I should be able to say, "Messages have this form, and they need to be encrypted end-to-end with authentication and without surreptitious forwarding," and have the right components assembled for me. Unfortunately, our understanding of cryptography is not well-developed enough to create such a system, and so we still fumble around and usually produce systems that are vulnerable (did you remember to have a good source of entropy? did you make sure your messages are all the same length? does your system compose well with others?).

Re: You are dangerously bad at cryptography

#16
About the timing attack on HMAC that the article mentions. It takes thousands if not hundreds of thousands of requests to gather the data (and let's assume you can indeed extract the data out of all the noise cause by network latency etc...), and any properly designed API should have a throttle measure built in to prevent brute force attacks like this.

A good, secure API is protected by a variety of measures, not just through the request authentication component. Of course you should still make your auth as secure as possible.

Re: You are dangerously bad at cryptography

#17
post #2

Saying 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…

>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? You could make each request many times, and then average them together. I don't know how many reques…

Also, this random behavior will be significantly amplified if the host is running inside of a VM.

Re: You are dangerously bad at cryptography

#18
His insight that crypto is hard because you don't get feedback when you mess up is good. It made me wonder what other domains are like that -- domains where correctness seems within reach, yet there are subtle aspects that are hard to state. Some that come to mind:

* Concurrency. It's easy to introduce race conditions, livelocks, or deadlocks without even knowing. They are often difficult to observe or reproduce, and it takes a lot of hard-won experience to become sufficiently critical of your own incompetence. On the other hand, the tools are improving here (helgrind, relacy, threadsanitizer).

* Exception-safety. I don't mean in the weak sense of "won't leak resources" but in the stronger sense of leaving the system in a consistent state after an exception. Again, it's difficult to analyze or induce all the different code paths that might occur, and difficult or expensive (depending on your starting point) to roll back your mutations. Again, there are tools that help with this, like STM or cheap persistent data structures (so you can do a bunch of mutation that is only committed atomically at the end).

Are there others? Can the progress in these domains shed light on how to make crypto safer?

Re: You are dangerously bad at cryptography

#19
post #14

Then there is the question; Is your app likely to ever be attacked at all? By someone good? With a lot of time? If not, perhaps hiring a cryptography expert is overkill, and you are better off just using whatever your framework offers, or integrate some library yourself. You are not a bank.

The message extension attack is pretty well known by crackers, which could leave your webapp open to pre-scripted kit attacks that simply crawl the web.

Re: You are dangerously bad at cryptography

#20
post #4
post #2

Saying 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…

I am doing this. It looks fun.
Post reply on HN