Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72600 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 26563 invoked from network); 14 Feb 2014 14:54:59 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 14 Feb 2014 14:54:59 -0000 Authentication-Results: pb1.pair.com header.from=narf@devilix.net; sender-id=pass Authentication-Results: pb1.pair.com smtp.mail=narf@devilix.net; spf=pass; sender-id=pass Received-SPF: pass (pb1.pair.com: domain devilix.net designates 209.85.213.52 as permitted sender) X-PHP-List-Original-Sender: narf@devilix.net X-Host-Fingerprint: 209.85.213.52 mail-yh0-f52.google.com Received: from [209.85.213.52] ([209.85.213.52:57352] helo=mail-yh0-f52.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 72/13-09381-24E2EF25 for ; Fri, 14 Feb 2014 09:54:59 -0500 Received: by mail-yh0-f52.google.com with SMTP id a41so11598171yho.39 for ; Fri, 14 Feb 2014 06:54:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=devilix.net; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lFrIzEbE9gVScYxHQCvlDylF/MZbv9/GNM1PV+G34Rw=; b=dxkMQ3a0obnH6Pq101o9q7Uj8quy9w4K4RsrZLU4xitwFiRMBbXBo69ejpcL98Lp30 KNHSFpG/B0MsCKYg+x6FOCWd5DY7OnzN7vMbZFmJ0MncqaEvA06sPq/NQtD6isds+zRk o1gOZtAjdaZggyykw+KDK0RUXLBKD9eGFdDMM= 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:date :message-id:subject:from:to:cc:content-type; bh=lFrIzEbE9gVScYxHQCvlDylF/MZbv9/GNM1PV+G34Rw=; b=GHMYvOgmATVpvzd1RUhUyK/yaSNO55xaxN5jbUNKcR16CVKtpSQ+QsNoLND2yfi4lU gNmoakxNUGOf40RA+ETQ04lmYG0UO0vLemoFCdHTxt10GLZDX+SImOhC3KWYuAVp9Bn1 XWR5T4vbhIK/j27MhoUrinM9rhHXISFxApsi/OnCz1c6IDWegOBWoEvXNM+1mZffc3qM fC3sjE2EHATSOsAzvNsDP1lY6oDDAjwQIfJiiPArDtbxK0wuglKWRxM+BCURxkU+Wgwv kErhFjOUT0l2a2ScsoXb7uhmb4nF+7PMD8Bm3jSLc39kE5fsNn4ZWXM3qUpSAnAkvudh gt7A== X-Gm-Message-State: ALoCoQmOZN1kKwG8W+dV5u2hhAERXa1LIqAi6HY37CACRnHUvzLosSuOV+GNHJGAeXpy7T+ytEDp MIME-Version: 1.0 X-Received: by 10.236.216.106 with SMTP id f100mr519784yhp.129.1392389694061; Fri, 14 Feb 2014 06:54:54 -0800 (PST) Received: by 10.170.49.147 with HTTP; Fri, 14 Feb 2014 06:54:54 -0800 (PST) In-Reply-To: References: Date: Fri, 14 Feb 2014 16:54:54 +0200 Message-ID: To: Jakub Zelenka Cc: Pierre Joye , PHP internals Content-Type: text/plain; charset=UTF-8 Subject: Re: [PHP-DEV] unify entropy source for all php related functions From: narf@devilix.net (Andrey Andreev) On Fri, Feb 14, 2014 at 4:19 PM, Jakub Zelenka wrote: > On Fri, Feb 14, 2014 at 1:53 PM, Pierre Joye wrote: >> >> On Feb 14, 2014 8:02 PM, "Andrey Andreev" wrote: >> >> > So how does openssl_random_pseudo_bytes() work without blocking then? >> >> Because it tells you if the result is crypto safe or not: >> >> string *openssl_random_pseudo_bytes* (int $length [, bool &$crypto_strong] >> ) >> >> >> If you want only crypto safe result another function has to be used (on >> opennssl). And my test.php that was pasted shows that it dumps TRUE for $crypto_strong, while mcrypt_create_iv() blocks. > That's not the way how it works in md_rand. The ssleay_rand_pseudo_bytes > (Rand_psedobytes called in openssl_random_pseudo_bytes) is just a wrapper > for ssleay_rand_bytes with pseudo flag set to 1. ssleay_rand_bytes first > calls Rand_poll that adds the entropy. The thing is that the entropy is > taken from /dev/urandom on Unix. It means you will always have enough > entropy on Linux and the functions returns 1 ($crypto_strong is set to > true). You won't get false on Linux though. The reason of the flag in > OpenSSL is if you run it in on some platform that can't provide enough > entropy which is not the case on Linux. Please see the sources for more > details. Sorry, I'm not really sure what this means, but 2 few bits that I spot are: - on UNIX(-like), it uses /dev/urandom - $crypto_strong will always be true on Linux (UNIX-whatever) And Pierre Joye says that /dev/urandom is not crypto-safe, so this kind of gets us in a conflict ... which one is it? The way I understand it, only /dev/whatever (meaning that it should be hardware input) could be considered crypto-safe and so if OpenSSL always returns without blocking, yet sets $crypto_strong to TRUE, then the same should be possible for PHP itself to do. That is, unless $crypto_strong is set to TRUE without the output actually being crypto-safe, in which case we have a bug. P.S.: Sorry folks, I didn't want to turn this into a "how OpenSSL works" thread. Cheers, Andrey.