From owner-freebsd-security@FreeBSD.ORG Fri Jul 18 19:08:17 2014 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4BD8CAC for ; Fri, 18 Jul 2014 19:08:17 +0000 (UTC) Received: from mail-lb0-f177.google.com (mail-lb0-f177.google.com [209.85.217.177]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id B63C32472 for ; Fri, 18 Jul 2014 19:08:15 +0000 (UTC) Received: by mail-lb0-f177.google.com with SMTP id s7so3185455lbd.36 for ; Fri, 18 Jul 2014 12:08:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=B8aTfzEKbYGm0nbzmXCmlW1o9JL7m68DOaEBcsDHUCY=; b=TbriXyqo46wyzV7y1OsTv+N9Ps5I9Ai0sYx51ysqHLvMe2ujiAQPTB3B/E0B7ykUKF 3myPVJuYb677yxwqXf4p68Klyh+6b8FCEPHIbAdSpFTP+iIn7TP0uKR2M2yaP+3QQaOL o8NukGJn1a50ZysJ5QPHX0aFM0jvRgwQX6QjUf38evybEwGf4iWQwjVtaqQwjcVx4da5 FuBM6Vapg0SjFptHUCvplJdT5VpNPEn3cUFQXYzKGVjhDSzzj6pb0DMLeJNitqD9Mmdc OZ8jZ12gSXP2eiASpOJNONj1/3kPOE0rsRJffAO5nrAYQ/kvZmNgJU1a7+qrPK2nrDO8 fWhw== X-Gm-Message-State: ALoCoQnGTnyrSBs6AqF31t8Rc2Lzh8bEVKd1QBGdUNfvH7p4W3KOmjcFXR+0iPFvhssCqjg7W3a9 X-Received: by 10.152.25.229 with SMTP id f5mr7342236lag.87.1405710153191; Fri, 18 Jul 2014 12:02:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.112.149.65 with HTTP; Fri, 18 Jul 2014 12:01:53 -0700 (PDT) X-Originating-IP: [24.111.146.222] In-Reply-To: References: <53C85F42.1000704@pyro.eu.org> <4E23BEEA-693A-4FA3-BE94-9BB82B49503A@vpnc.org> From: Leif Pedersen Date: Fri, 18 Jul 2014 14:01:53 -0500 Message-ID: Subject: Re: Speed and security of /dev/urandom To: Paul Hoffman Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 Cc: "freebsd-security@freebsd.org" , Steven Chamberlain X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Security issues \[members-only posting\]" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Jul 2014 19:08:17 -0000 On Fri, Jul 18, 2014 at 1:28 PM, Paul Hoffman wrote: > On Jul 18, 2014, at 11:19 AM, Leif Pedersen wrote: > > > The extra readers interrupt the position of the stream, so that it is > harder to predict the next value. This only works if one instance of the > PRNG is shared by multiple readers, rather than each reader operating in > isolation. > > If there was a non-zero chance that an attacker could predict the next > value, your PRNG was already broken. Two of the fundamental properties of a > working PRNG is that if an attacker sees any number of outputs from the > PRNG, the attacker cannot compute any previous values and the attacker > cannot predict any future values. > > if(! fork()) { int x = next_value(); // Do something that depends on the sensitivity of x here. } else { // exec untrusted program here... // distrusted program: int x = next_value(); printf("Known value: %i\n", x); } This has nothing to do with the quality of the PRNG or being otherwise compromised. It's that after being seeded the PRNG operates in isolation and the memory space is cloned exactly. PRNGs run on computers which are currently deterministic, so there is no algorithm that can yield different values for x in the two branches. Crypto libraries frequently fork untrusted processes, for example sshd accept()s, fork()s, does crypto, switches users, and forks a shell. Every child would have the same initial state at the "does crypto" part, and so must be reseeded. Web servers work similarly. Apache is more complicated because one child accepts many connections, but ultimately they always terminate and are replace by another sibling which will have exactly the same initial state if there is no provision to reseed the PRNG. I believe one of Steven's points was (I'm fairly sure I understood him correctly) that neglecting to reseed after fork() has led to problems. - Leif -- As implied by email protocols, the information in this message is not confidential. Any middle-man or recipient may inspect, modify, copy, forward, reply to, delete, or filter email for any purpose unless said parties are otherwise obligated. As the sender, I acknowledge that I have a lower expectation of the control and privacy of this message than I would a post-card. Further, nothing in this message is legally binding without cryptographic evidence of its integrity. http://bilbo.hobbiton.org/wiki/Eat_My_Sig