|
Re: encryption with 2.5.0b2
2006-02-23 18:51:56
Josef Wolf wrote:
On Wed, Feb 22, 2006 at 03:34:44PM -0800, Kevin Till wrote:
- What is the point to uuencode and encrypt (with gpg) random data to
generate the key? Since the passphrase is stored on the same host,
protecting the key with the passprase is not of much use (IMHO).
It illustrates the method of using multi-key which a strong point of
aespipe.
OK, I see. "multi-key" was the magic word that (after some googling)
made me understand what's going on here. AFAICS, multi-keys can prevent
watermark-attacks? Are there more advantages to them?
basically to make dictionary attack almost impossible given that the
passphrase is not in the wrong hand.
And it's a symmetric encryption and to facilitate automatic
backup, the passphrase has to be stored somewhere.
This is (one) of the reasons why I'd prefer a pubkey method: You don't
have the passphrase lying around on a networked box.
Yes. Keep in mind that the passphrase (be it in symmetric or public-key
encryption cases) still need to be properly stored and managed.
I know, you can store the private-key of the public-key method offline
and only use it for backup recover.
- Why using aespipe at all? Is there any reason not to use gpg?
AFAICS, aespipe introduces only an additinal layer of complexity.
Amanda users have used aespipe in the past, so it's there.
Hmmm, AFAIK is aespipe part of loop-aes and loop-aes is deprecated
because the kernel developers want to switch to devmapper. Please
correct me and clarify if I'm wrong.
devmapper seems to be merged into the mainline Linux and loop-aes has
not. However, for the purpose of backup encryption, it's still a valid
solution. Debian and Gentoo distribute it and it's actively maintained
by the author.
I believe aespipe gives better performance since gpg is doing more
than just encryption.
AFAIK, gpg does compression in addition to encryption. But then you need
to compare gzip+aespipe against gpg. Or did you mean something different?
gpg also does mdc (modification detection code).
- Since the server says whether/which encryption is to be used, the
server can request unencrypted backups from the client. This
implies that the server has to be trusted.
Use "auth ssh/krb4/krb5" to enable transport encryption.
I am not about transport encryption here. I am about not trusting the
amanda server.
That's how ssh will help here. When server starts the
process(/usr/bin/ssh -l amandabackup ../amandad) on the client. The
client sshd will perform RSA based authentication on the server.
It improves security.
What if the server is totally compromised? It's time to look at
SELinux(Redhat) and or AppArmor(SuSE)
--
Thank you!
Kevin Till
Amanda documentation: http://wiki.zmanda.com
Amanda forums: http://forums.zmanda.com
|
|
|
