[KyleSanderson]

The implementation is just wrong from what's been presented. basic jitter (20-100ms), and a dynamic payload size are what's actually missing here. The question now becomes though how interactive should your session be. Timing the connection latency might help to an extent, but this is about mitm and you don't necessarily know where your adversary is (first hop, or towards the end). Batching keystrokes would also help here.

[tialaramex]

Basically there are two "modes" in normal mode OpenSSH is content to idle with no packets moving except any requested keepalives. In "chaff mode" currently they try to send a chaff packet every time they can to disguise your keypresses, but they forgot keystrokes will just get bundled into the existing chaff packet, growing it, so it stands out as special.

All they need to do is retain the "chaff mode" but when they have a keystroke ready to be sent they should suppress the chaff that would otherwise go in the same packet.

No need for "basic jitter" or "dynamic payload size" that I can see, with this change the packets are indistinguishable in terms of size or (encrypted) content, and they have no more or less jitter than would be normal for the network they're traversing.

[Various small edits to clarify]

[aidenn0]

They will also need to increase the minimum size of a non-chaff keystroke to be the size of the largest keystroke that they wish to keep confidential; 3 bytes is a minimum for the basic control characters (e.g. arrow keys which are ESC '[' X where X depends on the arrow direction).

I did find it interesting that the return keystroke was of a differing size to other characters; on unix systems it should just send a ^J.

[ec109685]

Can’t they just send large control characters as three separate key presses?

[aidenn0]

That will confuse screen/tmux which needs to distinguish between escape codes and a press of the escape key.