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.> Anyway, I was simply thinking about this because the whole bugging of > typewriters thing crossed my mind recently. > > Chris >
Sorry for top posting but I'm on my phone. My colleague just sent me this. https://www.theregister.com/2023/08/07/audio_keystroke_security/ I don't know how relevant this is as of yet but based on a quick reading it seems related. So I fully support this work. If there is anything I can do please let me know. On Mon, Aug 7, 2023, 18:30 Damien Miller <djm at mindrot.org> 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. > > > > Anyway, I was simply thinking about this because the whole bugging of > > typewriters thing crossed my mind recently. > > > > Chris > > >
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