"This sequence is then folded using a compression function h(). The details of the h() depend on the hashing function, but the only thing that concerns us here is that the compression function takes two message blocks and returns another block of the same size."
So if the chunks in a SHA-1 hash are 512 bits each then surely the output of the hash function would be 512 bits rather than the 160 bit digest?
Edit: the IV is 160 bits , so "another block of the same size" means each derivative block is the size of the IV not of the actual data.
Stupid question: Whenever I've used GPG to sign an email, it includes a line saying "Hash: SHA1". Does this imply PGP-signed messages are vulnerable to this, or does PGP/GPG do something different/smarter?
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.
I'm not an IT guy, so no, I wasn't trolling. Why exactly is it "retarded" to build your system to reject (or at least flag) access patterns that are unlikely to be due to legitimate activity?
I'd recommend using the word "retarded" with a bit more circumspection. Obviously the incoming IP address doesn't uniquely identify a client who's likely to be on the other side of a NAT gateway. But the idea that a system should just sit there silently and carry on business as usual while any one address or class-C block generates large numbers of failed access attempts seems like a good application of the word in question.
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.
I'm not an IT guy, so no, I wasn't trolling. Why exactly is it "retarded" to build your system to reject (or at least flag) access patterns that are unlikely to be due to legitimate activity? I'd recommend using the word "retarded" with a bit more circumspection. Obviously the incoming IP address doesn't uniquely identify a client who's likely to be on the other side of a NAT gateway. But the idea that a system shoul…
You're not an IT guy, but you are a programmer, and you know that leaving a vulnerability in your code, hoping the devops team catches attempts to exploit it, is a fucking retarded idea. I think you're just trolling.
This seems to me like a variant of "do not trust the client." Good info though. I have learned a lot more about how hash algorythms work. I do wonder though if fixed-param hashes are relatively safe due to the inability to add suffixes.
"Never trust the client" is, like "always validate input", one of those timeless bits of security strategy that is worth pretty much nothing in the real world. It's about as useful as "pretty much you should always make sure you're secure, pretty much."
I'm not an IT guy, so no, I wasn't trolling. Why exactly is it "retarded" to build your system to reject (or at least flag) access patterns that are unlikely to be due to legitimate activity? I'd recommend using the word "retarded" with a bit more circumspection. Obviously the incoming IP address doesn't uniquely identify a client who's likely to be on the other side of a NAT gateway. But the idea that a system shoul…
You're not an IT guy, but you are a programmer, and you know that leaving a vulnerability in your code, hoping the devops team catches attempts to exploit it, is a fucking retarded idea. I think you're just trolling.
Who said anything about leaving a vulnerability in the code? If your security model depends on a suboptimal implementation of strcmp(), you have bigger problems than timing attacks.
This seems to me like a variant of "do not trust the client." Good info though. I have learned a lot more about how hash algorythms work. I do wonder though if fixed-param hashes are relatively safe due to the inability to add suffixes.
"Never trust the client" is, like "always validate input", one of those timeless bits of security strategy that is worth pretty much nothing in the real world. It's about as useful as "pretty much you should always make sure you're secure, pretty much."
I disagree with you here. One should always be sure input is validated somewhere before anything important is done with it. And not trusting the client is one element of what I call a "push security back" strategy (that strategy is, basically, don't do any security enforcement in your application you can't make a component further back do just as well. The reasoning here is that components like operating systems and web apps will always have more review and more eyes than your web app, so if they can work without trusting your app then all the better. Work from least privilege and design so that components further back can do things like authentication, authorization, and the like, to the extent this is practical. This creates a narrower security perimeter, and greater depth in defence. Of course, as in all things, security is a matter of perpetual tradeoffs.
You're not an IT guy, but you are a programmer, and you know that leaving a vulnerability in your code, hoping the devops team catches attempts to exploit it, is a fucking retarded idea. I think you're just trolling.
Who said anything about leaving a vulnerability in the code? If your security model depends on a suboptimal implementation of strcmp(), you have bigger problems than timing attacks.
I have no idea what you mean by "suboptimal implementation of strcmp".
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.
I'm talking about iptables rate limiting (on Linux and I assume other OS's firewalls can implement this). Fixing bugs in isolated code is part of the scope we face but preventing the business and its customers from suffering due to a bug is also part of we get paid for. If you are still in school or work in the scientific area then perhaps you have not come across rate limiting?
Fixing the leak today is admirable and difficult but challenging as the many comments have shown. The problem is that at any time regressions can and will happen. There was a problem on Ubuntu with SSH a couple of years ago, SSH had been fine then someone made a change (I don't recall the details) that went unnoticed for I think it was 2 or 3 years. That change made SSH vulnerable to I believe it was timing attacks and it could have been easily prevented. This was in SSH. SSH.
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.
I'm talking about iptables rate limiting (on Linux and I assume other OS's firewalls can implement this). Fixing bugs in isolated code is part of the scope we face but preventing the business and its customers from suffering due to a bug is also part of we get paid for. If you are still in school or work in the scientific area then perhaps you have not come across rate limiting? Fixing the leak today is admirable and…
No, the change you're thinking of is when Debian's maintainers managed to comment out the "secure" part of it's cryptographic secure random number generator, thus ensuring that SSH would only generate keys from a trivially small range of possible values. That change had nothing to do with the fundamental difficulty of generating random numbers.
The fix for not leaking timing from your comparison is trivial. Either double-hash, or use a timing-independent comparison function like the accumulator XOR function upthread.
It does nobody any favors to spread drama and FUD over what is in fact a simple and easily fixable problem.