It should be fairly straightforward to defeat such analysis using ssh compression. Keystrokes and control signals are batched before transmission.
Certainly I've had 'ssh -C' in finger-memory even on LANs for well over a decade.
Certainly I've had 'ssh -C' in finger-memory even on LANs for well over a decade.
And compression definitely doesn't always help as some of the attacks on TLS were only able to be done because of compression happening before encryption. Hence why we ended up with the HPACK in HTTP/2 to prevent exactly such type of attacks.
If necessary (or maybe in some optional supersecure mode), Mosh can afford to do much more timing variation, or even a "line-at-a-time" mode, since the client can be more aggressive about showing the predictive local echo (with the ability to correct it later) while waiting to send batches of keystrokes and for the server's reply. Or we could just do a CBR mode.
(BTW Mosh uses AES-128-OCB, not AES-256-GCM.)