openssh unix dev - Oct 2001 - [Fwd: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2]

Nicolas,

The timing attack described in the paper by Dawn Song et al. works by
examining the timing of keystrokes.  Currently OpenSSH sends a packet
every time you press a key, thus it is possible to capture the
approximate inter-keystroke timing of a user (they found minimal
overhead
in time from a key press to packet sent).  Our patch causes a packet to
be sent every 50 ms regardless of whether you type a key or not (sends
an ignore message aka nop).  Thus an attacker cannot be exactly sure of
your inter-keystroke timing.  

It doesn't matter if you are an average user or a fast touch-typing
secretary, your inter-keystroke timing is obscured.  In addition to this
our patch conserves bandwidth by shutting off after about a second after
the last key press.  If you don't stop typing for more than a second, it
appears as if you are constantly send packets to the server every 50
ms.    
Adding random noise would be less effective than what we are doing. 
Random noise would dilute the signal of inter-keystroke timing, we are
eliminating the signal altogether.  By pacing the inter-packet timing we
completely remove the inter-keystroke timing information.

regards,

-Jason Coit

-------- Original Message --------
Subject: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and
2.9p2
Date: Tue, 16 Oct 2001 17:36:18 -0400
From: Nicolas Williams <Nicolas.Williams at ubsw.com>
To: "C. Jason Coit" <jasonc at silicondefense.com>
CC: openssh-unix-dev at mindrot.org
References: <3BCC889C.AA5C57F0 at silicondefense.com>

Let's see. The timing attack has to do with predictable timing. The
solution would seem to be to add randomness to the packet timing. Your
patch does not do this -- it adds more predictable traffic.

I would think that to defeat the timing attack SSH would have to send
random-sized no-op packets at random intervals, or perhaps just adding
random delays before sending packets. And, of course, we're not talking
IP packets here, but SSH "packets."

But I could be wrong, I'm not an expert on this subject.

Nico

Oh, I see. I misunderstood your description of your patch.

Thanks,

Nico


On Tue, Oct 16, 2001 at 04:36:15PM -0700, C. Jason Coit
wrote:
> Nicolas,
> 
> The timing attack described in the paper by Dawn Song et al. works by
> examining the timing of keystrokes.  Currently OpenSSH sends a packet
> every time you press a key, thus it is possible to capture the
> approximate inter-keystroke timing of a user (they found minimal
> overhead
> in time from a key press to packet sent).  Our patch causes a packet to
> be sent every 50 ms regardless of whether you type a key or not (sends
> an ignore message aka nop).  Thus an attacker cannot be exactly sure of
> your inter-keystroke timing.  
> 
> It doesn't matter if you are an average user or a fast touch-typing
> secretary, your inter-keystroke timing is obscured.  In addition to this
> our patch conserves bandwidth by shutting off after about a second after
> the last key press.  If you don't stop typing for more than a second,
it
> appears as if you are constantly send packets to the server every 50
> ms.    
> Adding random noise would be less effective than what we are doing. 
> Random noise would dilute the signal of inter-keystroke timing, we are
> eliminating the signal altogether.  By pacing the inter-packet timing we
> completely remove the inter-keystroke timing information.
> 
> regards,
> 
> -Jason Coit
> 
> -------- Original Message --------
> Subject: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and
> 2.9p2
> Date: Tue, 16 Oct 2001 17:36:18 -0400
> From: Nicolas Williams <Nicolas.Williams at ubsw.com>
> To: "C. Jason Coit" <jasonc at silicondefense.com>
> CC: openssh-unix-dev at mindrot.org
> References: <3BCC889C.AA5C57F0 at silicondefense.com>
> 
> Let's see. The timing attack has to do with predictable timing. The
> solution would seem to be to add randomness to the packet timing. Your
> patch does not do this -- it adds more predictable traffic.
> 
> I would think that to defeat the timing attack SSH would have to send
> random-sized no-op packets at random intervals, or perhaps just adding
> random delays before sending packets. And, of course, we're not talking
> IP packets here, but SSH "packets."
> 
> But I could be wrong, I'm not an expert on this subject.
> 
> Nico
--
-DISCLAIMER: an automatically appended disclaimer may follow. By posting-
-to a public e-mail mailing list I hereby grant permission to distribute-
-and copy this message.-

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.