Hacker News new | past | comments | ask | show | jobs | submit login

This is sort of classic problem. First, you need to assume the attacker is capable of measuring checkMac's runtime reliably. Second, you also need to assume the attacker is able to control the message and the mac, but not the secret. How the attacker got there is not really relevant, the point is figuring out whether or not the system is possible to crack by having the attacker full knowledge of everything, but the secret.

In most languages, a similar implementation of checkMac would not pass the test, because they will usually implement some sort of short-circuiting. Which essentially means that checkMac will take longer to execute the closer you get to the true mac of that message.

Let's say computeMac(secret, "a") == "a21a". The attacker could pass in message="a" mac="0000" at first. Let's say that takes 1 unit of time, because "0000" == "a21a" only has to look at the first character. So the attacker knows that 0 is wrong. They then try "1000", then "2000", up until they get to "a000". Then, the algorithm takes 2 units of time, the first one is comparing '0' == 'a' and the second one is '0' == '2'. Now the attacker knows the first character of the mac. They keep going like this until they find out the entire mac of the message. In a nutshell, the time the function takes to execute leaks informartion that an attacker could use.

In this language, when you do use the secret(string) type, it will always compare all the characters of the string, even after it knows it will be false anwyay, just to make sure no information is leaked.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: