>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.
So the checksum is computed on the uncompressed data, and transmitted along
with the compressed data? That should be enough to detect bitflips.
>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.
TCP spoofing is beyond the scope of end-to-end encryption. Man in the middle
you've taken care of by using the password, which is known to both ends but not
Mallory, to generate the key.
>So this is a protection only against passive eavesdroppers. (Is her
>name Eve rather than Mallory? I don't have AC2 here.)
Yes. Then there are Peggy, Victor, and Walter.
>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.
I think it's quite enough to protect against Mallory, as long as there is no
set of bits that when flipped will produce valid output regardless of the data.
phma
