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, 08 Mar 2010 21:19:29 +0000 http://wordpress.com/ hourly 1 By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5504 Nate Lawson 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. 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-5503 Yuhong Bao Mon, 25 Jan 2010 07:40:09 +0000 http://rdist.root.org/?p=355#comment-5503 What about fast string ops? What about fast string ops?

]]> By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5485 Nate Lawson Wed, 06 Jan 2010 19:34:02 +0000 http://rdist.root.org/?p=355#comment-5485 Steve, adding noise does not make the attack impractical. Since the very nature of random noise is that it is equally distributed, it averages out if you take more measurements. The only solution is to use operations that do not have data-dependent variable timing. Steve, adding noise does not make the attack impractical. Since the very nature of random noise is that it is equally distributed, it averages out if you take more measurements.

The only solution is to use operations that do not have data-dependent variable timing.

]]> By: Steve Hurcombe http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5481 Steve Hurcombe Tue, 05 Jan 2010 14:28:02 +0000 http://rdist.root.org/?p=355#comment-5481 Hi Nate, This is very interesting. Now there may be a simpler way to avoid these attacks. If you added in a random delay you would surely add enough artificial noise to make the measurement impractical. This would then mask the inner workings of most algorithms regardless of how many separate paths there were. Best regards Steve Hi Nate,
This is very interesting. Now there may be a simpler way to avoid these attacks.

If you added in a random delay you would surely add enough artificial noise to make the measurement impractical. This would then mask the inner workings of most algorithms regardless of how many separate paths there were.

Best regards
Steve

]]> By: Nate Lawson http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5117 Nate Lawson Wed, 17 Jun 2009 18:16:42 +0000 http://rdist.root.org/?p=355#comment-5117 Dave, you're right that 32-bit compares are harder to attack. On average, you have to do 2^31 guesses before you hit the right one. And then, if your timing channel is at all noisy, you have to repeat them all again. As you note, it's hard to be sure what you've got until you really look at things from a low level. However, some situations like local attacks or slow embedded processors might still be vulnerable. Side channels really require careful threat modeling and low-level awareness. P.S. Care to include your email address? Dave, you’re right that 32-bit compares are harder to attack. On average, you have to do 2^31 guesses before you hit the right one. And then, if your timing channel is at all noisy, you have to repeat them all again. As you note, it’s hard to be sure what you’ve got until you really look at things from a low level.

However, some situations like local attacks or slow embedded processors might still be vulnerable. Side channels really require careful threat modeling and low-level awareness.

P.S. Care to include your email address?

]]> By: Dave http://rdist.root.org/2009/05/28/timing-attack-in-google-keyczar-library/#comment-5116 Dave Wed, 17 Jun 2009 10:28:36 +0000 http://rdist.root.org/?p=355#comment-5116 Some further comments after playing with Visual C++ and gcc's memcmp() a bit... gcc (for x86), despite claims on mailing lists to the contrary, appears to implement its memcmp() with a repe cmpsb even with optimisation enabled (seen via gcc -S -O2), so this should be vulnerable provided you can get precise timings. VC++, going all the way back to 6.0 from 1998, uses an optimised compare in which it compares 32-bit quantities as much as possible using repe cmps and then fixes up the leftovers at the end of the loop manually (with all sorts of special-case handling for alignment and odd-length quantities and the like, the code is quite convoluted and since all I have is a disassembly I'm having to guess at the reasons for some of this, which looks like a lot of hand-tuned P5 pipelining optimisation). For multiple-of-32-bit data values like an HMAC compare you're getting 32-bit compares in a tight loop, so any non-prehistoric Windows code at least would appear to be immune to the guess-a-byte timing channel because the granularity level is 32 bits and not 8. Thanks for the PDF links. Some further comments after playing with Visual C++ and gcc’s memcmp() a bit…

gcc (for x86), despite claims on mailing lists to the contrary, appears to implement its memcmp() with a repe cmpsb even with optimisation enabled (seen via gcc -S -O2), so this should be vulnerable provided you can get precise timings.

VC++, going all the way back to 6.0 from 1998, uses an optimised compare in which it compares 32-bit quantities as much as possible using repe cmps and then fixes up the leftovers at the end of the loop manually (with all sorts of special-case handling for alignment and odd-length quantities and the like, the code is quite convoluted and since all I have is a disassembly I’m having to guess at the reasons for some of this, which looks like a lot of hand-tuned P5 pipelining optimisation). For multiple-of-32-bit data values like an HMAC compare you’re getting 32-bit compares in a tight loop, so any non-prehistoric Windows code at least would appear to be immune to the guess-a-byte timing channel because the granularity level is 32 bits and not 8.

Thanks for the PDF links.

]]>