openssh and keystroke timing attacks (again)

Andrew Clausen clausen at
Tue Dec 28 09:07:15 EST 2010

Hi Dan,

On 27 December 2010 16:26, Dan Kaminsky <dan at> wrote:
> Isn't it difficult to predict the size of a legitimate response to a keystroke?  Just because you send a dummy response doesn't mean you got the size right. If you don't get the size right it's easy to differentiate wheat from chaff.

I presume you are referring to part of the proposal: if there is no
keystroke queued up to send when the transmission time arrives, a
dummy keystroke would be sent.  Your question is: what should the
reply to the dummy look like?

In most use cases such as writing commands in a shell, editing text in
vim/emacs, talking with talk(1), the server responds as follows:
 (1) In the middle of a stream of keystrokes, the server immediately
replies back with a short message immediately.  Typically, it just
echoes back the character just typed, or gives simple terminal
commands such as moving a cursor.
 (2) At the end of a (potentially short) stream of keystrokes, there
might be a larger reply, such as the output of an "ls" command, or the
result of a paste operation in a text editor.

Assuming (1) to be the case, if the server simply sends an immediate
short reply to the dummy messages, it will look like a real keystroke,
and an eavesdropper would have a hard time telling the real and dummy
keystrokes apart ("wheat from chaff").

I would like to add that ssh already pads messages, so that replies of
say 3 and 5 characters appear indistinguishable to eavesdroppers.


More information about the openssh-unix-dev mailing list