openssh and keystroke timing attacks (again)
clausen at econ.upenn.edu
Tue Dec 28 09:07:15 EST 2010
On 27 December 2010 16:26, Dan Kaminsky <dan at doxpara.com> 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