Forgive this intrusion, but I couldn't
find much mention of this in the archives.
To reduce vulnerability to "Keystroke Timing Attack"
and reduce keystroke packet overhead, why not insert
a small configurable delay (10-1000ms) before sending
keystroke packets?`ssh -d NNN`
Yes, this costs latency. But many netlinks are
already 200+ms and latency isn't always objectionable
in a CLI where people frequently type-ahead. The
longer delays (20+ms) also give a good chance to
combine multiple keystrokes into a single packet,
reducing overhead and confusing listeners.
Practically, XX chars or a wait of `delay` would
release the send buffer. That short wait would be
like pressing "RETURN" in LINEMODE telnet. Fancier
implimentations might use smart delays based on
previous keystroke interval.
nanosleep() and similar delay functions should be
very useful so long as they're not so short as to
busywait but instead wait for the system clock. This
introduces a variable delay that greatly reduces the
information from timing analysis.
I believe sshd already can handle multiple keypresses
per packet, but I did get one to choke around 1500
after pasting in 10KB.
I inserted a usleep() in channel_output_poll() [not the
best place but I couldn't get it to work in clientloop.c]
and it runs fine for me, but I may need to make the delay a
bit smarter.
-- Robert
