Date: Thu, 4 May 2000 14:10:47 -0400 From: "Crist J. Clark" <cjc@cc942873-a.ewndsr1.nj.home.com> To: "Andrew J. Korty" <ajk@iu.edu> Cc: security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) Message-ID: <20000504141047.B11123@cc942873-a.ewndsr1.nj.home.com> In-Reply-To: <Pine.BSF.4.21.0005031019190.21805-100000@kobayashi.uits.iupui.edu>; from ajk@iu.edu on Wed, May 03, 2000 at 10:33:32AM -0500 References: <Pine.BSF.4.21.0005031019190.21805-100000@kobayashi.uits.iupui.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, May 03, 2000 at 10:33:32AM -0500, Andrew J. Korty wrote: > I've just extended dump(8) and restore(8) to encipher dump lists > and inode data with CBC 3DES, leaving the headers as cleartext. > Keys can be entered from the tty or a cleartext file. The > purpose is to safely transport and store dumps containing > sensitive data. Everyone seems pretty excited about this possible extension to dump-restore, but I have a few IMHOs that do not seem to have come up in the thread. IMHO, secure transport and secure storage are two different issues. True, if the dump is encrypted from the get-go, secure transport is moot, but for me and for others I am sure, secure storage is not needed or desired. I don't want people peaking at dumps over the network, but as for the media, I use the physical security of the media (a safe or lockbox) rather than encryption. You may ask what's the problem with just adding the extra layer of encryption to the dump? First and foremost, is how to store the keys to the dumps securely. If I am making dumps for a company or other entity, it may not be me who is doing the restore. The electronic keys and any passwords involved must be documented. And they must be kept as long as the backups are kept. If you toss a floppy with the keys on it and a Post-It with the password in with your dump tapes, where is this added security? You need to lock all that up... so why not lock unencrypted tapes in the first place and skip the headaches. Tape, which still is the medium of choice for dumps (yes, others, including the ridiculously cheap HDD, are options), is not known for being the most reliable. If the process is not designed well, corruption on one small part of the tape renders the dump useless. If it is unencrypted, you can pull the raw data off of the dump and it could still be quite salvageable. Unfortunately, I saw in the thread that this solution "was needed yesterday." I hope that means things like recovery from partial media failure are not overlooked or sacrificed. Because, and this is another huge issue, if incompatibilities in the dump-restore process arise, your data may again be lost forever. Or we get dump-retore bloat for backcompatibility. This should be done right the first time... at least to within reason. Before I finish I want to say that this is by no means to say that I do not think this would be a very useful thing. For individuals who may find secure storage unacceptable and won't find documenting keys and passwords such a chore, it is a boon. What I really find facinating however, is the potential to backup data to an untrusted backup server. -- Crist J. Clark cjclark@home.com 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?20000504141047.B11123>