Well, I was thinking this situation in real life, and in case of SSH (for example) is usually used. Over TCP/IP I mean. TCP protocol it selfe does not care what is delay between packages it receives (if they come in meanfull time) or even in what order those packages comes. So typed S -character can arrive before K -character, even they are typed in different order. Packet could be also droped. Data flow over networks can be very unstable this way and I could quess that because of this, time analyse would be quite hard to use. Atleast in big networks where packets travels long routes. Ok this does not mean that time analyse method itselfe would be totally impossible but hard it is anyway. :)

Only passwords? Using a dictionary attack, you could possibly reconstruct most of what the user is entering because everyone has his own special way to use a keyboard, his own special time signature....

Solution: put a tiny minimum delay between non-burst transfers of small data amounts (< 10 bytes?) and re-send similarly sized fake data at the same tiny minimum delay afterwards up to X times, so we get a constant data stream for 5 seconds or so and without any timely information.

Of course, we still have some timely information exposed to the outside world: burst periods structure or so. But it is possibly much less critical.

Seems a little on the paranoid side, but if you're serious about plugging up this theoretical security hole, you can do it without changing ssh. Instead patch screen or xterm or write a standalone pty middleman that adds random timing jitter to all buffered keystrokes. For extra fun, on backspace have it delete characters from its internal buffer if they haven't been sent yet, or even randomly send characters followed by backspaces in order to introduce yet more noise, but of course this'll break interactive programs like mutt and vim which don't universally allow backspace to undo the effect of the previous keystroke. So only enable this "extra fun" if the subordinate program is in cooked mode. (Oh wait, isn't ssh always in raw mode?)