On 27 Oct 2000, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Rsync does its own compression, which is
> encryption, as you don't know where the compressed bits come from even
> if you guess the compression used.
It's true that existing and rearranged data is not transmitted, but
inserted data is sent essentially in the clear.
> > of operating system or rsync bugs in blocking/nonblocking
> > pipes/sockets etc.
>
> So correct the O/S bugs. Write to the authors and tell them about
> it.
I too would much rather people used non-sucky operating systems.
People using systems with buggy stacks have every right to complain to
the authors/vendors. But I doubt if many proprietary vendors will
care enough to fix the bugs, and even then not everybody has the
choice of upgrading. (Just the other day I tried to help somebody
build some software on Solaris 2.4.)
> > the challenge-response password system, this will mean that both
> > passwords and rsync data will be protected from snooping on the wire.
>
> There's very little percentage in this. while an xor costs nothing
> to implement, you have to change the key every few bytes to stop it
> being subject to differential analysis. That implies frequent key
> exchanges using a tougher key.
>
> Anyone who is interested in your home directory can get the key of an
> xored exchange by planting a text that they know the text of (like a
> mail from them) and inducing you to back it up with the key.
You seem to think I was talking about using xor with a constant key,
in which case that would be true. I'm not quite that stupid. I was
planning to use arcfour, which should make even chosen-plaintext
attacks hard. (I should have said so explicitly.) The weakness is
active attacks, implementation bugs and weak passwords.
> Please leave these things to the experts!
I agree that a little knowledge about crypto is a dangerous thing.
But what would you rather: that nobody should write network
applications at all?
Even if we decide not to implement it please just consider this thread
just me trying to learn a little more about the right way to do it.
> If you must, please implement an external transport by taking ssh
> and correcting whatever bug it has (or has not).
Andrew's already established that the bugs are in the tcp stack, not
in ssh or rsync. On anything non-free it's not in my power to fix it.
Perhaps we can provide more workarounds for broken stacks -- turning
off pipelining might work.
> Who is to say that you won't be blamed for providing security-less
> "security".
That's a good point. In the end, perhaps offering weak security as an
alternative is a bad idea, as people may be tempted to use it rather
than doing a little more work to install ssh. On the other hand,
sometimes something is better than nothing.
A closely corresponding situation is Netscape connecting to a web
server that presents an untrusted certificate. The connection is
subject to exactly the same attacks as this approach. They choose to
warn the user but allow them to proceed.
Indeed, arguably rsync should never support SSL, because unlike SSH
it's easy to use it in an insecure manner.
Do you think it would be reasonable to make arcfour encryption a
non-default compile-time option, turned on with --with-weak-privacy?
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
