[Fwd: Re: Defeating Timing Attacks Patch for OpenSSH 2.9.9p2 and 2.9p2]

Nicolas Williams Nicolas.Williams at ubsw.com
Wed Oct 17 23:12:00 EST 2001

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



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.

More information about the openssh-unix-dev mailing list