From owner-freebsd-current@FreeBSD.ORG Mon Nov 14 20:58:56 2011 Return-Path: Delivered-To: current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B168F1065676; Mon, 14 Nov 2011 20:58:56 +0000 (UTC) (envelope-from das@freebsd.org) Received: from zim.MIT.EDU (ZIM.MIT.EDU [18.95.3.101]) by mx1.freebsd.org (Postfix) with ESMTP id 707228FC1A; Mon, 14 Nov 2011 20:58:56 +0000 (UTC) Received: from zim.MIT.EDU (localhost [127.0.0.1]) by zim.MIT.EDU (8.14.5/8.14.2) with ESMTP id pAEKwtuX059140; Mon, 14 Nov 2011 15:58:55 -0500 (EST) (envelope-from das@freebsd.org) Received: (from das@localhost) by zim.MIT.EDU (8.14.5/8.14.2/Submit) id pAEKwtTO059139; Mon, 14 Nov 2011 15:58:55 -0500 (EST) (envelope-from das@freebsd.org) Date: Mon, 14 Nov 2011 15:58:55 -0500 From: David Schultz To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org Message-ID: <20111114205855.GB58790@zim.MIT.EDU> Mail-Followup-To: Andrey Chernov , current@freebsd.org, secteam@freebsd.org References: <20080916140319.GA34447@nagual.pp.ru> <20080916201932.GA59781@zim.MIT.EDU> <20111112102241.GA75396@vniz.net> <20111112154135.GA21512@zim.MIT.EDU> <20111112171531.GA83419@vniz.net> <20111114013004.GA53392@zim.MIT.EDU> <20111114192721.GA16834@vniz.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20111114192721.GA16834@vniz.net> Cc: Subject: Re: Is fork() hook ever possible? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Nov 2011 20:58:56 -0000 On Mon, Nov 14, 2011, Andrey Chernov wrote: > 1) We should use > mib[0] = CTL_KERN; > mib[1] = KERN_ARND; > > len = sizeof(rnd); > sysctl(mib, 2, rnd, &len, NULL, 0); > here instead of /dev/random, like OpenBSD did. It helps jails, and > re-stearing not happens too often in anycase. Obviously it minimizes > OpenBSD diffs too. Yes, that was in my list of suggested follow-on work, but I don't have time for it right now. > > the IV. In arc4_stir(), I also fixed the bug where the wrong > > buffer size was being passed to arc4_addrandom(), resulting in > > entropy loss. That change should be committed separately. > > 2) I already explain this moment before. There is no bug here but > intentional hack using time and pid entropy for stearing when read is > fail: time/pid are at the beginning of the struct, successful read happens > at the beginning of the struct too and beginning of the struct is passed > as the key too. Key is always fixed KEYSIZE bytes. > > In your new patch you pass unneded stack garbadge at the beginning of the > struct (often 0-s) in case good entropy is successfully readed into > rdat.rnd, moreover, you pass more then KEYSIZE bytes - sizeof(rdat). No, the "unneeded stack garbage" was passed in before. The difference is that previously you were calling arc4_addrandom() with a 148-byte struct rdat and a length parameter of 128 bytes. The result was that the last 20 bytes of the key obtained from /dev/random were unused. It's actually worrisome that you've got the predictable part of the key (pid and timestamp) first. The known-key attacks on RC4 that were used to break WEP rely on exactly this type of key. Specifically, because of the way the key scheduling algorithm works, the first few bytes of the state are strongly correlated with the first few bytes of the key. > 3) (optional) I think we can lover initial permutations from our 1024 to > at least OpenBSD's 256 here: > for (i = 0; i < 1024; i++) > (void)arc4_getbyte(); > In my initial commit attemps I post several references to publicly > available mathematical researches calculating estimated initial > permutation count, some paper allows even 128. They can be found in the > commit log. The revision history shows that you changed that parameter from 256 to 1024 to 512 to 768 to 1024 again. I'm not inclined to change it yet again unless an actual cryptographer weighs in and proscribes an appropriate level of paranoia. For what it's worth, I believe the attack you cited in the comments is unlikely to matter, assuming the initialization issue I mentioned above is fixed. arc4random() uses a larger-than-usual key size (1024 bits instead of the 64-128 used in most RC4 implementations). Thus, an attacker who can correlate the keystream with the first few bytes of the key gains negligible advantage, assuming that the key itself is random. But I'm not sufficiently well versed in the RC4 key schedule to preach that as the gospel truth.