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?
You are dangerously bad at cryptography
11–20 of 174 posts
Re: You are dangerously bad at cryptography
#12Saying 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…
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
#13When 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?
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
#14If 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
#15So, 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…
Re: You are dangerously bad at cryptography
#16A 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
#17Saying 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…
Re: You are dangerously bad at cryptography
#18* 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
#19Then 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
#20Saying 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…