As an aside, I talked to the lead author on that acoustic side channel
attack. He says "This is a very interesting parallel to our paper and I
am happy to tell you that the timing between keystrokes was not used as
part of our model. The only features extracted for our classifier were
the acoustic emanations of the individual keystrokes, so no TDoA or
inter-key timing was used."
Hopefully, I haven't give him and his team ideas for a new attack :)
Mitch and I will take a look at your pull if you like. It may take a bit
as we are finishing up some work on ChaCha20.
Chris
On 8/11/23 8:38 PM, Damien Miller wrote:
On Tue, 8 Aug 2023, Damien Miller wrote:
On Mon, 7 Aug 2023, Chris Rapier wrote:
The broader issue of hiding all potential keystroke timing is not yet fixed.
Could some level of obfuscation come from enabling Nagle for interactive
sessions that has an associated TTY? Though that would be of limited
usefulness in low RTT environments. I don't like the idea of having a steady
drip of packets as that seems problematic both in terms of code complexity and
network usage. I also don't like the idea of imposing random jitter though
that might be easier to implement. However, without actual modeling I have no
idea if that would actually improve things.
Nagle is usually turned off because it causes annoying perceptions of
non-deterministic latency.
For ssh, IMO sending interactive traffic on a fixed clock (e.g. every
2-4ms) instead of as soon as possible, and adding fake keystroke packets
for some interval after the user stops generating traffic is the way to
fix it. I've slowly been preparing for this by reworking the mainloop and
associated timers.
Here's the beginning of an implementation of this. Far from complete,
but the timing quantisation part seems to work at least.
https://github.com/djmdjm/openssh-wip/pull/24
-d
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
