From: "Jeroen C. van Gelderen" <jeroen@vangelderen.org> To: Kris Kennaway <kkennawa@physics.adelaide.edu.au> Cc: Adam Shostack <adam@breakwater.homeport.org>, nr1@ihug.co.nz, freebsd-security@FreeBSD.ORG Subject: Re: secure backup Message-ID: <37402654.EE74B389@vangelderen.org> References: <Pine.OSF.4.10.9905172327060.9205-100000@bragg>
next in thread | previous in thread | raw e-mail | index | archive | help
Kris Kennaway wrote: > > On Mon, 17 May 1999, Jeroen C. van Gelderen wrote: > > > This feature has been available since PGP's early days. It > > uses PGP's default symmetric cipher. > > Which is what? I don't have PGP handy here.. IIRC IDEA for the 2.x series. CAST5 (default), TripleDES or IDEA for the 5.x/6.x versions. > > 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. > > Can you elaborate on this? Apart from the fact that bdes expects keys to be > given on the command line for non-interactive use (and not taken from a file, > which should be an easy hack to make), what's wrong with it? The problem is the people that use it: they pick non-random passwords. If you are *very* lucky, a password has 6 bits of entropy per character, you can only enter 8 characters -> 48 bits. This assumes a random distribution over 64 characters, quite unlikely. One (partial) solution is to accept longer passphrases, hashing them down to 56 bits of DES key. If you use a cryptographically strong hash function (SHA-1) it will preserve the entropy from the given password. Another advantage of this approach is that you can introduce salt and/or multiple hashing to slow down brute force attacks. And -chances are small but not non-existent- it is possible to choose DES weak keys, something that PGP automatically avoids for you. PGP delivers all these 'advanced' techniques in a reputable program. So you'd better benefit from all the expertise that's been put into PGP than invent yourself a scheme. > > > 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. > > Yes, but the original problem related to a non-interactive tape backup. There > is no reason to have the encryption key as a human-memorable phrase; on the > contrary it's much better to make it a machine-generated random string of the > sufficient length. How many people do this? You will have to restore the backup at some point in the future. And at that point in time, access to the vault (where the paper with the passwords is) may not be available. There's a subtle difference between theory and practice here. Cheers, Jeroen PS. s/PGP/GnuPG/ if you want. -- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?37402654.EE74B389>