From owner-freebsd-security Thu May 4 13:22:30 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 F2F8137C254 for ; Thu, 4 May 2000 13:22:16 -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 WAA07642; Thu, 4 May 2000 22:22:23 +0200 (SAST) (envelope-from mark@grimreaper.grondar.za) Message-Id: <200005042022.WAA07642@grimreaper.grondar.za> To: "Andrew J. Korty" Cc: security@FreeBSD.ORG Subject: Re: Cryptographic dump(8) References: In-Reply-To: ; from "Andrew J. Korty" "Thu, 04 May 2000 13:31:15 EST." Date: Thu, 04 May 2000 22:22:23 +0200 From: Mark Murray Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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. You are thinking about this in very much the right way! :-) > 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. ...Unless you could flag it in some creative way "the rest of this is encrypted; sod off"? > The reason for the separation is so that one corrupted block does > not render the entire tape useless. Could you break it in a way that would not compromise the crypto; that is break the stream at ${count} ${units}, rather than at "logical" boundaries, in such a way that the stream can be recovered at some point at the expense of maybe losing a ${block} if it contains a corruption? 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