Strong encryption
C.Zimmermann
Host for security reasons.
Encryption must be strong: IDEA, 3DES or similar.
One way would be the integration of PGP into rsync.
Is there any PGP integration into rsync available ?
Thank愀 Clemens
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Lapo Luchini
>
>Is there any PGP integration into rsync available ?
>
>
http://www.openssh.org/
--
Lapo 'Raist' Luchini
la...@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
jw schultz
> We need to encrypt files before transferring them to the destination
> Host for security reasons.
> Encryption must be strong: IDEA, 3DES or similar.
> One way would be the integration of PGP into rsync.
>
>
You are a little vague here. Do you mean you need the
transmission encrypted or that you want the files to be
stored encrypted on the destination?
If you want the transmission encrypted use rsync over ssh
or you can look into encrypted tunnels and VPN stuff.
If you want them stored on the destination encrypted you
will need to keep them encrypted on the source. Rsync won't
be able to compare an encrypted (cyphertext) file with an
unencrypted (plaintext) one. For rsync to support
encryption it would need to be able to decrypt your files
and that would be very insecure.
If you keep the files encrypted on the source and
destination you might as well use the rsync -w option
because for encryption to be effective it truly does need to
randomize the data rendering the special efficencies of
rsync moot. Additionally, for the class of cyphers you
mention to be secure they need long keys that change
frequently and are best generated randomly and then
encrypted using even more secure cyphers. This randomness
assures that no file will be encrypted to the same
cyphertext twice.
Sorry if i bowled you over on the cyphertext files issues.
Hopefully all you needed was a pointer to secure
transmission. If not, a coherent description of why the
need for encryption may help us find a way to meet your
needs.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: j...@pegasys.ws
Remember Cernan and Schmitt
C.Zimmermann
> If you want them stored on the destination encrypted you
Yes, that´s it. The owner of the source files will be sure, that no one
else can read his files on the destination host.
I thought, rsync only looks at the modification date of a file and
decides whether to backup this file or not. In this case, the backup
could be stored encrypted.
Bye Clemens
Lapo Luchini
>
>I thought, rsync only looks at the modification date of a file and
>decides whether to backup this file or not.
>
examines the content of the file to send just what is needed,
differently from other mirroring software.
--
Lapo 'Raist' Luchini
la...@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
jw schultz
> >
> > If you want them stored on the destination encrypted you
>
> Yes, that´s it. The owner of the source files will be sure, that no one
> else can read his files on the destination host.
>
> could be stored encrypted.
Rsync can handle encrypted files just fine. It just treats
them as ordinary binary files. If the owner of the files
encrypts them on the source they will be encrypted on the
destination.
As you have said rsync normally just looks at the
modification date for deciding whether to update the
destination (unless you use the -c option) But, unless the
-w option is used rsync will use some rather clever (nod to
rsync developers) methods to transfer only the changed the
parts of changed files. It is this feature that gives rsync
its speed. My comments below are to advise you that that
clever feature is nullified by encrypted files. In fact for
encrypted files rsync would be sub-optimal. If most/all of
the changed files are encrypted i would use the -w option.
Enjoy
>
> Bye Clemens
>
>
>
>
> > will need to keep them encrypted on the source. Rsync won't
> > be able to compare an encrypted (cyphertext) file with an
> > unencrypted (plaintext) one. For rsync to support encryption
> > it would need to be able to decrypt your files and that would
> > be very insecure.
> >
> > If you keep the files encrypted on the source and
> > destination you might as well use the rsync -w option
> > because for encryption to be effective it truly does need to
> > randomize the data rendering the special efficencies of rsync
> > moot. Additionally, for the class of cyphers you mention to
> > be secure they need long keys that change frequently and are
> > best generated randomly and then encrypted using even more
> > secure cyphers. This randomness assures that no file will be
> > encrypted to the same cyphertext twice.
> >
> > Sorry if i bowled you over on the cyphertext files issues.
> > Hopefully all you needed was a pointer to secure
> > transmission. If not, a coherent description of why the need
> > for encryption may help us find a way to meet your needs.
> >
> > --
> > ________________________________________________________________
> > J.W. Schultz Pegasystems Technologies
> > email address: j...@pegasys.ws
> >
> > Remember Cernan and Schmitt
> >
> >
>
>
> --
> To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
> Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: j...@pegasys.ws
Remember Cernan and Schmitt
--
Adrian Ho
> As you have said rsync normally just looks at the modification date
And the file size. This check, to the best of my knowledge, cannot be
turned off.
- Adrian
jw schultz
> On Wed, Jun 05, 2002 at 03:33:23AM -0700, 'jw schultz' wrote:
> > As you have said rsync normally just looks at the modification date
>
> And the file size. This check, to the best of my knowledge, cannot be
> turned off.
Yes. I remembered that just after sending. A significant
oversimplification on my part. Sorry. There is
--size-only, --ignore-times, --modify-window and --checksum
that affect the detection of changed files.
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: j...@pegasys.ws
Remember Cernan and Schmitt
--
C.Zimmermann
> >
> >I thought, rsync only looks at the modification date of a file and
> >decides whether to backup this file or not.
> >
> examines the content of the file to send just what is needed,
> differently from other mirroring software.
But beside this rsync offers the mechanism for incremental mirroring on
file bases over the network, so I think it makes sence to enhance rsync
with the encryption option on destination files.
Its better than "tar -cvf - / | pgp | ssh user@destinationhost"
Clemens
>
> --
> Lapo 'Raist' Luchini
> la...@lapo.it (PGP & X.509 keys available)
> http://www.lapo.it (ICQ UIN: 529796)
>
>
>
>
jw schultz
>
> > >
> > >I thought, rsync only looks at the modification date of a file and
> > >decides whether to backup this file or not.
> > >
> > By default, it does not, in fact it's REAL usefullness it's that uit
> > examines the content of the file to send just what is needed,
> > differently from other mirroring software.
>
> But beside this rsync offers the mechanism for incremental mirroring on
> file bases over the network, so I think it makes sence to enhance rsync
> with the encryption option on destination files.
Reread my earliest response on this thread. An encryption
option would require large changes to the protocol and be a
real nightmare as far as keys are concerned. If you want
encryption, keep the files on the source encrypted.
> Its better than "tar -cvf - / | pgp | ssh user@destinationhost"
That is like saying a courier service is better than drayage
(cargo hauling).
--
________________________________________________________________
J.W. Schultz Pegasystems Technologies
email address: j...@pegasys.ws
Remember Cernan and Schmitt
--
Donovan Baarda
> > >
> > > If you want them stored on the destination encrypted you
> >
> > else can read his files on the destination host.
> >
> > could be stored encrypted.
>
> Rsync can handle encrypted files just fine. It just treats
> them as ordinary binary files. If the owner of the files
> encrypts them on the source they will be encrypted on the
> destination.
>
> As you have said rsync normally just looks at the
> modification date for deciding whether to update the
> destination (unless you use the -c option) But, unless the
> -w option is used rsync will use some rather clever (nod to
> rsync developers) methods to transfer only the changed the
> parts of changed files. It is this feature that gives rsync
> its speed. My comments below are to advise you that that
> clever feature is nullified by encrypted files. In fact for
> encrypted files rsync would be sub-optimal. If most/all of
> the changed files are encrypted i would use the -w option.
Perhaps he wants a gpg-rsyncable patch to gpg?
Seriously, such a thing would be possible. After the long thread in which I
made a dick of myself discussing how gzip-rsyncable couldn't possibly work,
only to have someone explain how it does, I now know how it could be done;
encript the data in chunks, where the chunk boundaries are determined by the
same heuristic gzip-rsyncable uses.
I think I could even whip up a working Python wrapper around gpg in a day or
so that could do the job... but I'm too buisy looking for paid work right
now to do it so I'll leave it as an excersise for others :-)
--
----------------------------------------------------------------------
ABO: finger a...@minkirri.apana.org.au for more info, including pgp key
----------------------------------------------------------------------
Lapo Luchini
>
>encript the data in chunks, where the chunk boundaries are determined by the
>
>
--
Lapo 'Raist' Luchini
la...@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)
Michael Salmon
wrote:
+------
| >
| >
| > encript the data in chunks, where the chunk boundaries are determined
| > by the
| >
| >
| That would lessen encryption security, of course.
All encryption is done in chunks, the size varies of course, usually
between 1 and 256 bits.
/Michael
--
This space intentionally left non-blank.
Lapo Luchini
> between 1 and 256 bits.
Of course, but even if block ciphers are usually used to encode data,
they are usually used in OFB or other feedback mode that convert them to
stream ciphers, so that equal blocks are NOT converted to equal blocks
(this would of course lessen the security A LOT) so the fact that the
original cipher is a block cipher is totally ininfluent and a change in
a single bit in the plaintext creates changes from that block until the
end, in the ciphertext.
Lapo
BTW: using the cipher in ECB (without feedback) is much less secure, see
the RSALABS FAQ for more infos or other crypto texts.
--
Lapo 'Raist' Luchini
la...@lapo.it (PGP & X.509 keys available)
http://www.lapo.it (ICQ UIN: 529796)