Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:94378 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 56942 invoked from network); 4 Jul 2016 23:14:33 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 4 Jul 2016 23:14:33 -0000 Authentication-Results: pb1.pair.com smtp.mail=yohgaki@ohgaki.net; spf=pass; sender-id=pass Authentication-Results: pb1.pair.com header.from=yohgaki@ohgaki.net; sender-id=pass Received-SPF: pass (pb1.pair.com: domain ohgaki.net designates 180.42.98.130 as permitted sender) X-PHP-List-Original-Sender: yohgaki@ohgaki.net X-Host-Fingerprint: 180.42.98.130 ns1.es-i.jp Received: from [180.42.98.130] ([180.42.98.130:55419] helo=es-i.jp) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 99/43-30328-7DDEA775 for ; Mon, 04 Jul 2016 19:14:32 -0400 Received: (qmail 41225 invoked by uid 89); 4 Jul 2016 23:14:27 -0000 Received: from unknown (HELO mail-qk0-f170.google.com) (yohgaki@ohgaki.net@209.85.220.170) by 0 with ESMTPA; 4 Jul 2016 23:14:27 -0000 Received: by mail-qk0-f170.google.com with SMTP id u124so50151750qkh.2 for ; Mon, 04 Jul 2016 16:14:26 -0700 (PDT) X-Gm-Message-State: ALyK8tLgOLuaLyNrwBKeW5K0vqkdB8srfLS8n546iLH8303v2NJ3venK+74A08sn32kfw1lst62+dsSXu2s3Aw== X-Received: by 10.55.136.133 with SMTP id k127mr19969851qkd.20.1467674060879; Mon, 04 Jul 2016 16:14:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.140.17.33 with HTTP; Mon, 4 Jul 2016 16:13:41 -0700 (PDT) In-Reply-To: References: Date: Tue, 5 Jul 2016 08:13:41 +0900 X-Gmail-Original-Message-ID: Message-ID: To: Stanislav Malyshev Cc: "internals@lists.php.net" , danack@php.net Content-Type: text/plain; charset=UTF-8 Subject: Re: [RFC][VOTE] Session ID without hashing From: yohgaki@ohgaki.net (Yasuo Ohgaki) Hi Stas, Thank you for sharing opinion. Followings is mine. On Tue, Jul 5, 2016 at 7:23 AM, Stanislav Malyshev wrote: >> Could you share the reason why against this change? > > 1. I'm not sure exporting raw generator state is a good practice. I may > change my opinion on the subject if I hear from some security people > (I'm no crypto expert) that this is ok, then I may change my opinion. I think no one can guarantee security of CSPRNG on all platforms. "CS" means cryptographic safety and cryptographers recommends not to reinvent crypt related functions/features. > 2. Due to (1), I do not think it makes sense to do this change, because > we produce no benefit (session generation speed is not that important > since nobody generates millions of sessions at once) and create > potential problems. Current implementation is regenerating random hash string by using - PID - Time (Simple random function) - CSPRNG when it is available 10 years ago, I would agree with your opinion, since old PRNG is not as good as current one. Today, I don't see the reason why we should reinvent secure random bytes as we do now. I agree we should have some mitigations just in case a CSPRNG is broken badly. The patch uses 4 to 6 bits to generate readable string and read extra 60 bytes to hide raw PRNG state. This mitigation should be good enough for somewhat broken CSPRNG. In addition, even when CSPRNG generates the same random bytes, session module has collision detection and will not create the same session ID. I hope you and others are convinced by this explanation. Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net