On Tue, Oct 09, 2001 at 01:25:08PM -0400, Henry Spencer wrote: > The nice thing about the Silicon Defense technique (assuming I've > understood it correctly -- I haven't yet examined their code) is that it > actually eliminates the signal path completely, by fitting the real > traffic into the dummy traffic. At first glance, I don't think there's > any reasonable general-purpose way for the network layer to do that. You mentioned the padding used by IPSEC in another message, and this is probably a help. However, perhaps specifying internally that packets should only go out at specific intervals which are adjusted for volume would be plausible? I'm talking very low delays here; on the level of a few milliseconds, but enough to take timing resolution out of the equation in some cases. If we haven't seen a packet to be encrypted in one second, holding it until the next 10ms mark is fine. If we've seen a packet in the last second but not in the last 100ms, send the packet out on the next 2ms marker, etc. > Given that the only really touchy area is passwords, which are a tiny > fraction of all network traffic, it seems reasonable to seek long-term > solutions at or near the application layer, where it's easier to recognize > the situations needing special attention. In particular, it's really dumb > to have passwords going across a character at a time, when there is no > character-by-character interaction involved. Unfortunately, this isn't just a change to 'su' or some such interactive application, but to the terminal application being used. If I'm 'ssh'ing into a remote machine on which I run 'su', ssh doesn't 'know' that that application doesn't need my keystrokes until the newline. If there were some terminal emulation way of communicating "line at a time" mode, with echo on or off for input, it would help. -- Michael T. Babcock CTO, FibreSpeed Ltd. Linux-crypto: cryptography in and on the Linux system Archive: http://mail.nl.linux.org/linux-crypto/
