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

91–100 of 174 posts

Re: You are dangerously bad at cryptography

#91

Post by objectivefs »

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…

If you have a crypto heavy app I recommend the fast and easy to use correctly NaCl project.

http://nacl.cace-project.eu

Re: You are dangerously bad at cryptography

#92

Post by tptacek »

im3w1l wrote: post #24
alinajaf wrote: post #8

Earlier quoted context omitted.

Hi, author here, I'm glad you found it useful! > I didnt know for example that you can basically extend an MD5ed string and keep the original MD5 value Thank tptacek for that knowledge, I think I picked it that up in a talk he did that's somewhere on Vimeo (will link to it). > Then again, I know that MD5 isn't a secure cryptographic hash function so I wouldn't have used it from the start. Nice to know why thats the c…

> It's because of the internal mechanism (a "Merkel Damgard Construction") intrinsic to hash functions like MD5, SHA1, SHA256 and friends. Even if MD5 were cryptographically secure, this vulnerability would still present itself if used in the way I described. Thanks for pointing that out, didn't know that. Just for fun, if they had written message+secret instead of secret+message it would have been ok (although bad p…

Secret suffix MACs are insecure if your hash function isn't collision-resistent. To illustrate: MD5 isn't collision-resistent, but HMAC-MD5 has no currently known viable attacks, because it isn't simple a secret-suffix MAC.

So it's true that using a secret-suffix MAC is safer than using a secret-prefix MAC, but if you know enough to make that choice, you know enough to use HMAC.

Re: You are dangerously bad at cryptography

#93

Post by davidw »

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

The world needs more broken crypto like a dissident strapped to a chair in a concrete cell in South America needs another car battery alligator clipped to their fingers. How about, if the world really needs more cryptography, the people who bring it to us take the time to become just a little bit literate in how crypto is actually attacked, instead of pretending like they understand it just because they were able to…

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, and not all of us have the money to hire you.

* "just a little bit literate ", given the above, seems kind of dangerous, no? It seems that way to me. Why bother learning just enough to get yourself into trouble?

* Given the above demand, people are going to try this stuff one way or the other. It seems the best thing is to give them the safest building blocks. The cited example in the article seems indicative: the companies were all trying to do more or less the same thing, which was not something complicated. Why wasn't it easier for them to do the right thing?

* I think what the world needs is easier, clearer, proven open source solutions/recipes to common problems.

Also, another thought that is not related to you or what you wrote, or write: is it just me or do a lot of security discussions turn into dick waving contests? Why is that?

Re: You are dangerously bad at cryptography

#94

Post by wzdd »

tptacek wrote: post #87
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!

MD4, MD5, SHA1, and all the SHA2 variants use a structure called Merkle Damgard, which does include the message size. Most are vulnerable to length extension attacks. SHA3 (Ketchup) is not vulnerable to length extension attacks, because resistance to length extension was a design criteria for the SHA3 contest. Edit: Doh, SHA2-224 and SHA2-384 are truncated and aren't vulnerable

Thanks, I looked up Merkle Damgard now understand the comments about padding and how they would affect things.

But I was specifically thinking of the following scheme:

Message: [length][key-value pairs]

Hash: MD5 (shared secret, message)

Assuming that the rule is: the length is at the start of the message, and only "length" bytes of the message are used after the hash check passes.

It seems that if you have found a hash collision, Merkle Damgard lets you find more collisions easily. But the exploit in the article doesn't require a hash collision. If you haven't found a hash collision, would the above scheme be vulnerable to length extension?

Re: You are dangerously bad at cryptography

#95

Post by jarrett »

tptacek wrote: post #79
jarrett wrote: post #75

Earlier quoted context omitted.

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

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 more specific. For example, the responses you've given on this thread have been both helpful and specific. I'm arguing that people should say the kind of stuff you've said, rather than the unrealistic "don't use crypto."

Re: You are dangerously bad at cryptography

#96

Post by tptacek »

wzdd wrote: post #94
tptacek wrote: post #87

Earlier quoted context omitted.

MD4, MD5, SHA1, and all the SHA2 variants use a structure called Merkle Damgard, which does include the message size. Most are vulnerable to length extension attacks. SHA3 (Ketchup) is not vulnerable to length extension attacks, because resistance to length extension was a design criteria for the SHA3 contest. Edit: Doh, SHA2-224 and SHA2-384 are truncated and aren't vulnerable

Thanks, I looked up Merkle Damgard now understand the comments about padding and how they would affect things. But I was specifically thinking of the following scheme: Message: [length][key-value pairs] Hash: MD5 (shared secret, message) Assuming that the rule is: the length is at the start of the message, and only "length" bytes of the message are used after the hash check passes. It seems that if you have found a h…

The attack has nothing to do with hash collisions; it has to do with the fact that the MD-structured hashes spit out their entire state at the end of the operation, which means an attacker can simply reformat the hash back into the hash core's state and continue hashing with it.

Re: You are dangerously bad at cryptography

#97

Post by wzdd »

tptacek wrote: post #89
[deleted] wrote: post #82

Earlier quoted context omitted.

[deleted]

The attacker doesn't "update" the length. The attacker appends data to the message, which has the effect of turning the previously stamped message length into just another bunch of bits in the middle of the message, and then includes their own message length at the end. The final message must accurately represent the length of the original message including the shared secret, so there's trial and error involved, but…

Yes, sorry for deleting a comment when there was a reply! For posterity, it was something like: "it seems like you would need to break MD5 in order to do this, because you'd have to update the length."

Re: You are dangerously bad at cryptography

#98

Post by papsosouid »

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…

When you undo the C and C++ merger, how does the list look? They are very different languages, in particularly in that they attract very different people, so it is interesting to know which is actually being used rather than "C/C++".

Re: You are dangerously bad at cryptography

#99

Post by daeken »

tveita wrote: post #69
wulczer wrote: post #9

Earlier quoted context omitted.

Doesn't matter if it's MD5 or SHA512. You can extend either hash function in the exact same way ( http://en.wikipedia.org/wiki/Length_extension_attack )

It does matter what hash function you use, though. MD5 and SHA-512 are both vulnerable to length extension, but there are other hash functions that are not, like SHA-512/256, SHA-3 or BLAKE. The documentation for both Keccak and BLAKE2 recommend prefixing a fixed-length key to the message to do MAC, pretty much like in the vulnerable example, but with a better hash function.

> other hash functions that are not, like SHA-512/256

I think you meant SHA-224/384. Both SHA-512 and -256 are vulnerable to length extension because their internal state is dumped and resumable. With SHA-224/384, you only get a truncated state (from 256- and 512-bits respectively), which you can't pick up and resume.

Re: You are dangerously bad at cryptography

#100

Post by wzdd »

tptacek wrote: post #96
wzdd wrote: post #94

Earlier quoted context omitted.

Thanks, I looked up Merkle Damgard now understand the comments about padding and how they would affect things. But I was specifically thinking of the following scheme: Message: [length][key-value pairs] Hash: MD5 (shared secret, message) Assuming that the rule is: the length is at the start of the message, and only "length" bytes of the message are used after the hash check passes. It seems that if you have found a h…

The attack has nothing to do with hash collisions; it has to do with the fact that the MD-structured hashes spit out their entire state at the end of the operation, which means an attacker can simply reformat the hash back into the hash core's state and continue hashing with it.

I didn't think so, but I mentioned it because the Wikipedia article on Merkle-Damgård hashes (http://en.wikipedia.org/wiki/Merkle–Damgård_construction) talks about length extension attacks only in the context of hash collisions: "Length extension — once an attacker has one collision, he can find more very cheaply."
Post reply on HN