On 29 Oct 2000, Pierre Abbat <[EMAIL PROTECTED]> wrote:
> The attacks on synchronous stream ciphers (not to be confused with
> self-synchronizing stream ciphers, which are different sort of
> animal) are of the sort where Mallory flips a bit, not knowing what
> the plaintext is, but knowing that the bit is in a certain field of
> a record. This can be foiled by using a nonlinear checksum or hash
> function to verify the integrity of the data.
I agree that that is a possible attack on this design.
The data sent over the encrypted channel will usually be
gzip-compressed, so changing a single byte won't produce a single byte
change in decompressed plaintext. (It might be appropriate to force
at least -z0 if --privacy is specified.) Simple corruption of the
stream will be detected by gzip. Without knowing the previous
plaintext history it will be hard (though probably not impossible) to
work out what to change in the cyphertext to produce a desired change
in the decompressed output. Effectively gzip will act as a nonlinear
checksum.
Firstly, this is not a tape serial or radio link where the fundamental
attack is to flip a bit: rather, over a TCP connection the attacker
has to take over the whole connection, or at least a whole packet. If
we allow that, we might have to worry about TCP spoofing,
man-in-the-middle, and many other things.
So this is a protection only against passive eavesdroppers. (Is her
name Eve rather than Mallory? I don't have AC2 here.)
If you're concerned about attackers smart/powerful enough to modify
arbitrary bytes in the TCP connection and reverse the gzip checksum,
then you should be using SSH (and maybe a VPN). Here I'm just trying
to protect against people running tcpdump to sniff files as they go
past.
Thanks for your feedback -- it's very helpful.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
