From owner-freebsd-security Mon May 17 6:43: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from schuimpje.snt.utwente.nl (schuimpje.snt.utwente.nl [130.89.238.4]) by hub.freebsd.org (Postfix) with ESMTP id 666D015094 for ; Mon, 17 May 1999 06:43:03 -0700 (PDT) (envelope-from jeroen@vangelderen.org) Received: from wit395301.student.utwente.nl ([130.89.235.121]:48914 "EHLO vangelderen.org" ident: "NO-IDENT-SERVICE[2]") by schuimpje.snt.utwente.nl with ESMTP id <8063-32304>; Mon, 17 May 1999 15:42:53 +0200 Message-ID: <37401CDF.CEFA8B53@vangelderen.org> Date: Mon, 17 May 1999 15:42:55 +0200 From: "Jeroen C. van Gelderen" X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Adam Shostack , nr1@ihug.co.nz, freebsd-security@FreeBSD.ORG Subject: Re: secure backup References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > PGP provides a password based encryption mode, just use that, you will > > still benefit from PGPs compression and checksumming facilities. > > Didn't know that. What cipher does it use? This feature has been available since PGP's early days. It uses PGP's default symmetric cipher. > > > Pass the data through three > > > rounds of bdes doing an encrypt, decrypt, followed by encrypt (with different > > > keys, of course) and you've got yourself 3DES, which bdes doesn't seem to do > > > natively. Make the keys random, and stick those in a PGP file if you like. > > > > If you assume PGP is available, why not just use it? Using bdes(1) in > > this setup sounds way more complicated (thus error-prone) to me. > > There's no /need/ to use PGP in this step - clearly you could do anything you > like with the local keys, such as printing them out, or storing them as > plaintext (or keeping a constant key used for multiple backups). I realize that. But using bdes(1) when you have PGP available is not a very good idea. Using bdes(1) actually never is a good idea because of it's crappy key handling (no hashing). bdes(1) allows you to shoot yourself in the foot without you realizing it. > > > Transport the data stream to the server using ssh -c none (no need for the > > > overhead of another encryption layer unless you're really paranoid) > > > > Just being cautious is enough. Adding a layer of SSH encryption will at > > least twarth offline dictionary attacks on the backup passphrase. > > Encryption is cheap, why disable it if you don't have to? > > If you use a random passphrase as in my suggestion then dictionary attacks are > worthless and you're only vulnerable to an (expensive) brute force keyspace > search. Encrypting the already encrypted stream doesn't buy you anything I can > see, except the extra CPU time. But it's not a big deal. Uhm, a dose of reality here: how many people will pick random passphrases of sufficient length? There is almost never reason to disable SSH encryption. Cheers, Jeroen -- Jeroen C. van Gelderen - jeroen@vangelderen.org - 0xC33EDFDE To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message