Defence against timing attacks

Question

I know this is a difficult subject but would a good defense against timing attacks be not sending a message if the decryption or authentication fails? So if the attacker provides a wrong HMAC for example and this is compared and found to be false you simply return nothing to the attacker (this is considering a network environment though i do not want to limit it to a network environment)

Are there other ways to defend against timing attacks? I've found papers like this (free PDF) and this (free PDF). The later one seems to be a proposal to change AES to help it prevent feasibility of timing attacks, I don't think I should just go ahead and implement it my self.

All these papers are great but they are such a long read and to be honest sometimes they just loose me. So are there any real life implementation examples against timing attacks? I'd prefer these examples to work on any cipher but cipher specific would be good as well.

I should note I've found some answers on this topic: like this one AES-timing-attacks but again the answer (as it is everywhere) is: take the worst possible time and make it last that long. this, for implementations, just isn't a feasible way to go is it?

TL;DR

1. is simply not returning a message when something failed to decrypt or authenticate a viable option?
2. are there other good implementations against timing attacks.

Answer 1

No, because timing attacks don't really have anything to do with errors. A timing attack means analyzing the time it takes a cryptographic operation to complete leaks secret information. That actually has nothing to do with error messages; it's just as much a timing attack to look at how long it takes the server to decrypt something in a CTR mode (where the AES primitive is run on publicly known plaintext with a secret key) by measuring delay between messages, to get information about the key. On the flipside, there are very good reasons to return an error if something goes wrong -- it means the message needs to be re-sent, because you don't know if it was corrupted in transit or if there was a problem with the message itself.

Now, there are attacks that have to do with being able to learn that there was an error in the message; the POODLE attack against TLS was one such attack, where learning that the padding was bad told the attacker valuable information about the plaintext. That may be what you're thinking about in terms of error messages, and one part of a remedy may be to not send detailed error messages (the real remedy is to use a message integrity mechanism to protect the plaintext, so an attacker can't pull a chosen-ciphertext attack). But timing attacks have little to do with this.

The way to defend against timing attacks is to make sure the time taken to execute cryptographic operations does not depend on any secret information. It can depend on key length or message length, because that's not generally considered secret; it must not depend on the actual value of the key, or the contents of the message. This is more complicated than just doing constant-time compares and the like; you also need to worry about other factors (like caching) that you don't directly control but nevertheless affect the time to run the operation (this is one of the advantages of direct hardware implementation of crypto: it's easier to control timing when you have the total control over execution that only Intel or AMD engineers have).