> converse among themselves. If data is buffered up into blocks they
If you're using zlib on the streams you already *have* sufficient
packetization...
>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 gz
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
On 30 Oct 2000, "Mark W. Eichin" <[EMAIL PROTECTED]> wrote:
> Instead of making up some hashing key-generation method, please look
> at RFC2104 "HMAC" (and the six or seven followup rfc's on specific
> instantiations.)
>
> Also, for rsync, I don't see why you'd particularly want a stream
> cipher
Instead of making up some hashing key-generation method, please look
at RFC2104 "HMAC" (and the six or seven followup rfc's on specific
instantiations.)
Also, for rsync, I don't see why you'd particularly want a stream
cipher (it isn't interactive, you have "large" packets to work with)
and I mig
>Z number of people will use stream cyphers when they really should be
>using ssh, because there are active attackers on the network and the
>data is security-critical. This despite that the documentation will
>still recommend using SSH as a first choice.
The attacks on synchronous stream cipher
On 28 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> I think you've got a plan that will not weaken rsync, and that will
> add some valuable security in some settings. It's nicely
> complementary to rsync-over-ssh. Those of us who use rsync-over-ssh
> haven't even figured out what the daemon
On Sun, Oct 29, 2000 at 02:54:26PM +1100, Martin Pool wrote:
> On 28 Oct 2000, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> > My guess is that if the SSHv2 spec issues are cleared up then SSHv2 is
> > the best possibility for rsync. I don't mean using SSH with rsync as is
> > done now, but rather
On 29 Oct 2000, Martin Pool <[EMAIL PROTECTED]> wrote:
> Although I would prefer a cypher with a nonproprietary design, RC4
> does seem to be widely used and trusted. Schneier also mentions SEAL;
> I'll look at it later.
It turns out that SEAL is patented (patent pending?) by IBM, so it's
even
On 28 Oct 2000, Nicolas Williams <[EMAIL PROTECTED]> wrote:
> If I may I'd like to suggest an alternative: use Diffie-Hellmann for the
> key exchange and use the DH key as the symmetric encryption key. This
> gives you anonymous encrypted sessions. Add an authentication feature
> (basic, GSS-API,
On 28 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-28-20:03:19 Martin Pool:
> > > As for licensing, the only requirement is to give credit...
> >
> > Fine.
>
> If you've made peace with OpenSSL licensing, then I'd like to
> suggest:
I thought it was more of a problem than it app
> Add allow RSA identification only.
Thanks - I didn't see this option.
> Only because you didn't read the manpage. The principle is obvious!
The principle is. The manpage isn't. The manpage didn't help at all with
compiling and installing ssh on Win95/98/NT/2000. It was reasonably
straightf
On Sun, Oct 29, 2000 at 11:03:19AM +1100, Martin Pool wrote:
> On 28 Oct 2000, Rich Salz <[EMAIL PROTECTED]> wrote:
> > If you just embed arcfour, what's your key management plan?
>
> key = MD4(salt, user, password, possibly other stuff)
>
> The salt is sent on each new connection; at the moment
On 28 Oct 2000, Rich Salz <[EMAIL PROTECTED]> wrote:
> > However, I don't think SSL will cope with two fork'd processes trying
> > to do SSL simultaneously, because the library assumes complete control
> > over the local end of the socket.
>
> OpenSSL doesn't *have* to work that way, it's just th
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
> However, I don't think SSL will cope with two fork'd processes trying
> to do SSL simultaneously, because the library assumes complete control
> over the local end of the socket.
OpenSSL doesn't *have* to work that way, it's just that the default
implementation that most people use works that w
I'd like to add my voice to the "yes please" crowd for built-in transport
and encryption for rsync. I use rsync primarily for mirroring purposes,
and hence have to run it as root at both ends. To have it run via ssh
automatically at night, I had to have an empty passphrase for root. That
is now
>> I honestly don't think it's worth it. Anyone who can compile can
>> compile (and install) ssh.
>
>Possibly it is not worthwhile after all -- I always knew it would be
>worse than SSL but the idea of completely cutting out the transport
>problems was tempting.
>
>If it turns out that there ar
On 27 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-27-21:26:36 Martin Pool:
> But OpenSSL isn't just the reference SSL lib these days, it's also
> the reference general-purpose crypto library. OpenSSH doesn't talk
> SSL, it just uses the crypto routines out of OpenSSL. In fact,
> O
On 27 Oct 2000, Bennett Todd <[EMAIL PROTECTED]> wrote:
> 2000-10-27-22:02:28 Martin Pool:
> > 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
>
On 28 Oct 2000, "Peter T. Breuer" <[EMAIL PROTECTED]> wrote:
> Ssh is open software. If there is a bug, it can be fixed by writing to
> the authors. If you mean Windows, use Putty. If you mean solaris,
> ask the people who run the free solaris software sites to add a
> correctly compiled ssh pack
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 i
On 27 Oct 2000, Dave Dykstra <[EMAIL PROTECTED]> wrote:
> There's been a lot of talk about incorporating openssl into rsync but
> it's never been done.
My previous message explains why it seems hard, but perhaps I've just
missed something.
> I'm actually much more interested in the active attac
On 27 Oct 2000, Neil Schellenberger <[EMAIL PROTECTED]> wrote:
> I'm absolutely no expert on it (e.g. never programmed with it), but
> perhaps you could simply use OpenSSL (which is, after all, what
> OpenSSH is implemented on top of anyway). Then you'd get high grade
> encryption, certificates,
Obviously ssh is a source of a large fraction of the problems people
have in using rsync. Most of the problems seem to come from the fact
that we have to run an external program, and so we get lockups because
of operating system or rsync bugs in blocking/nonblocking
pipes/sockets etc.
I'm look
25 matches
Mail list logo
