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

51–60 of 174 posts

Re: You are dangerously bad at cryptography

#51

Post by Strilanc »

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…

- Relying on undefined or implementation-specified behavior. Problems only show up years down the road. (example issue: expecting signed overflow to wraparound in C)

- Avoiding statistical biases when transforming random values. Statistical unit tests are hard. (example issue: shuffling via lots of uniformly random swaps)

- Integer overflow ruining algorithms that would be correct, given unbounded integers. (example issue: average = (a+b)/2)

Re: You are dangerously bad at cryptography

#52

Post by jdbernard »

wzdd wrote: post #41

I'm just curious: the obvious response to the first problem (message extension attack) is to include the message length in the message. If this wouldn't work, could an expert please tell me why? Edit: To be specific, I was thinking of a Pascal-style length-at-start arrangement. It's clear that if you put the length at the end you may be vulnerable to exactly the same attack!

The attacker just needs to include the updated length, which he can likely calculate since the shared secret is probably the same length for all accounts-even if it is not he only needs it for this request--and he knows the length of the parameters and their values. It would take some guesswork and trial and error to nail it down, and the attacker would have to guess that the length was included in the first place. Assuming he has plenty of time and processing power it is not infeasible. There are a lot of fairly easy things you could add to make it more difficult to attack.

Re: You are dangerously bad at cryptography

#53

Post by jarrett »

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 kind of authentication in the cookie, which then gets sent with each request. You can use HTTP auth. But in any scenario, you're definitely using SSL, and you're probably using some other kind of crypto on top of that.

* Encrypting cookies. You should store as little as possible in cookies--ideally just a single identifier. But even so, it's very important to make cookies tamper-resistant. You can't, e.g. just have a plaintext cookie that says "userid=42."

So what does the OP propose we do? If this article were making the usual case that we shouldn't implement our own crypto algorithms, I'd agree 100%. But he seems to be taking it a step farther, and saying we shouldn't even use existing crypto libraries, because we'll misuse them. But what are the alternatives?

Re: You are dangerously bad at cryptography

#54

Post by StavrosK »

jiggy2011 wrote: post #44

I would break the levels of crypto knowhow down thusly: 1) End user level: You want to buy things online, you should know to check for the padlock icon. 2) Deployment level: You run an online shop using an off the shelf eCommerce system. You should buy an SSL cert and know how to install it on your web server of choice. You should also know the difference between a public and private key (and hence why you should nev…

> I would guess that most developers should stay at around level 2 as much as possible, delving into level 3 only when required and never further.

Why would you advocate that people stay away from learning cryptography? They should know as much as possible, they just should avoid implementing it.

Re: You are dangerously bad at cryptography

#55

Post by StavrosK »

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…

There aren't any, learn how the libraries work and use them. I agree with your point, in that respect.

Also, about the cookies, you can definitely have a plaintext cookie saying userid=42, as long as it's signed.

Re: You are dangerously bad at cryptography

#56

Post by StavrosK »

venomsnake wrote: post #49

Few thoughts - why MD5 in the example at all? I thought that SHA-2 was the go to for hash functions nowadays. And a question on the timing attack - how real it is? Because in the response time you have a lot of random variables which with the current fast servers will take more time than the calculation itself. You receive request - how fast it will go trough the loadbalancer is random, then you must read the shared…

With thousands of tries, you can apparently average the noise out pretty effectively, so timing attacks are very possible.

Re: You are dangerously bad at cryptography

#57

Post by Dylan16807 »

venomsnake wrote: post #49

Few thoughts - why MD5 in the example at all? I thought that SHA-2 was the go to for hash functions nowadays. And a question on the timing attack - how real it is? Because in the response time you have a lot of random variables which with the current fast servers will take more time than the calculation itself. You receive request - how fast it will go trough the loadbalancer is random, then you must read the shared…

State of the art multiple years ago was 100ns over LAN (aka datacenter). It's something to worry about. Honestly, I'd be extra paranoid and use a construct that hashes the supplied digest an extra time on top of doing a timing-safe comparison.

Re: You are dangerously bad at cryptography

#58

Post by BrainInAJar »

jiggy2011 wrote: post #48
LaGrange wrote: post #40

Earlier quoted context omitted.

Outside of computing: health and diet. Sure, you get some feedback, but you also can screw up things in some ridiculously slow-acting way. Pharma companies (are supposed to) monitor drug use for decades after introduction for the same reason. Construction. Just build that chunk out of two steel beams instead of one, and witness it work perfectly until someone decides to throw a party on that balcony. Or witness your…

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)

Re: You are dangerously bad at cryptography

#59

Post by scg »

> Measure the time each request takes to complete. Since string equality takes a tiny bit longer to complete when the first char matches, the message that takes the longest to return will have the correct first character.

Always wondered if this really works in practice ...

I imagined the time it takes to compare 2 strings should be negligible / indistinguishable in a full HTTP request over the wire. Among all the other things happening in the network stack, OS, Rails, HTTP, database access, and everything else you're doing in your request, a string comparison of a few dozen characters should be well within the noise range.

I've Googled around and it seems like it really is a viable attack:

http://www.cs.rice.edu/~dwallach/pub/crosby-timing2009.pdf

> We have shown that, even though the Internet induces significant timing jitter, we can reliably distinguish remote timing differences as low as 20µs. A LAN environment has lower timing jitter, allowing us to reliably distinguish remote timing differences as small as 100ns (possibly even smaller). These precise timing differences can be distinguished with only hundreds or possibly thousands of measurements.

#mindblown

Post reply on HN