On Mon, Mar 31, 2003 at 02:05:01PM +0200, Nicki Messerschmidt wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi all,
> I just finished my amanda - gpg setup and now I'm capable of backup
> files and restoring files (even with amrecover!).
> For thos who are curious how I did it I provide short step-by-step
> instructions:
...
> 6. configure source with: GZIP=<path>/gpgzip [as attached] ./configure
...
I've seen that script before and had a couple of thoughts regarding it.
As I don't have gpg running I've been unable (disinclined?) to check them.
First, during encryption+compression the compression level is "9".
dump_to_stdout () {
# Encrypt it, compress it, and send it on it's way
${gpg_prog} --no-tty -q -e -z 9 -r ${gpg_as} -r ${gpg_as_self}
^^^^^
This is the highest compression level, corresponding to "BEST" in a dumptype.
BEST compression may place a heavy cpu burden on the system, particularly
with the added, simultaneous burden of encryption.
Second I question the wisdom of the order of encrypt then compress (and
uncompress/decrypt). I'm guessing here, but I assume the output of an
encrytion scheme is relatively random. If so, as "we all know from
tapetype reports :)", random data does not compress very well. It may
be best to compress first and then encrypt. This would require the
"dump_to_stdout" to be a pipeline similar to "restore_from_stdin" and
the order of the restore pipeline be reversed.
An added advantage to splitting the command into a pipeline is that the
compression flags used by amanda (including compression levels specified
in the dumptype) could be applied to gzip.
The third thing also deals with the order of compress/encrypt. Standard
unix is supplied with an encryption program crypt(1). This uses a not
so state of the art algorithm, but was considered pretty good by the
Germans in WWII ;) One known method of guessing the passkey for that
algorithm depends on knowing the original structure of the encrypted
data (all ascii, structured headers, ...). Amanda dump files fall into
such a category. One way to complicate such an attack is to compress
the data before encrypting causing it to loose its original structure
and require the attacker to try to uncompress the data after each guess
of a passkey. I do not know if pgp is vulnerable to any similar attacks,
but if so, compressing first may make the data more secure.
Just some thoughts dreged up from old memory cells upon seeing the script again.
jl
--
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)
|
