Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72021 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 34715 invoked from network); 2 Feb 2014 22:59:13 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 2 Feb 2014 22:59:13 -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.170 as permitted sender) X-PHP-List-Original-Sender: pierre.php@gmail.com X-Host-Fingerprint: 209.85.216.170 mail-qc0-f170.google.com Received: from [209.85.216.170] ([209.85.216.170:55209] helo=mail-qc0-f170.google.com) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 2E/05-30967-0CDCEE25 for ; Sun, 02 Feb 2014 17:59:13 -0500 Received: by mail-qc0-f170.google.com with SMTP id e9so10366425qcy.29 for ; Sun, 02 Feb 2014 14:59:09 -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=on4yde0y11M7US+Y1xFLPnhE5zJPW8WH33EKs/syCgY=; b=BOb2CPQR7ZNMeFPRLz2TN0CzFYoH+a/aT8FgbVBVzSytZ/Ih2Fe8zdsHO0loIBpQrU ETvnulSVn4/sKwny6FN2+xCCsZG4lYZNoPjeUaaqUJMzVTEV/MSKSG0tQ9y9lOFQznPM gjlxY10xt8xZn8bgCcqxI6NbxChbEfYWTWnmptqVGeWpAzBgHrYxajhp5IhPdb9Qa6EC t5FiQgAH3ZrX5vGnfh/y1erHk59ZtcHCIMeV0h7mZjF6ICWKWGWaHspZY7HiPuzwCf82 A9JHVxG/IUXdQMUFDk5MyBw//WMtGmbuXg7LKaf/kA0whlvumRHABZmpXNVuyGAHCtCI iQzQ== MIME-Version: 1.0 X-Received: by 10.224.98.212 with SMTP id r20mr51805517qan.0.1391381949911; Sun, 02 Feb 2014 14:59:09 -0800 (PST) Received: by 10.140.18.129 with HTTP; Sun, 2 Feb 2014 14:59:09 -0800 (PST) In-Reply-To: References: <52EE1EDC.2010309@sugarcrm.com> Date: Sun, 2 Feb 2014 23:59:09 +0100 Message-ID: To: Yasuo Ohgaki Cc: PHP internals , Stas Malyshev Content-Type: multipart/alternative; boundary=089e0149d0d0df162604f1745a82 Subject: Re: [PHP-DEV] Extending uniqid() or not? From: pierre.php@gmail.com (Pierre Joye) --089e0149d0d0df162604f1745a82 Content-Type: text/plain; charset=UTF-8 On Feb 2, 2014 11:09 PM, "Yasuo Ohgaki" wrote: > User may use it. IV should be random bytes and it can be used as > secure source for hash. I does almost the same thing that I would > like to do. Issues are > > - it does not auto detect RNG and use /dev/random by default > - it does not support /dev/arandom > - it uses php_rand() to create random bytes if source option is not RANDOM > or URANDOM > - it is not an available function by default... > > 1st issue is not a issue actually. I think this is good that it uses > /dev/random by default > even if it may block script. As a crypt module, it should use most secure > source by default. We may improve mcrypt_create_iv() a little by raising > E_NOTICE > error when user set source other than RANDOM or URANDOM, and add ARANDOM > as a source. > > Even though mcrypt_create_iv() good enough for it's original purpose, it's > not good as > a general (fool proof) method for generating random bytes as it can block > script execution. It is exactly because of of its blocking nature when the entropy source is not sufficient that it is secure. This is the root difference between urandom and random (or the likes). > My question is if we should extend uniqid() or add new function that > actually > generates safe ID string. We may add more description to uniqid() page, > mcrypt and However we really do not crypto safe random bytes for this purpose. urandom and similar are enough for session hash data or unique id. Non crypto safe RNGs are not necessary unsafe, only not safe enough for cryptography related operations, unique IDs is not a cryptography related operation. > Do you prefer documentation rather than extending uniqid() or new function? I think better documentation is a good solution. Cheers, Pierre --089e0149d0d0df162604f1745a82--