Date: Thu, 4 May 2000 13:31:15 -0500 (EST) From: "Andrew J. Korty" <ajk@iu.edu> To: Mark Murray <mark@grondar.za> Cc: Matthew Dillon <dillon@apollo.backplane.com>, security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) Message-ID: <Pine.BSF.4.21.0005041323480.26511-100000@verbal.uits.iupui.edu> In-Reply-To: <200005040635.IAA05693@grimreaper.grondar.za>
next in thread | previous in thread | raw e-mail | index | archive | help
> > That sounds good, but I should probably leave the very first > > header as cleartext. That way, I can put a flag there to tell > > restore whether or not this tape is encrypted or not. > > Fair enough. I'm starting to second guess this decision, since an attacker could get inode numbers from the cleartext headers and perform known-text attacks by guessing which binaries have those inode numbers. If I need to put the random string at the beginning of the header, then we're throwing the old file format out the window anyway, so I might as well encrypt everything. > > > Also, putting a random number in each block is important if each block > > > is separately encrypted, for the same reason. > > > > Would it be acceptable to encrypt the header and block together > > but each header/block pair separately? I don't think I have room > > to add anything in the block, so maybe I could get that randomness > > from what I add to the header (CBC should propagate it a little). > > The more you separate, the better chance you give for certain types of > attacks; you are not giving much at all, but you are adding a tiny > weakness. Attackers can use anything "known" about the structure > of the data, and you are giving them the boundaries. The reason for the separation is so that one corrupted block does not render the entire tape useless. -- Andrew J. Korty, Lead Security Engineer Office of the Vice President for Information Technology Indiana University 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?Pine.BSF.4.21.0005041323480.26511-100000>