31–40 of 103 posts
what's wrong with hashing (message + secret) instead?
In order for an extension attack, wouldn't the blocks have to align perfectly? Like suppose I hash [abcd][efgh][k] How would you extend that?
Your hash construction will pad out your data to be multiples of the right size. That padding can be verified in some way - often it is all nulls, or encodes the length of the message. http://en.wikipedia.org/wiki/Merkle%E2%80%93Damg%C3%A5rd_con...
Earlier quoted context omitted.
You can learn all that and more just by reading Applied Cryptography.
People that build crypto after reading Applied Cryptography are doing a fine job paying for my kids college education, so I agree with you and encourage everyone to do likewise. If you don't happen to like my kids, well, first, screw you, and secondly: buy _Practical Cryptography_ or _Cryptography Engineering_ (really the same book) and burn your copy of "Applied".
Except not for the reason the author thinks.
There are several problems here.
First, with SHA-1 for example, you have 64 bytes per chunk. That means you basically get a free ride on this problem for anything Secondly, unless a message ends right on the 64 byte boundary, it is not nearly that simple. You have a bit of a problem, because the hash is padded, and when you add extra characters to your original string, that padding gets replaced with those values. So, it's no longer simple to just "keep going" from where you stopped.
Still, you can see how that leaves a distinct subset of cases where you'd be exposed. SHA-1, along with most secure hash functions, appends the length of the message the end of the source text before performing the hash function. That means that if you add even one byte to the string, you have now changed the last 8 bytes that were fed in to the "original" hash function. Oh, and your extra byte goes in before those bytes, so not only did you change those 8 bytes, but you shifted them down a byte.
So, no, it isn't nearly that easy to crack a SHA-1 based authentication, and yet, it is easy enough that you should totally NOT use them for authentication and instead use HMAC ; they are vulnerable to extension attacks, it's just not nearly as easy as this article suggests, and conclusions one might draw from this article (like you can solve this problem by feeding all source text in to the hash algorithm backwards) are likely ill founded.
It just turns out that cryptography is way more complicated, and even in terms of understanding weaknesses that arise from doing things wrong, you are going to get it wrong. Trust the experts, when they say it is a bad idea, but don't assume why it is a bad idea can be explained in a short blog article like this.
UPDATED: Added an explanation as to why it might be dangerous to just take this article at its word.
Number one thing I learned from the Coursera class: don't build your own crypto.
There are many ways to fail with cryptography and avoiding them all takes considerable expertise. Using crypto libraries does not solve this problem.
For the string comparison, could you really use that in a timing attack. Wouldn't the difference between comparison taking one char longer be measured in nanoseconds, while the overall network lag would be milliseconds?
> The easiest way to defeat this attack is, instead of directly comparing two strings, compare their mappings under a collision-resistant hash function. Is this really the best way to compare strings without giving away timing info?
No. It's A way to do it, but not the fastest or the simplest. An easier, faster way to do it is what Rails does (after Nate Lawson via Coda Hale told them how): accumulate the XORs of each offset of both strings and then verify that they add up to zero.
> Finally, you should make sure your application does not exit early if the tag is invalid. You should do all the data processing you would normally do, just short of modifying the database, and check the tag last. If you return early you risk another timing attack. What kind of timing attack is that? In order for there to be a timing attack, there has to be a difference in the timings. 1. You can either process the…
The timing attack is if you check the tag, that fails, and then you don't do any further request processing. This shortens the request time. It depends quite a lot on what you're actually doing with the message, but in general you want to leak as little info as possible about what's happening during any crypto-related process.
The only good thing that "authenticating last" does is that it prevents the attacker from issuing lots of requests sequentially, thus brute-forcing your authentication, but this should be solved in another way, without slowing down legitimate users and overloading your servers.
what's wrong with hashing (message + secret) instead?
For example, if you already happen to know a collision hash(m1)=hash(m2), where m1 and m2 have full block size, then you also get a collision hash(m1|key)=hash(m2|key), just as explained in the article. So, one could forge messages, which should clearly be counted as a weakness, even if it assumes knowledge of a collision.