Comments on: Timing attack in Google Keyczar library http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/ Embedded security, crypto, software protection Mon, 06 Feb 2012 20:16:28 +0000 hourly 1 http://wordpress.com/ By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5939 Wed, 11 Aug 2010 21:03:45 +0000 http://rdist.root.org/?p=355#comment-5939 Unlike local timing attacks where you have to worry more about cache, branch prediction cache, etc., remote timing attacks are easiest to avoid by using a simple constant time loop. More complicated countermeasures are more likely to fail.

]]> By: Travis H. http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5937 Wed, 11 Aug 2010 19:06:38 +0000 http://rdist.root.org/?p=355#comment-5937 Hey Nate,

Regarding Steve Hurcombe’s comment, I wonder if you had heard of anyone injecting a delay, not random, but based on a function of the user-selected guess and a secret value. It seems that the function computation could be potentially expensive, but it would be simpler to implement in some cases than constant-time algorithms. Example, much simplified for didactic purposes:

…do comparison…
sleep(HMAC(user_supplied_guess, secret_delay_key))

Described among possible counter-measures here:
http://www.subspacefield.org/security/security_concepts/index.html#tth_sEc31.2.4

Another idea, off the top of my head, would be to hash the two values before comparison, so knowing how many octets were identical doesn’t help you much – you find out about the hash of the correct value, but preimage resistance prevents you from learning about the correct value.

I throw these out there as ideas because DJB makes me skeptical of my ability to write truly constant-time code. :-)

]]> By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5789 Thu, 08 Apr 2010 22:36:25 +0000 http://rdist.root.org/?p=355#comment-5789 Every call to “==” is a branch. So you will reveal the timing difference of whether or not the branch is taken on each character. This is actually easier to attack than “terminate early” behavior since it allows you to test a number of possibilities in parallel.

]]> By: Aahz http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5783 Mon, 05 Apr 2010 22:32:22 +0000 http://rdist.root.org/?p=355#comment-5783 I’m curious why this loop isn’t used, it would be a lot faster because
of avoiding the function calls:

for x, y in zip(correctMac, sig_bytes):
result += (x == y)

Assuming I understand correctly, this should not result in a timing
difference until you have a digest that’s bigger than two gigabytes.

]]> By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5504 Wed, 27 Jan 2010 05:41:55 +0000 http://rdist.root.org/?p=355#comment-5504 I assume you’re referring to the x86 string instructions such as “rep cmpsd”? They still terminate early so there is a timing difference. It will be very small, but you have to consider the attacker’s vantage point. It still may be exploitable and is highly dependent on the security model.

]]> By: Yuhong Bao http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/comment-page-1/#comment-5503 Mon, 25 Jan 2010 07:40:09 +0000 http://rdist.root.org/?p=355#comment-5503 What about fast string ops?

]]>