From owner-freebsd-hackers@FreeBSD.ORG Sat Apr 19 19:30:21 2008 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id AA70D106566C for ; Sat, 19 Apr 2008 19:30:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) Received: from 0.mx.codelabs.ru (0.mx.codelabs.ru [144.206.177.45]) by mx1.freebsd.org (Postfix) with ESMTP id 593808FC2B for ; Sat, 19 Apr 2008 19:30:21 +0000 (UTC) (envelope-from rea-fbsd@codelabs.ru) DomainKey-Signature: a=rsa-sha1; q=dns; c=simple; s=one; d=codelabs.ru; h=Received:Date:From:To:Cc:Message-ID:References:MIME-Version:Content-Type:Content-Disposition:In-Reply-To:Sender:Subject; b=ZDth4WBnG/l4OjKYjLlF9e/qTjwc3I1Gr9qMSsIcqXMadH6JY9uOEOaL0CKzWN4U07OdFdXz2aERFnqFBhTfa875g5Nk2I9lzLlFb53OkHeXYth8Hwv+xhoEdUgIJpq8yEmHgBFzM3oA2kJ9YWBrQCaX31Ds8+f+I/CU75Gl/UI=; Received: from amnesiac.at.no.dns (ppp83-237-104-51.pppoe.mtu-net.ru [83.237.104.51]) by 0.mx.codelabs.ru with esmtpsa (TLSv1:AES256-SHA:256) id 1JnIlP-000ONp-Pr; Sat, 19 Apr 2008 23:30:19 +0400 Date: Sat, 19 Apr 2008 23:30:23 +0400 From: Eygene Ryabinkin To: RW Message-ID: References: <20080419175655.51a37bb2@gumby.homeunix.com.> MIME-Version: 1.0 Content-Type: text/plain; charset=koi8-r Content-Disposition: inline In-Reply-To: <20080419175655.51a37bb2@gumby.homeunix.com.> Sender: rea-fbsd@codelabs.ru Cc: freebsd-hackers@freebsd.org Subject: Re: Yarrow's Counter X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Apr 2008 19:30:21 -0000 Good day. Sat, Apr 19, 2008 at 05:56:55PM +0100, RW wrote: > The random number generator in FreeBSD's Yarrow implementation uses > AES256 in counter mode. When a reseed occurs the generator is > reinitialised like this: > > - generate a new cypher-key from the pool[s] and the old key > - zero the counter > - encrypt the (zeroed) counter with the new key The latter two are better explained as "generate new counter as the result of encryption of a number 'zero' with the new key". > My question is: why zero the counter? It is per paper about Yarrow design: see http://www.schneier.com/paper-yarrow.html page 11, section 5.3, step 4. > If it's not zeroed then the old counter is encrypted instead, and after > a few reseeds the counter will accumulate an independent 256 bits of > entropy, rather than being a function of the new key. As the seventh paragraph of section 5.3 says, "There is no security reason why we would set a new value for the counter C". And deriving the new value of C from the old one will not add any additional entropy -- you're producing the old C and new key from the same "entropy source", so this won't give you more entropy: you have two dependent values. Moreover, as the last paragraph of page 9 says "...the counter value C is assumed to be known to the attacker", Yarrow was designed with this motto in mind. As I see it, the key reasoning is that for the perfect encryption function in the counter mode, there is no reason to keep the counter to be secret: it is just nonce, nothing more. Only the key should be kept safe. > Should I submit a patch, it's simply a matter of deleting two > lines in reseed() in sys/dev/random/yarrow.c. > > > yarrow_hash_finish(&context, temp); > yarrow_encrypt_init(&random_state.key, temp); > > /* 4. Recompute the counter */ > > for (i = 0; i < 4; i++) <--- > random_state.counter[i] = 0; <--- > > yarrow_encrypt(&random_state.key, random_state.counter, temp); > memcpy(random_state.counter, temp, sizeof(random_state.counter)); I would not do it without consultations with Yarrow's creators: this modification seems not to help anything, but can break something. But your mileage may vary, as usual ;)) -- Eygene