Date: Fri, 5 May 2000 08:30:43 +1000 From: Peter Jeremy <peter.jeremy@alcatel.com.au> To: "Andrew J. Korty" <ajk@iu.edu> Cc: security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) Message-ID: <00May5.083045est.115878@border.alcanet.com.au> In-Reply-To: <Pine.BSF.4.21.0005031019190.21805-100000@kobayashi.uits.iupui.edu>; from ajk@iu.edu on Thu, May 04, 2000 at 01:34:31AM %2B1000 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 2000-May-04 01:34:31 +1000, "Andrew J. Korty" <ajk@iu.edu> 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. BTW, unless you're using H/W encryption, 3DES is quite slow - and will probably be the limiting factor in your dump/restore speed. This may or may not be an issue. If it is, you might like to look at alternative algorithms. Another comment that people haven't mentioned is that since you're dumping in a non-standard format, your restore program is critical. Remember to keep a couple of known-good copies around in an format you can get at - eg tar a copy of the restore onto the front of each backup, or build your own bootable, recovery CD including it. >The question: what is the best way to verify a key handed to >restore(8) to decipher a dump? Matt suggested storing an unencrypted hash of the unencrypted header, together with the encrypted header. Another option, if your key management (which you seem to have glossed over) can handle larger keys: Define the key as the concatenation of the 3DES key and 8 bytes of random data. Those 8 bytes are stored encrypted in the header. After decryption, verify that you get back the random data you started with. Peter 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?00May5.083045est.115878>