From owner-freebsd-hackers@FreeBSD.ORG Sat Mar 5 20:04:25 2005 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2555416A4CE for ; Sat, 5 Mar 2005 20:04:25 +0000 (GMT) Received: from wiredyne.com (adsl-63-194-89-150.dsl.snfc21.pacbell.net [63.194.89.150]) by mx1.FreeBSD.org (Postfix) with SMTP id AF7D843D1D for ; Sat, 5 Mar 2005 20:04:24 +0000 (GMT) (envelope-from pdh@wiredyne.com) Received: (qmail 9981 invoked by uid 1009); 5 Mar 2005 20:04:46 -0000 Date: 5 Mar 2005 20:04:46 -0000 Message-ID: <20050305200446.9980.qmail@wiredyne.com> From: Peter Hendrickson To: Thor Lancelot Simon In-Reply-To: <20050303181044.GA6732@panix.com> References: <20050303165730.8931C3BFDBA@berkshire.machshav.com> <9418.1109872131@critter.freebsd.dk> <20050303181044.GA6732@panix.com> X-Mailman-Approved-At: Sun, 06 Mar 2005 12:58:25 +0000 cc: tech-security@netbsd.org cc: Poul-Henning Kamp cc: hackers@freebsd.org cc: cryptography@metzdowd.com Subject: Re: FUD about CGD and GBDE X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Mar 2005 20:04:25 -0000 Thor Lancelot Simon wrote: > I note that GBDE uses a number of algorithms in ways that are not > consistent with their design purposes. For instance, it truncates a > non-keyed hash (SHA512); the fact that this is not necessarily a > good idea is one of the major motivators for the design of HMAC. This is a widely accepted practice. RFC 2631 generates keys this way, using SHA-1. And aren't most /dev/random implementations outputting SHA-1 hashes? Users are expected to treat the output as a stream of random bits, so in most cases truncated hashes are used. It may not be a good idea, but Poul-Henning Kamp has not made a radical design decision here. Also, a problem with a keyed hash may not be a problem when generating key material from a secret. Let's say we use this as a keyed hash function: SHA-1(k || p). (k the key, p the plaintext to be authenticated.) This has the bad property that the attacker can easily forge signatures of the form SHA-1(k || p || x) where x is attacker supplied material. (The attacker does not need to know the value of k.) But this is a reasonable way to generate key material to drive a cipher. I will note that Kamp's design differs from RFC 2631's approach. Section 7.1 ("From passphrase to master key") of his paper describes the generation of three keys from one hash. RFC 2631 would generate these keys by doing three hash computations with a counter used to vary the input slightly and using the leftmost bits of the result. Intuitively, I like RFC 2631's approach better, but it would be interesting to know if there's a better reason to do it that way. Peter