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

151–160 of 174 posts

Re: You are dangerously bad at cryptography

#151

Post by sbi »

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

The biggest candidate: * Pure mathematics: Consider e.g. the difficulty in verifying the recent proofs of Fermat's Last Theorem (Wiles-Taylor-Frey theorem?), the Poincaré conjecture (Perelman-Hamilton-Thurston theorem?), and now the ABC conjecture (Mochizuki-Szpiro theorem?): there is essentially no indication of the correctness of a mathematical proof besides simply having a whole lot of smart people look at it and…

Two notes: factoring polynomials over finite fields isn't hard (look up the Berlekamp algorithm or Cantor-Zassenhaus for starters). Second, I believe the system you've described doesn't satisfy your property (b). Quantities such as M[1]C[0] - C[1]M[0] + M[0]^2 and C[1]M[2] - C[2]M[1] + M[1]^2 - M[0]M[2] are congruent to 0 mod p; compute them over the integers and then take the gcd. By computing enough of these you should recover the prime p. Once you have p, recovering z is very easy (e.g., take the gcd of C and C'-M, where C' is the derivative of C).

Re: You are dangerously bad at cryptography

#152

Post by jarrett »

tptacek wrote: post #149
unethical_ban wrote: post #146

Earlier quoted context omitted.

You made it a semantic debate. "Don't use crypto." - you "That's terrible advice, we need crypto for x,y,z" "I don't really mean don't use crypto" "You just said that!" "You're just talking semantics."

Nobody dings developers for generating random numbers because they're "doing crypto".

Few do, but I genuinely thought that the OP was, so no semantic debate was intended :) (And I have actually seen people say that elsewhere.) While the OP didn't mention random numbers specifically, his prohibition on using crypto seemed general enough that I assumed it to include random numbers. Ditto for hashing. Certainly, his method of argument--describe the technique, show a vulnerability the reader might not have heard of--could be applied to both password hashing and random numbers.

I realize, however, that you have a more charitable interpretation of what the OP was suggesting. I think you and I mostly agree about the substantive issue: Crypto should be used, but as you said, developers owe it to users to make it work. My disagreement isn't with you but with the OP and others who seem to suggest tossing aside crypto because it's too hard to get right.

I just realized I haven't proposed a positive alternative to the "don't use crypto" meme, though. I honestly don't know what the answer is, I'm afraid. Realistically, lots of devs need to use crypto, and we can't all develop your level of expertise in that area. (The founder of a security consultancy will always know a lot more about security than generalist app developers. Only so much time in the day.) So becoming a true crypto/security expert can't be the solution, even if that would be the best one. The best realistic solution I can think of is for authors of crypto libraries to provide enough documentation that devs can use it safely.

Re: You are dangerously bad at cryptography

#153

Post by jarrett »

bigiain wrote: post #144
jarrett wrote: post #95

Earlier quoted context omitted.

Sure, but then what are they saying? "Dont use cryptography" is a quotation taken verbatim from the OP, and I've heard similar statements all around in the last few years. A reasonable person reading that statement would interpret it at face value: "Don't use cryptography" means that very thing. So what I'm suggesting is that the "don't use crypto" meme should go away and be replaced with something more helpful and m…

Isn't the actual meme "Don't build your own crypto", rather than "don't use crypto"? I remember at least 10 years ago getting (and seeing a lot) the advice "use SSL for data in transit, use GPG for data at rest". Those two principles, combined with the somewhat more recent "just use (b|s)crypt" for password hashes would still provide your average non-crypto-expert developer with a pretty good fundamental starting pla…

I've seen a fair amount of both.

The former ("don't build your own crypto") is clearly correct.

The latter ("don't use crypto") is what I disagree with. One example of this meme comes from the OP, who ends his article with: "Save yourself the trouble. Don't use cryptography. It is plutonium."

Re: You are dangerously bad at cryptography

#154

Post by jarrett »

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

> * Storing passwords. You can't store them in plaintext. Why not. Just write upfront on the signup form, "we don't hash or protect your passwords in any way. Do not reuse passwords from other sites. Create a unique password and retrieve it using a password manager." Password hashing is a losing battle: * the users who aren't educated enough to use unique passwords are the same ones who will always use a really weak…

> Just write upfront on the signup form, "we don't hash or protect your passwords in any way. Do not reuse passwords from other sites. Create a unique password and retrieve it using a password manager."

For one, I'd consider that bad business. If you want to make money, it's not a good idea to declare to users that your system is insecure.

More importantly, you're now putting all the responsibility on the user. Yes, it's good for users to think about security. Yes, it's impossible to 100% guarantee the security of your users' passwords. But disclaiming all responsibility? We're the ones with more technical knowledge, not our users. We should bear as much of the burden of security as we can.

> Password hashing is a losing battle

Your argument here seems to boil down to the idea that GPUs are now capable of cracking any password hashing scheme we have, assuming weak passwords. My understanding was that this was not the case, but perhaps I'm wrong. As far as I know, you can set the difficulty factor in Bcrypt high enough that it's impractical to crack on any commodity hardware. There's also scrypt, which is supposedly even stronger in this respect, although I don't know if it's been adequately vetted yet.

Re: You are dangerously bad at cryptography

#155

Post by lifeisstillgood »

kbaker wrote: post #118
lifeisstillgood wrote: post #34

I completely agree with this and have just released a session-cache for python that completely ignores encryption and just stores uuid in a cookie, and relies on server side lookups for session work.

Make sure you are using HTTPS exclusively so you aren't vulnerable to Firesheep-style attacks.

That's in the docs :-)

Re: You are dangerously bad at cryptography

#156

Post by lifeisstillgood »

kbaker wrote: post #118
lifeisstillgood wrote: post #34

I completely agree with this and have just released a session-cache for python that completely ignores encryption and just stores uuid in a cookie, and relies on server side lookups for session work.

Make sure you are using HTTPS exclusively so you aren't vulnerable to Firesheep-style attacks.

That's in the docs :-)

Ooops no it's not - kind of assumed it was obvious - thank you for the reminder :-)

Re: You are dangerously bad at cryptography

#157

Post by jarrett »

tptacek wrote: post #102
davidw wrote: post #93

Earlier quoted context omitted.

There's something that strike me as a bit off in what you write. I'm having trouble pinning it down, so here are some vague thoughts: * The world does need more crypto. There's market demand for keeping stuff safe/hidden/whatever. * It is hard to get crypto right. People like the author, and if I'm not mistaken, yourself, keep pounding that point home. Ok, we're convinced... but people still need to do this stuff, an…

The world might need more working crypto. The world doesn't need more broken crypto. Broken crypto isn't just a step on the path to working crypto; it's an opportunity for people to get hurt. The bet I'm making right now is that if people get a little bit of crypto literacy, they'll stop being so excited about deploying crypto in their applications. Implementing a bunch of crypto attacks has the effect of making you…

After having this debate with you two or three times now, I'm starting to realize that we both want the same thing: Good libraries like Keyczar that just do the right thing by default.

I would argue that there is a second side to the solution: Authors of more low-level crypto libraries (like OpenSSL) should very prominently warn users that said libraries are easy to misuse, and they should point users in the direction of the high-level libraries.

In my travels around the web, I've not often encountered such a warning. For example, as of today, the top Google hit for "ruby encrypt string" is a StackOverflow post. Its highest-voted answer advocates an OpenSSL wrapper.

Re: You are dangerously bad at cryptography

#158

Post by anonymouz »

scythe wrote: post #145
anonymouz wrote: post #122

Earlier quoted context omitted.

If I understood your proposed system correctly, the following seems to be a deal-breaking weakness: Given a number of polynomials representing encrypted messages, (x-z) is a common factor of all of them. The GCD of a set of polynomials can very efficiently be computed. Thus, an attacker observing different messages encrypted with the same key over time gets a better and better idea of what the key is (how quickly dep…

In this case, simply computing the GCD may require "non-obvious" intuition, since the polynomials do not act over the real numbers, but the algebraic closure of an unknown finite field. But I wouldn't bet my data on it, at least, not until I am a lot more confident in my understanding of abstract algebra.

Ah yes, I missed that the prime is part of the key.

Re: You are dangerously bad at cryptography

#159

Post by Dylan16807 »

alinajaf wrote: post #38
ams6110 wrote: post #31

I have implemented an MD5-based scheme similar to what was described. At the time, MD5/hash extension attacks were not as well-known as they are today, at least I had not heard of them and I read up on MD5 before I designed the sytem, so another worry is that what is considered secure today might not be secure tomorrow.

> another worry is that what is considered secure today might not be secure tomorrow If history is anything to go by then what is secure today will definitely be insecure tomorrow. No real solution to this AFAIK. If vulnerabilities in the crypto itself doesn't get you eventually, quantum computing will.

Quantum computers can only solve certain types of problems efficiently. Hashing is not generally in that set.

Re: You are dangerously bad at cryptography

#160

Post by MarkMc »

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

> * Storing passwords. You can't store them in plaintext. Why not. Just write upfront on the signup form, "we don't hash or protect your passwords in any way. Do not reuse passwords from other sites. Create a unique password and retrieve it using a password manager." Password hashing is a losing battle: * the users who aren't educated enough to use unique passwords are the same ones who will always use a really weak…

> Just write upfront on the signup form, "we don't hash or protect your passwords in any way"

Can you legally absolve yourself from all responsibility in that way? Say Toyota sell cars that explode when the engine is reved beyond the red line. If the sale contract says, "Toyota is not responsible if you do not follow the instruction manual" does that mean they cannot be sued?

Post reply on HN