[santaragolabs]

Sure. But that's why my point was about mosh (https://mosh.org/). It just uses TCP+SSH for the authentication part and then it sets up an encrypted UDP-tunnel on the server-side with the mosh-client then just sending AES-256-GCM packets back and forth over UDP. To the best of my knowledge it doesn't batch anything.

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.

[keithwinstein]

Mosh does include random chaff and (some) timing variation and batching in an effort to weakly frustrate these kinds of keystroke information leakages -- my understanding is that we are at least as strong as SSH in this area, but would love to see any analysis either way. (We have a "frame rate" with a minimum interval in both directions, and a SEND_MINDELAY collection interval. The current values are chosen for performance and minimizing tiny packets, but could be increased or randomized.)

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.)

[santaragolabs]

Oh wow, thanks Keith, first of all for mosh! I've been using it daily for several years now. It's been great! Second of all for clarifying and correcting me regarding the algorithm-usage. I don't know where I got it from and I must have just misremembered; it's been a while since I spent a bit of time looking at the source code (and walking away very impressed).