
Timing Analysis of Keystrokes and Timing Attacks on SSH (2001) [pdf] - feross
https://people.eecs.berkeley.edu/~daw/papers/ssh-use01.pdf
======
pentestercrab
Anyone interested in this will likely enjoy Don't Skype & Type![1] where
researchers decoded keystrokes from background audio of Skype conversations.
The best part is source code is available[2]. I wonder how many people are
applying this to Twitch streamers or YouTube videos (especially any Talks at
Google videos) today?

1\.
[http://spritz.math.unipd.it/projects/dst/](http://spritz.math.unipd.it/projects/dst/)
2\. [https://github.com/SPRITZ-Research-Group/Skype-
Type](https://github.com/SPRITZ-Research-Group/Skype-Type)

~~~
ggerganov
I've been working on a similar tool: [https://github.com/ggerganov/kbd-
audio](https://github.com/ggerganov/kbd-audio) (see the 'keytap' tool). Not
sure how well it works yet, as I have made tests only with my setup. There is
a live page that anyone can experiment with.

~~~
feross
This is incredible work. Very well done! Have you posted this to Show HN yet?

~~~
ggerganov
Thanks! I haven't posted it yet, as I want to test how reliable is the
approach. I know it does not work with non-mechanical keyboards at all (most
likely because the key sounds are quiet) and I have tested it only with my
mechanical keyboard.

~~~
feross
Then I must apologize as I've already posted it to Twitter where it's getting
a lot of really positive reactions:
[https://mobile.twitter.com/feross/status/1068038193868460032](https://mobile.twitter.com/feross/status/1068038193868460032)

It worked pretty well on my keyboard! Let me know if you'd prefer me to delete
the tweet.

~~~
ggerganov
Wow! Thanks so much!

Please, don't delete the tweet. Hopefully I can collect feedback. Thanks
again!

------
santaragolabs
Man, this paper is a classic. I love traffic analysis attacks like this. I did
something myself six years back albeit with a somewhat contrived example
figuring out what someone is looking at on Google Maps via request and
response sizes. Example video here
[https://www.youtube.com/watch?v=skQNwd9Jij4](https://www.youtube.com/watch?v=skQNwd9Jij4)
and [https://ioactive.com/ssl-traffic-analysis-on-google-
maps/](https://ioactive.com/ssl-traffic-analysis-on-google-maps/).

I am speculating that nice traffic analysis attacks can be done on mosh (which
is a great tool btw) to, similar to the paper that is in this thread. It's
been sort of on my "todo/research" list but haven't been able to sit down for
a few days and mess around with it. And I'm sure that QUIC (HTTP/3) will open
up some interesting avenues of attack here too.

~~~
dingaling
It should be fairly straightforward to defeat such analysis using ssh
compression. Keystrokes and control signals are batched before transmission.

Certainly I've had 'ssh -C' in finger-memory even on LANs for well over a
decade.

~~~
santaragolabs
Sure. But that's why my point was about mosh
([https://mosh.org/](https://mosh.org/)). It just uses TCP+SSH for the
authentication part and then it sets up an encrypted UDP-tunnel on the server-
side with the mosh-client then just sending AES-256-GCM packets back and forth
over UDP. To the best of my knowledge it doesn't batch anything.

And compression definitely doesn't always help as some of the attacks on TLS
were only able to be done because of compression happening before encryption.
Hence why we ended up with the HPACK in HTTP/2 to prevent exactly such type of
attacks.

~~~
keithwinstein
Mosh does include random chaff and (some) timing variation and batching in an
effort to weakly frustrate these kinds of keystroke information leakages -- my
understanding is that we are at least as strong as SSH in this area, but would
love to see any analysis either way. (We have a "frame rate" with a minimum
interval in both directions, and a SEND_MINDELAY collection interval. The
current values are chosen for performance and minimizing tiny packets, but
could be increased or randomized.)

If necessary (or maybe in some optional supersecure mode), Mosh can afford to
do much more timing variation, or even a "line-at-a-time" mode, since the
client can be more aggressive about showing the predictive local echo (with
the ability to correct it later) while waiting to send batches of keystrokes
and for the server's reply. Or we could just do a CBR mode.

(BTW Mosh uses AES-128-OCB, not AES-256-GCM.)

~~~
santaragolabs
Oh wow, thanks Keith, first of all for mosh! I've been using it daily for
several years now. It's been great! Second of all for clarifying and
correcting me regarding the algorithm-usage. I don't know where I got it from
and I must have just misremembered; it's been a while since I spent a bit of
time looking at the source code (and walking away very impressed).

------
anfractuosity
That's really amazing how you can use the intervals between packets to infer
passwords like that. I thought I'd seen an attack like this that used tcp
timestamps, I didn't know you could do this from the packet arrival times
themselves!

I wrote a little program to transmit data via packet intervals, I need to play
with adding error correction to it now -
[https://www.anfractuosity.com/projects/timeshifter/](https://www.anfractuosity.com/projects/timeshifter/)

