Hacker News new | ask | show | jobs
by cabirum 996 days ago
The release notes do not say why there is a need to obfuscate keystroke timings. I guess it is designed to mitigate some attack vector? Is it already being exploited in the wild or... let's say is purely of academic interest?
4 comments

> mitigate some attack vector?

Pretty much, if anybody can listen in on your traffic and IO is unbuffered then they can extract information about the keys pressed based on the timing between consecutive presses. There's this old LWN article: https://lwn.net/Articles/298833/

It was also discussed a while back when it was first published on undeadly: https://news.ycombinator.com/item?id=37307708

In general though if you have buffered IO you are fine since a packet is sent only when 'enter' is pressed.

There is this cool thing I've noticed about software as it matures and this is a good example of that. When you're first starting out on a project, have no users, and its mostly feature incomplete there is little to no drive or reason to care about whole classes of security and performance issues... You're trying to just get the thing to work.

Let's ignore ongoing feature creep and development in projects for now (I'll address this in a second). As the core software becomes functional, gains users, has bugs fixed, the threat model of the software needs to change and grow. Generally software in this state gets progressively more stable and in that stability you can see the tiny ripples of very small edge cases.

For software where security is paramount and has an uncountable number of users protecting uncountable bytes of data like SSH, the tiny ripples of extremely esoteric attacks become a reasonable thing to address as a feature improvement. Do I need this feature for my personal threat model or even the threat model of my company? No probably not... But it doesn't hurt to have it either.

This feature raises the cost of attacking the software, and may dissuade different attacker from even trying. Most of practical security is more about making attacks expensive enough that they attacker will have to spend more than the value of what they would obtain if they were able to break into it and this change helps keep that high watermark well above those thresholds.

For software that does have ongoing feature creep this process is a lot slower but does seem to happen for opensource projects specifically that can survive their infancy sufficiently long enough to become foundational components like SSH and Curl. I've never seen this level stability from closed source software.

Keystroke timing attacks have been known for quite a while - heres a highly cited paper from over 20 years ago: https://www.usenix.org/conference/10th-usenix-security-sympo...

Recently there has been some work on using audio of keypresses to determine what's been typed: https://arxiv.org/pdf/2308.01074.pdf .

The statistical analysis described earlier works better when you have samples of a person's typing to try and learn whats been sent, but the acoustic work has raised some concerns that ML techniques can be used on just packet timings to determine what's been typed without a pre-determined signature. There's also concern that all that telemetry programs and sites send about you may be abused to build a signature of your typing patterns as well.

There was a recent research paper shared here where it was claimed using keystroke timing and some AI, researchers could predict the password with significant accuracy.