On Fri, Feb 06, 2004 at 06:54:06PM -0500, Eric Siegerman wrote:
> [CCing the author of the web page in question, in case she's
> no longer subscribed]
>
> On Tue, Jan 27, 2004 at 09:19:26AM +0100, Paul Bijnens wrote:
> > Long ago, I bookmarked this page:
> >
> > http://security.uchicago.edu/tools/gpg-amanda/
> >
> > but I never tried it myself...
>
> Long ago, it seems I had a small amount of input into it. Funny
> how that happens :-) But I've never tried it either.
>
> Looking at it now, I see that the basic approach is to have the
> Amanda client do compression, with the "compression" program
> (GZIP= environment variable to "configure") being a script that,
> during backups, does essentially "gpg -e | gzip", and during
> restores does the inverse.
>
> The gzip step in this pipeline is a pointless waste of CPU time,
> and may make the backup *larger*; by design, encrypted data is
> supposed to resemble random data, and so it compresses very
> poorly. (If yours compresses well, I'd be *very* worried about
> how secure your encryption is!)
>
> Try removing the gzip step entirely, and reducing it to just the
> gpg command. (gpg compresses the data internally, for the sake
> of better encryption, so putting a gzip step *before* gpg is
> equally pointless.)
The name escapes me now, but someone, about 2 yrs ago, but some effort
into installing the suggestions from U. Chicago on their systems and
then published a how-to to the mailing list.
I don't have gpg available to check the man page, but ISTR that it
even had an option to do gzip compression itself, eliminating the
need for a separate process in the pipeline.
I recall in email with the author of the how-to the same noting the
same potential problem you mention, gziping of fairly random data.
Rather than dropping it from the pipeline I suggested swapping the
order in both the dump and restore scripts. It would give two
benefits, compression and extra security. The latter comes from
the nature of many type of encryption cracking. They depend on
seeing recognizable language patterns in the "plain text" resulting
from a test-decryption. But if the original "plain text" was a
gzipped file, there would be no recognizable patterns. Of course,
if the cracker knew the plain text were a gzip file they could look
for the gzip "magic number" in the decryption.
--
Jon H. LaBadie jon AT jgcomp DOT com
JG Computing
4455 Province Line Road (609) 252-0159
Princeton, NJ 08540-4322 (609) 683-7220 (fax)
|
