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

81–90 of 103 posts

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

#81

Post by CamperBob2 »

tptacek wrote: post #24
jebblue wrote: post #21

>> This fact means that an attacker can determine the first correct character of the tag by submitting requests to a signed URL with a different first character in the tag each time, and stopping when the request takes a little longer than usual. After guessing the first character they can move onto the second, and so on until they’ve guessed the whole correct tag. Wouldn't this attack be eliminated by using iptables…

Wouldn't this attack be better eliminated by fixing the timing leak that is potentially allowing people to guess valid MACs on packets? The reality is that you probably can dick around with things in your deployment and your app to make timing attacks prohibitively expensive/annoying; if you understand that you're not eliminating the timing leak, but rather masking it, you can take advantage of the additional measure…

I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.

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

#82

Post by ma2rten »

tptacek wrote: post #67
ma2rten wrote: post #60

I was wondering about that timing attack. Is that really possible? How many requests would you have to make until you can get reliable statistics over the timing of a string comparison, when you have network delays, other requests and all kinds of stuff that influence timing?

It's very difficult, but possible. It's a plausible enough threat, especially if you're cloud hosted now or ever might be, that you should take steps to avoid it. Jitter and confounding are problems that can be addressed simply by repeated measurements. The rule-of-thumb from Crosby & Wallach's paper on remote timing attacks is, assume tens-to-hundreds of nanoseconds precision if you can colocate the attacker at the…

Thanks for your reply. I was totally oblivious to this type of timing attack before I read the article.

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

#83

Post by exit »

jcoglan wrote: post #48
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.

> "What if $EDGE_CASE_OF_INAPPROPRIATE_CRYPTO_FUNCTION" is never a good question to ask. Just use the right tools in the first place.

that's not an intelligent attitude.

understanding where an edge case breaks down is still illuminating, regardless of whether i use hmac in the end.

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

#84

Post by jcoglan »

cbsmith wrote: post #61
jcoglan wrote: post #44

Earlier quoted context omitted.

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 doe…

> 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. I'm with you except for: "a useless diversion". From the description in your article, I might…

Thanks for the suggestion in the last paragraph, very helpful.

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

#85

Post by gambler »

tptacek wrote: post #66
cjg wrote: post #36

Earlier quoted context omitted.

I've heard this said many times before and I agree. However, using crypto libraries does not solve the problem of vulnerabilities through cryptography misuse. For example, keys must be stored correctly, algorithms often need initialising in the correct mode for your specific application, IVs must not be repeated, and, as shown in this article, hashes should be used in specific ways to work correctly. There are many w…

This is the entire point of high-level crypto libraries, like Guttman's libcrypt and Google's Keyczar. So, yeah, don't use OpenSSL or javax::crypto or whatever .NET calls it; but, do consider using something like Keyczar, or, better yet, just use PGP/GPG to store data at rest, TLS for data in motion, and be done with it.

High-level libraries are definitely the way to go for a variety of reasons, but they don't replace understanding. Developers still need to understand what exactly is and is not guaranteed by cryptography involved, because that's the stuff protocols are build on. The root article is a great illustration of this.

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

#86

Post by seats »

tptacek or others with domain knowledge-

Is the timing attack hardening suggested in the blog post a standard approach?

If I was trying to attack a system and knew loosely that they did what he suggested (hashing then comparing vs comparing with timing exposed) , my untrained instinct would be that this is the weakest part. In other words I think this just makes the timing attack a little more difficult, but still possible, by producing specific hashes that carry out the timing attack.

When I've needed to harden comparisons against timing attacks, I've always just used constant time comparison functions, such as these ->

http://codahale.com/a-lesson-in-timing-attacks/ http://rdist.root.org/2010/01/07/timing-independent-array-co...

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

#87

Post by tptacek »

gambler wrote: post #85
tptacek wrote: post #66

Earlier quoted context omitted.

This is the entire point of high-level crypto libraries, like Guttman's libcrypt and Google's Keyczar. So, yeah, don't use OpenSSL or javax::crypto or whatever .NET calls it; but, do consider using something like Keyczar, or, better yet, just use PGP/GPG to store data at rest, TLS for data in motion, and be done with it.

High-level libraries are definitely the way to go for a variety of reasons, but they don't replace understanding. Developers still need to understand what exactly is and is not guaranteed by cryptography involved, because that's the stuff protocols are build on. The root article is a great illustration of this.

This is classic developerthink, and it's a good thing, but it doesn't serve you very well with crypto. The problem with crypto is that a partial understanding of the problems is actually worse than no understanding. You can be worse off learning crypto material than you were before you learned it.

If you're interested in picking up crypto knowledge, my advice is to do so in the context of breaking systems, not building them. I spend a lot of time doing crypto stuff, and I don't feel qualified to build them. But needing to figure out how to break all the random systems that end up on my desk has taught me a lot about crypto.

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

#88

Post by tptacek »

CamperBob2 wrote: post #81
tptacek wrote: post #24

Earlier quoted context omitted.

Wouldn't this attack be better eliminated by fixing the timing leak that is potentially allowing people to guess valid MACs on packets? The reality is that you probably can dick around with things in your deployment and your app to make timing attacks prohibitively expensive/annoying; if you understand that you're not eliminating the timing leak, but rather masking it, you can take advantage of the additional measure…

I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.

The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.

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

#89

Post by jebblue »

tptacek wrote: post #88
CamperBob2 wrote: post #81

Earlier quoted context omitted.

I guess the idea of just blacklisting the client's IP after the first 1,048,576 failed attempts is too boring, or has some other drawback.

The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.

Are you saying ip rate limiting is a bad idea?

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

#90

Post by tptacek »

jebblue wrote: post #89
tptacek wrote: post #88

Earlier quoted context omitted.

The idea of trying to detect people employing timing attacks on your cryptography and block them individually by IP address is so obviously retarded that the comment I'm replying to is indistinguishable from trolling.

Are you saying ip rate limiting is a bad idea?

I'm saying that trying to detect someone launching a timing attack on your application and then blocking their specific IP is a bad idea.

As to the rest of it: just fix the damn timing leak.

Post reply on HN