Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:83690 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 40517 invoked from network); 24 Feb 2015 19:32:12 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 24 Feb 2015 19:32:12 -0000 Authentication-Results: pb1.pair.com smtp.mail=pierre.php@gmail.com; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=pierre.php@gmail.com; sender-id=pass Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.216.169 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.169 mail-qc0-f169.google.com Received: from [209.85.216.169] ([209.85.216.169:42090] helo=mail-qc0-f169.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 6B/13-24698-BB1DCE45 for ; Tue, 24 Feb 2015 14:32:12 -0500 Received: by qcvp6 with SMTP id p6so18443773qcv.9 for ; Tue, 24 Feb 2015 11:32:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=D/cOQIZwrIkuisO+JizO31w1++AqfPexKwfZW7r4+qc=; b=BdJ6bG1p6U9XLuJUfSqxi6Thvf9DfPNmesZ5IT3x4JVc2a5XTHUAes36UX/KGCOYpk KhxmaRaJjFoBAjEqY6ju53mnhnIJ9LA5eHrSQQQR7LJV9jyoi5PDjX010aejR88fgdae hBWaXxhpy8E503TCmbqxVa0hW+ma3W1+g+H7T6dZ+boMmHlFCoymifc7QRYUOdWX5j3u DKlATmynaOM2bkQFkJPJYe5Aqd7mGyhtLfRuhHZ6e1pgt+a8hfWbcmNbt7FwiEeuzWtU +WSbYQpm+Lj5eeo7Xu0c8E1lWtDzegv6pLqOlC01W16E1QiKG48065nSV8BNDZermVGG 9VPQ== MIME-Version: 1.0 X-Received: by 10.140.238.13 with SMTP id j13mr40184172qhc.75.1424806323691; Tue, 24 Feb 2015 11:32:03 -0800 (PST) Received: by 10.96.39.195 with HTTP; Tue, 24 Feb 2015 11:32:03 -0800 (PST) In-Reply-To: References: Date: Tue, 24 Feb 2015 11:32:03 -0800 Message-ID: To: Leigh Cc: Sammy Kaye Powers , PHP internals Content-Type: multipart/alternative; boundary=001a1135883ecc31c5050fda9256 Subject: Re: [PHP-DEV] [RFC] [DISCUSSION] Reliable user-land CSPRNG From: pierre.php@gmail.com (Pierre Joye) --001a1135883ecc31c5050fda9256 Content-Type: text/plain; charset=UTF-8 On Feb 24, 2015 3:08 AM, "Leigh" wrote: > > On 24 February 2015 at 10:55, Pierre Joye wrote: > > It should use the session.entropy_file setting as it aims to be the exact > > same thing. It also allows custom entropy src (better ones for higher > > demands) as well. > > I disagree. We want to take responsibility away from the user to > choose the best source of entropy. The session.entropy_file setting > also does not allow arc4random to be used, which is a source of > cryptographic quality random without using a file descriptor. > Sorry, my reply could have been confusing. I was not trying to say It should use only this setting. However it should be able to use it. As it is a requirement and is part of the configure requirements to begin with. > In fact I had planned for a future RFC where we allow > session.entropy_file to use using random_bytes(). So the "best" source > is chosen automatically. (If you think there are better sources not > covered by this patch, please let me know, I would like it to be > complete) I rather prefer to be able to choose. Maybe make it system instead of INI_ALL if the users ability to choose wisely are questionable. > There is an aspect of this that has been left for "future work", but > if the list thinks it is important I can implement it for this RFC. > The issue is that on Linux it still does not provide a way of getting > random bytes without using a file descriptor. This is important for a > couple of reasons, 1) It means chroot environments don't require > /dev/*random 2) it prevents fd-exhaustion attacks that force lower > quality randomness. LibreSSL-portable has a very good implementation > of this using the Linux getrandom syscall (Kernel >= 3.17) that I can > phpise and include if we think it is necessary. It is all the same setting. What is done on windows can be applied on any other platforms. Either use a path or a method, it just works fine. There are many different RNG providers, daemons or other services. I have seen customers using some of them (together) to generate enough data for their needs (need a lot of entropy data). By enough data I mean to be 200% sure that the entropy is good enough at any time no matter how much data is being fetched. I am also unsure about random_get_int, why only integer? It is also important that doing so the results is per se not crypto safe anymore. But still handy for codes required random integers (or other types). If it is kept, I would also prefer to name it random_get_ instead, for clarity. Cheers, Pierre --001a1135883ecc31c5050fda9256--