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

Why you should never use hash functions for message authentication

blog.jcoglan.com

Post reply on HN
Print view View original

41–50 of 103 posts

Re: Why you should never use hash functions for message authentication

#41

Post by klodolph »

jcoglan wrote: post #9
klodolph wrote: post #6

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

You can compare success versus failure.

Success: check authentication, process data, commit, return 2xx status.

Failure: check authentication, return 4xx status.

The reason that you don't get any information from the difference in timing between the two branches is because you already get that information from the status code.

Now on the other hand, if you use naive string comparison, different failure branches will take different amounts of time. That is a security hole, and it's not what we're talking about here.

Re: Why you should never use hash functions for message authentication

#42

Post by Ralz »

I e-mailed visa about something similar with their new upcoming V.me service. They suggest that you use md5 to generate the tag which is known to be weaker than SHA-1. I was a little surprised that a company like Visa would mess up on crypto and not know to use HMAC instead of just a simple hash. Never heard a response from them either.

Here's what their documentation says:

Language Standard Syntax for Generating MD5 Hash Java import org.apache.commons.codec.digest.*; hash = DigestUtils.md5Hex(string1+string2+string3...); PHP $hash = md5($string1.$string2.$string3...); Ruby require 'digest/md5' hash = Digest::MD5.hexdigest(string1+string2+string3...) Python import md5 hash = md5.new(string1+string2+string3...)

Re: Why you should never use hash functions for message authentication

#43

Post by more_original »

tomp wrote: post #40
more_original wrote: post #31

Earlier quoted context omitted.

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.

Not according to http://news.ycombinator.com/item?id=4089076 (SHA1 appends the length of the original message to the message).

Well, if you have an internal collision hash(m1)=hash(m2) and both messages m1 and m2 are of the same size, then it seems that one would also get hash(m1|key|size) = hash(m2|key|size). So, I cannot really see how appending the size will help.

(All subject to optimistic assumptions about block sizes, etc.)

Re: Why you should never use hash functions for message authentication

#44

Post by jcoglan »

cbsmith wrote: post #35

This is a great essay on why you should never use a hash function for message authentication. 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 probl…

Your point about padding and length bytes is spot-on. I actually left this out of the explanation, although it's interesting, because I felt it a useless diversion: something that's safe except in an easily describable subset of cases is still not fit for purpose when specially designed tools without these problems exist.

Point being, although hash functions might work most of the time, their general construction does not make them safe for this purpose. You can't say something is 'mostly secure' because it works 'most of the time'. The times is doesn't work will affect someone, and for them the system is not secure at all.

Plus, implementations with weird edge cases make for horrible debugging, especially when it comes to security.

Re: Why you should never use hash functions for message authentication

#45

Post by tomp »

more_original wrote: post #43
tomp wrote: post #40

Earlier quoted context omitted.

Not according to http://news.ycombinator.com/item?id=4089076 (SHA1 appends the length of the original message to the message).

Well, if you have an internal collision hash(m1)=hash(m2) and both messages m1 and m2 are of the same size, then it seems that one would also get hash(m1|key|size) = hash(m2|key|size). So, I cannot really see how appending the size will help. (All subject to optimistic assumptions about block sizes, etc.)

In this sense, every hash function is equally unsafe, even HMAC.

Re: Why you should never use hash functions for message authentication

#46

Post by tptacek »

quotemstr wrote: post #34
tptacek wrote: post #23

Earlier quoted context omitted.

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

There's nothing wrong with Applied Cryptography so long as you _understand_ it. If you blindly apply outdated algorithms, yes, you lose. Everyone should read both Applied Cryptography _and_ the other books you mentioned, and keep up on the literature besides.

No, there's a lot wrong with _Applied Cryptography_, and those things have very little to do with the fact that AC writes about IDEA and not AES.

If you read _Practical Cryptography_, you don't need to read _Applied Cryptography_. AC is a book full of trivia, and of encyclopedia-style descriptions of random block ciphers with minimal attention given to the actual real-world attacks on implementations of those ciphers.

I strongly advise that you not waste time reading AC. If you're lucky, you can read it and just lose time; if you're unlucky --- and a lot of my clients have been --- you can find yourself having learned stuff you'll later need to unlearn.

Re: Why you should never use hash functions for message authentication

#47

Post by tptacek »

cbsmith wrote: post #35

This is a great essay on why you should never use a hash function for message authentication. 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 probl…

In practice, attackers just guess the bit length of the message by writing the Ruby script that generates the 100 candidate messages at different expected bit lengths and feeding them to their fuzzer. The bit length issue is not a real one in practice.

In practice, length-extendable SHA-1 MAC functions are mechanically exploitable; they'll be discovered quickly by competent attackers who don't even have access to your source code, because attempts to break them require very little code and even less time.

It is a very, very bad idea to put off fixing a problem like this because you've been led to believe by someone on a message board that MD padding is going to be an obstacle to attackers. It isn't. The Flickr MAC break required MD padding, too; Thai and Juliano broke it just the same.

Re: Why you should never use hash functions for message authentication

#48

Post by jcoglan »

exit wrote: post #26

what's wrong with hashing (message + secret) instead?

Relying on the way you happen to combine data, instead of using a function that's designed for authentication and has baked-in a safe way to combine the inputs, is a bad idea. "What if $EDGE_CASE_OF_INAPPROPRIATE_CRYPTO_FUNCTION" is never a good question to ask. Just use the right tools in the first place.

Re: Why you should never use hash functions for message authentication

#49

Post by jcoglan »

Ralz wrote: post #42

I e-mailed visa about something similar with their new upcoming V.me service. They suggest that you use md5 to generate the tag which is known to be weaker than SHA-1. I was a little surprised that a company like Visa would mess up on crypto and not know to use HMAC instead of just a simple hash. Never heard a response from them either. Here's what their documentation says: Language Standard Syntax for Generating MD5…

Dear Christ just kill me already.

Re: Why you should never use hash functions for message authentication

#50

Post by pbsd »

cbsmith wrote: post #35

This is a great essay on why you should never use a hash function for message authentication. 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 probl…

"Never use a hash function for message authentication" is such a simplistic view. The author takes a common hash function design (Merkle-Damgard), and somehow extrapolates that hash functions should be simply ruled out for authentication.

First, this may send the wrong message to the less-focused reader: "what, I should use block ciphers instead?". Luckily, HMAC is eventually brought up, which is a fine solution.

HMAC requires 2 calls to H, our favorite hash function. Certain applications may find the overhead to be prohibitively high. With non-broken hash functions (e.g., any of the SHA-3 finalists), we can use the so-called envelope authenticator: A = H(K||M||K), with some padding to separate K from M to keep security proofs happy. This is significantly faster for short messages, and short is the most common size out there.

Post reply on HN