LWN.net Logo

Buffer keys at 100 ms intevals

Buffer keys at 100 ms intevals

Posted Sep 19, 2008 0:20 UTC (Fri) by gmaxwell (subscriber, #30048)
In reply to: Buffer keys at 100 ms intevals by djm
Parent article: OpenSSH and keystroke timings

Tricks like this sound nice but try proving that they actually stop the information leak. As far as I'm aware nothing short of padding to a full constant information rate has ever been proven to stop information leaks from timing in systems where they have been considered (anonymous remailers, onion networks).

Since we're already talking about a somewhat obscure (though, no doubt, real) vulnerability it's probably not worth adding complexity for a half solution which can not be proven to completely close the hole.

To me the obvious solution to this would be to extend ssh agent to supporting more types of authentication, and allowing programs other than SSH to make use of that functionality. Timing attack immunity would fall out as a nice side-effect but greater robustness against compromised jump hosts would also be a benefit, as well as the ability to provide things like smart-card authentication across multi-hop ssh connections.

Beyond the basic SSH-via-SSH or SUDO-(PAM)-via-SSH) cases it would take some time for applications to be updated to take advantage of this functionality, so it wouldn't be an overnight fix, but we've lived with this vulnerability this long so a bit longer waiting for the right fix shouldn't kill anyone.


(Log in to post comments)

Buffer keys at 100 ms intevals

Posted Sep 19, 2008 6:00 UTC (Fri) by djm (subscriber, #11651) [Link]

SSH isn't like an Onion network or a remailer - those seek to hide the identities of disparate users, whereas SSH just needs to mask inter-keystroke timings and run lengths. It's quite a different (and much simpler, thankfully) problem.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds