From owner-freebsd-security Wed May 3 23:35:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from grimreaper.grondar.za (grimreaper.grondar.za [196.7.18.138]) by hub.freebsd.org (Postfix) with ESMTP id 93FB537BFAC for ; Wed, 3 May 2000 23:35:17 -0700 (PDT) (envelope-from mark@grondar.za) Received: from grimreaper.grondar.za (localhost [127.0.0.1]) by grimreaper.grondar.za (8.9.3/8.9.3) with ESMTP id IAA05693; Thu, 4 May 2000 08:35:13 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200005040635.IAA05693@grimreaper.grondar.za> To: "Andrew J. Korty" Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) References: In-Reply-To: ; from "Andrew J. Korty" "Wed, 03 May 2000 13:39:26 EST." Date: Thu, 04 May 2000 08:35:13 +0200 From: Mark Murray 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. > > 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. M -- Mark Murray Join the anti-SPAM movement: http://www.cauce.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message