Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

You are dangerously bad at cryptography

happybearsoftware.com

Post reply on HN
Print view View original

71–80 of 174 posts

Re: You are dangerously bad at cryptography

#71

Post by agwa »

megrimlock wrote: post #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…

Along the lines of of your examples, I would add distributed systems.

Still, cryptography is much, much worse than all these examples for a simple reason: with a sufficient amount of testing for functionality you can convince yourself that you've gotten things like concurrency correct, or at least correct enough that it won't be a problem most of the time. You can't do that with security - instead of testing for functionality you have to test for attack resilience, but whereas you know what functionality to test for, you can't test for attacks you don't know about. Furthermore, you can't be correct merely most of the time - you have to be correct all of the time, because if you slip up just once, your adversary will exploit you.

I really don't think there's any parallel.

Re: You are dangerously bad at cryptography

#72

Post by dakimov »

Very good point. I would extend it to security in general.

Security is like medicine: do not try it yourself, unless you are a specialist or want to end up dead.

Too bad a lot of developers still do not understand this and remain too self-confident, from what I personally have seen.

Re: You are dangerously bad at cryptography

#73

Post by mindcrime »

BrainInAJar wrote: post #58
jiggy2011 wrote: post #48

Earlier quoted context omitted.

Economics is also an excellent example. Nobody knows how to do it properly, even establishing direct cause and effect is basically impossible so we just iterate through progressively less broken solutions.

> so we just iterate through progressively less broken solutions. And then get all ideological about it and iterate back to more broken solutions (Chicago school)

And then get all ideological about it and iterate back to more broken solutions (Chicago school)

Or, even worse, Keynesianism.

Re: You are dangerously bad at cryptography

#74

Post by Filligree »

jimmaswell wrote: post #60

For the timing-based one, you I would've made the server wait a small random amount of time during the process. The xor is more clever, though.

Not the way a naive reading of your post suggests, no.

If you add a random amount of time, the timing attack still works; it averages out, the same way network jitter does. What you need to do is make every request take the same amount of time; randomness is not helpful here.

Re: You are dangerously bad at cryptography

#75

Post by jarrett »

tptacek wrote: post #62
jarrett wrote: post #53

This argument keeps coming up, and while its premises are valid, its conclusion never sits right with me, namely: "Don't use cryptography." That advice isn't practical for developers. There are plenty of systems we have to design where crypto is not optional. Examples: * Storing passwords. You can't store them in plaintext. * Signing requests (like in the OP's example). What are the alternatives? You can store some k…

Point by point: * Despite all the press password hashing gets, bad password hashes are rarely the worst mistakes people make in their applications. I'm glad there's a meme now about using bcrypt or scrypt, but I don't think people should be afraid to deploy password hashing. * The alternative to signed requests is to credential the requests directly and not build delegation features. Many applications that use signed…

> I don't think people should be afraid to deploy password hashing.

Neither do I, but the whole "don't use crypto" meme says the opposite.

> Just use HTTP Auth and a long random credential

Yes, that is a viable alternative. But it is also one which uses crypto. You're generating a random sequence, and you're using SSL. So once again you run up against the "don't use crypto" argument.

> You said it right here: just use random tokens to key a serverside session store.

But again, you've already introduced secure random number generators and SSL.

The point I was making with all these examples is that they are commonly encountered and can't be solved without crypto. Some of the solutions are easier to screw up than the others, and that's definitely worth talking about. But "don't use crypto" is too simplistic for these kinds of use cases.

Re: You are dangerously bad at cryptography

#76

Post by jimmaswell »

pcwalton wrote: post #46
megrimlock wrote: post #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…

Memory safety in memory-unsafe languages. We've had Valgrind and ASan for a while, and people still find crippling bugs in C and C++ code all the time. XSS vulnerabilities. Maybe Content Security Policy will help some here when it becomes ubiquitously available. Integer overflow. This is a particularly insidious problem because your well-formed test cases often won't catch it.

Here's a gem from an attempt to fix an integer overflow vulnerability in the PHP compiler:

if (size > INT_MAX) return NULL;

http://use.perl.org/use.perl.org/_Aristotle/journal/33448.ht...

Re: You are dangerously bad at cryptography

#77

Post by tptacek »

Note: we're still running these challenges:

http://www.matasano.com/articles/crypto-challenges/

The current standings are:

* level 0 (4362 players),

* level 1 (335 players),

* level 2 (123 players),

* level 3 (40 players),

* level 4 (21 players),

* level 5 (23 players),

* level 6 (32 players)

We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets.

The top languages finishers are using are (in order) Python, Go, Ruby, C/C++, C#, Clojure, and Haskell. People are also using Java, PHP, OCaml, Scala, Racket, Javascript, Common Lisp, Perl, Julia(!), erlang, Rust, Visual Basic, Groovy, ObjC, F#, Factor, Dart, and Microsoft Excel(!!!).

Re: You are dangerously bad at cryptography

#78

Post by dsl »

betterunix wrote: post #15
e1ven wrote: 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 fu…

http://nacl.cr.yp.to/

NaCl is well implemented cryptographic functions designed to be easy to use and fast. As opposed to something like OpenSSL that gives you nine million options, NaCl just does what is best.

Re: You are dangerously bad at cryptography

#79

Post by tptacek »

jarrett wrote: post #75
tptacek wrote: post #62

Earlier quoted context omitted.

Point by point: * Despite all the press password hashing gets, bad password hashes are rarely the worst mistakes people make in their applications. I'm glad there's a meme now about using bcrypt or scrypt, but I don't think people should be afraid to deploy password hashing. * The alternative to signed requests is to credential the requests directly and not build delegation features. Many applications that use signed…

> I don't think people should be afraid to deploy password hashing. Neither do I, but the whole "don't use crypto" meme says the opposite. > Just use HTTP Auth and a long random credential Yes, that is a viable alternative. But it is also one which uses crypto. You're generating a random sequence, and you're using SSL. So once again you run up against the "don't use crypto" argument. > You said it right here: just us…

Just accept the fact that people who say "don't use crypto" aren't saying "don't hash passwords", nor are they saying "don't generate random numbers", and move on.

Re: You are dangerously bad at cryptography

#80

Post by dsl »

tptacek wrote: post #77

Note: we're still running these challenges: http://www.matasano.com/articles/crypto-challenges/ The current standings are: * level 0 (4362 players), * level 1 (335 players), * level 2 (123 players), * level 3 (40 players), * level 4 (21 players), * level 5 (23 players), * level 6 (32 players) We're still donating $20 to PIH or Watsi for everyone who finishes all 6 sets. The top languages finishers are using are (in o…

Just curious how far the Excel hacker(s) got... Also, have you made any hires from the contest yet?
Post reply on HN