Disable Keystroke timing obfuscation in ssh

It is redundant thanks to Kloak and there is reason to believe its packet generation frequency (50Hz) is probably too fine grained allowing for CPU activity side-channel leaks. Something we could do without since we are in the business of sanitizing protocols to mitigate timing leaks.


In the Openssh config we ship we need to set ObscureKeystrokeTiming to “no”. because it is enabled by default.

(Credit goes to scientist Vinnie Monaco for bringing this to our attention)

1 Like

We don’t ship any SSH config files at time of writing. Never did. Doing so would be dangerous because it could break existing SSH setups, lockout people from servers. Next best thing would be offering an op-in config package for installation.

And SSH doesn’t have a .d config snippet drop-in folder.

related documentation:


IIRC what Vinnie described, this introduces a side-channel or even covert channel in the SSH protocol that is similar to the one described in the “hot or not” clock skew paper for TCP, that we spent a lot of effort tearing out by disabling timestamps and rewriting ISNs for.

Well this is awful. We will have no choice but to talk to upstream about it.

Enabled by default sounds good. Why disable it?

You’re suggesting to disable ssh’s native keystroke timing obfuscation because kloak supposedly already handles that?

But what’s the disadvantage to keep it as is?

The high grained frequency it generates packets constantly at could potentially reveal changes in CPU load of the system, leaking info by an adversary who induces CPU load on an onion service - leading to deanonymization. Also can leak info about encryption keys/operations running on a CPU observable on the network

1 Like

If you believe ssh wanted to introduce a security feature but actually could have introduced a CPU activity side-channel leak please report this to SSH.

1 Like

Upstream message link and reply:



Waiting for Vinnie’s feedback on whether this is enough or not.