> 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,
24 matches
Mail list logo
