Date: 03 May 2000 18:21:00 -0400 From: stanislav shalunov <shalunov@att.com> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: freebsd-security@freebsd.org Subject: Re: Cryptographic dump(8) Message-ID: <87snvz46nn.fsf@sharik.worldnet.att.net> In-Reply-To: Matthew Dillon's message of "Wed, 3 May 2000 10:18:40 -0700 (PDT)" References: <Pine.BSF.4.21.0005031019190.21805-100000@kobayashi.uits.iupui.edu> <200005031718.KAA63329@apollo.backplane.com>
index | next in thread | previous in thread | raw e-mail
Matthew Dillon <dillon@apollo.backplane.com> writes: > [random (16 bytes)][MD5 of entire header including random, not including > the MD5 itself] > [ .................. entire block is encrypted (entire header, including > random and MD5)] > > Restore would then decrypt the header using the user-supplied key, then > MD5 it and compare the MD5 against the decrypted MD5. Doesn't this seem too complex? Storing MD5 of the cleartext header as first two blocks is enough (and somewhat guards you against poor choice of IV, too; poor choice of IV isn't catastrophic with CBC). Mallory still can modify tape in the middle and you won't notice it. If you're happy with two passes for restore, you could put MD5 of the entire tape in the end. > Also, putting a random number in each block is important if each block > is separately encrypted, for the same reason. I'm afraid you've either missed the fact that he uses CBC, or might be missing the implications of this. How much random data do you want to put into an 8-byte block, anyway? > Using /dev/random to obtain your random numbers is considered to be > acceptable. The bandwidth of /dev/random is far too small even on busiest machines to provide (unnecessary) random data for each block. -- stanislav shalunov | Speaking only for myself. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the messagehelp
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?87snvz46nn.fsf>