On 28 Oct 2000, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> It can't. That's what I said. if the key were constant, the code would
> be trivial to crack. So you must change the key frequently.
arcfour is a stream cypher that behaves similarly to RSADSI's RC4(tm)
cypher, described in s17.1 of Schneier's Applied Cryptography 2ed.
arcfour is initialized by a 256-byte key. It uses this to generate a
keystream independent of the plaintext. The keystream is XORd with
the plaintext to generate the cyphertext. RSADSI claims that RC4 is
immune to differential and linear cryptanalysis, doesn't seem to have
any small cycles, and is highly nonlinear. RC4 can be in about
2**1700 = 256! * 256**2 internal states, so it is hard to predict
later parts of the sequence even if known plaintext reveals part of
the keystream.
Obviously making two transmissions with the same key would be very
dangerous as it could be used to recover the XOR of the two
cleartexts. Therefore our key is based on a strongly random salt in
combination with the password.
As you noted, if we drop any bytes in the channel then because there
is no explicit synchronization, the remainder of the stream will be
unrecoverable. However, we can quite reasonably count on TCP to avoid
doing that. (It's not like we're running over a plain async serial
line.) After all, if TCP were to lose bytes then plain rsync would be
corrupted and unrecoverable anyhow. arcfour encryption makes it no
more and no less vulnerable.
> You can only avoid layering if you have a stream cipher. If it's a
> block cipher, then you will have to switch your data stream on and off
> while you send the meta information, padding, random fill, etc. in each
> block, and just "sliding in the code" (as I called it) becomes hard.
Yes, only a stream cypher would be sensible.
> I don't know anything about arcfour. Is it a stream cipher, then?
>
> > The algorithm is basically: if the --weak-privacy option is specified,
> > then create an arcfour cypher at each end using MD4(password,
> > challenge, ...) as the key. The two sides both have that information,
> > but the password has not been sent clear over the wire. Therefore no
> > key exchange is required, and the key will be different on every
> > transfer.
>
> You are talking about a one-time shared secret obtained at the initial
> handshake? (sounds like ssl to me!). Be careful that it really is known
> only to the two participants, even in the presence of
> eavesdroppers.
To log into an rsyncd server, the client must supply a password. At
the moment it's used in a challenge-response protocol for
authentication, so it's never sent in the clear or even encrypted.
The password is known to both the client and the server, but not to
the eavesdropper.
MD4 is used for the c-r protocol, and some weaknesses in it are now
known although I think it's not actually broken. I think it will be
simpler for the eavesdropper to do a dictionary attack. Possibly we
should move to SHA instead, but that's not in the scope of this
proposal.
We can't encrypt anonymous sessions; that's not a terrible loss as
anonymous rsync is usually used for public distribution.
If the eavesdropper discovers the password (e.g. because it's
obvious), then they'll be able to decrypt the sessions. But it's
likely that they could in any case just log in and retrieve the
information themselves. It is a little worse than that: this way is
silent whereas logging in could be detected, and they can use it to
get around IP address restrictions.
If the eavesdropper can reverse MD4, or can guess the password, then
they can both eavesdrop and log in themselves.
So security comes down to the security of the password. If passwords
are not enough, then the user should go to SSH and Diffie-Hellman,
Public-Key authentication and so on.
> OK, so arcfour must be a stream cipher, with keys changing "by dead
> reckoning" in synchrony on either side. This is very susceptible to
> noise, surely? When it breaks, what do you do? reconnect using the same
> keys? There are likely disruption and replay attacks if you do.
See above for noise.
rsync never automatically retransmits. If the user restarts rsync,
there will be a different salt, and so the encryption key will be
different. Good question though.
> Why create your own set of potential security holes?
I think it can be justified if
* it's substantially more useable for some people
* they don't weaken the product unless they're specifically requested
* the potential weaknesses are documented
Bear in mind that there is already crypto/security code in rsync to do
c-r authentication. In a way it is more dangerous: if my stuff fails,
the data will be revealed; if the authentication stuff fails then the
attacker can log in, possibly r/w.
--
Martin Pool, Linuxcare, Inc.
+61 2 6262 8990
[EMAIL PROTECTED], http://www.linuxcare.com/
Linuxcare. Support for the revolution.
PGP signature
