On timing attacks; and other common misconceptions

[hmmueller]

In the chapter on hash functions, under "Password storage", there is the innocent remark about plaintext password storage: "Besides an obvious timing attack in the string comparison ..."

This timing attack is not at all obvious to us readers=newbies; and might, moreover, make a good example to debunk misconceptions about timing attacks - the most important being: "Ok, but the time differences because of matching different lengths of prefixes in chosen passwords [if this is the gist of timing attack - I'm just trying to do my first steps in understanding crypto problems!] will be enormously small, given the fact that a string comparison loop is usually running in a few CPU cycles - this will be drowned by the variances in all the other surrounding function calls that will take longer by orders of magnitude" - where the answer is (at least) - "Yes, but the duration of these other calls is statistically independent and hence can be removed by averaging over many attempts" - where the standard reply is - "Oh, then we add some more noise by adding a random delay" - with answer "This will not change the statistical independence" etc.

So, I think there should be some place where such basic ideas find their place. Maybe this could go together with

• something on the "secret algorithms fallacy" ("if we don't tell anyone how we decrypt, the encryption is much more secure")
• something on "multi-layered security doors" (if door 1 is cracked, there should be another door etc.) in some chapter on "Common ideas about security and their pitfalls"?

---

I just saw that there is a section on timing attacks in the appendix on side-channel attacks. Mhm. For me, the misconcepton problem - where the timing-attack-is-drowned-by-noise-fallacy is just one example - seems to be important enough to not put it in some appendix, but at some prominent position.

[lvh]

Yes, I definitely need to actually have a timing attack chapter there :) For some reason, I still feel uncomfortable throwing it in in any particular place (which is why it's now tentatively an appendix): a CBC bit flipping attack chapter obviously belongs with CBC mode, but there aren't any cryptosystems I can think of off the top of my head that can't (in principle) be subjected to side channel attacks.

As for a centralized place, I actually thought that some of these ideas would be bundled in a different book about actually designing secure software, but I do suppose they could go together in here :)

[lvh]

Here's the part I don't get: why is it not okay to mention that plaintext password storage is broken because of timing attacks? You suggested on the other PR that I should leave it out, reffing to this ticket, but I'm only seeing why I should explain timing attacks more, not why I shouldn't mention that timing attacks break straight password storage.

[hmmueller]

... my feeling was that because the explanation would take a little longer than 1 or 2 sentences, it would not be the right place here in a chapter on (cryptographic) hash functions. And because, as I see it, a separate text part on timing attacks would be nice anyway, that could well be explained there.

However, if introduced with something like "Before finding out why cryptographic hashing alone is not sufficient ...., let us take a short look at a timing attack against plaintext password storage.", a more or less short paragraph of explaining it is certainly ok (my goal only being that the reader - me :) - does not lose the overall plan of the text).