From owner-freebsd-security Thu May 4 11:33:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from verbal.uits.iupui.edu (dhcp-uits-18-12.uits.indiana.edu [129.79.18.12]) by hub.freebsd.org (Postfix) with ESMTP id B63F537C335 for ; Thu, 4 May 2000 11:33:23 -0700 (PDT) (envelope-from ajk@iu.edu) Received: from localhost (ajk@localhost) by verbal.uits.iupui.edu (8.9.3/8.9.3) with ESMTP id NAA26542; Thu, 4 May 2000 13:31:15 -0500 (EST) (envelope-from ajk@iu.edu) X-Authentication-Warning: verbal.uits.iupui.edu: ajk owned process doing -bs Date: Thu, 4 May 2000 13:31:15 -0500 (EST) From: "Andrew J. Korty" X-Sender: ajk@verbal.uits.iupui.edu To: Mark Murray Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) In-Reply-To: <200005040635.IAA05693@grimreaper.grondar.za> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > > 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