Hi all,
On Thu, Feb 2, 2017 at 12:47 PM, Yasuo Ohgaki wrote:
>
> Posting RFC draft before discussion
>
> https://wiki.php.net/rfc/improve_predictable_prng_random
>
> This RFC includes results of recent PRNG related discussions.
> I would like to keep it simple, but basic object feature will be
>
Hi Niklas,
On Thu, Feb 2, 2017 at 11:05 PM, Niklas Keller wrote:
> 2017-02-02 14:24 GMT+01:00 Christoph M. Becker :
>
>> On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
>>
>> > Although users must never do this, but there are codes that generate
>> random
>> > password/access key by mt_rand().
>>
>>
On Thu, Feb 2, 2017 at 10:24 PM, Christoph M. Becker
wrote:
> On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
>
> > Although users must never do this, but there are codes that generate
> random
> > password/access key by mt_rand().
>
> There is also code that stores clear text passwords. How would y
2017-02-02 14:24 GMT+01:00 Christoph M. Becker :
> On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
>
> > Although users must never do this, but there are codes that generate
> random
> > password/access key by mt_rand().
>
> There is also code that stores clear text passwords. How would you
> prevent
On 02.02.2017 at 12:51, Yasuo Ohgaki wrote:
> Although users must never do this, but there are codes that generate random
> password/access key by mt_rand().
There is also code that stores clear text passwords. How would you
prevent that?
IMHO, if users don't care to read the docs[1], it's thei
Hi Lauri,
On Thu, Feb 2, 2017 at 6:54 PM, Lauri Kenttä wrote:
> I think this RFC is badly prepared. You're overhauling the whole mt_rand
> system in one go, but you're not doing it properly. There is no
> justification for breaking compability, not in 7.x and not even in 8.0 in
> my opinion.
>
On 2017-02-02 05:47, Yasuo Ohgaki wrote:
Posting RFC draft before discussion
https://wiki.php.net/rfc/improve_predictable_prng_random
This RFC includes results of recent PRNG related discussions.
I would like to keep it simple, but basic object feature will be
implemented.
Methods could raise
>
> Posting RFC draft before discussion
>
> https://wiki.php.net/rfc/improve_predictable_prng_random
>
> This RFC includes results of recent PRNG related discussions.
> I would like to keep it simple, but basic object feature will be
> implemented.
>
> Methods could raise exceptions for invalid ope
Hi all,
On Mon, Jan 30, 2017 at 7:54 PM, Yasuo Ohgaki wrote:
> On Mon, Jan 30, 2017 at 7:47 PM, Yasuo Ohgaki wrote:
>
>> On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
>> wrote:
>>
>>> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>>>
I'll prepare patch that allows int array
initialization
On Mon, Jan 30, 2017 at 7:47 PM, Yasuo Ohgaki wrote:
> On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
> wrote:
>
>> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>>
>>> I'll prepare patch that allows int array
>>> initialization for mt_srand() so that whole state buffer can be
>>> initialized as user
Hi Lauri,
On Mon, Jan 30, 2017 at 7:41 PM, Lauri Kenttä
wrote:
> On 2017-01-30 04:25, Yasuo Ohgaki wrote:
>
>> I'll prepare patch that allows int array
>> initialization for mt_srand() so that whole state buffer can be
>> initialized as user specifies.
>>
>
> Don't.
>
> See these:
> https://gith
On 2017-01-30 04:25, Yasuo Ohgaki wrote:
I'll prepare patch that allows int array
initialization for mt_srand() so that whole state buffer can be
initialized as user specifies.
Don't.
See these:
https://github.com/php/php-src/pull/2089
https://www.mail-archive.com/internals@lists.php.net/msg87
Hi all,
On Mon, Jan 30, 2017 at 11:25 AM, Yasuo Ohgaki wrote:
> Our part could be fixed by us. Let's fix it now.
>
> Lauri made patch for unseeded mt_rand(). I'll prepare patch that allows
> int array
> initialization for mt_srand() so that whole state buffer can be
> initialized as user specifi
Hi all,
On Mon, Jan 30, 2017 at 10:08 AM, Yasuo Ohgaki wrote:
> Issues are
>> - Current mt_rand() is not fully exploited. It wastes more than 99% of its
>> random cycle.
>>
>> This was discussed in Aug last year and dropped.
>>
> I didn't notice the discussion, let's discuss again.
>
> It does n
Hi Tom,
On Mon, Jan 30, 2017 at 1:22 AM, Tom Worster wrote:
> On 1/28/17 4:32 PM, Yasuo Ohgaki wrote:
>
> Could you give some examples?
>
> I'm not sure what kind of IoT devices/OS that support PHP do not have
> CSPRNG.
>
> I'm sorry, my reply ended up with subject "Re: internals Digest 27 Jan
>
On 1/28/17 4:32 PM, Yasuo Ohgaki wrote:
Could you give some examples?
I'm not sure what kind of IoT devices/OS that support PHP do not have
CSPRNG.
I'm sorry, my reply ended up with subject "Re: internals Digest 27 Jan
2017 10:58:15 - Issue 4425". My fault. I'll copy it here...
There a
Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entropy environments exist. The problem
>
Hi all,
On Wed, Jan 18, 2017 at 3:04 PM, Yasuo Ohgaki wrote:
> The patch initializes the full MT state vector, approximately 2.5KB of
>> memory, from a CSPRNG. To put this into perspective, 16 bytes are generally
>> considered to be sufficient for cryptographic keying material. Does this
>> seem
On 2017-01-27 17:13, Leigh wrote:
On 27 January 2017 at 14:30, Lauri Kenttä
wrote:
This needs to be thought of as 2^32 possible _streams_ with a period
of (2^19937)−1. Offset within the stream is as important as the
stream
variation itself.
This is not true. There is one stream of period (2
On 27 January 2017 at 14:30, Lauri Kenttä wrote:
>> This needs to be thought of as 2^32 possible _streams_ with a period
>> of (2^19937)−1. Offset within the stream is as important as the stream
>> variation itself.
>
> This is not true. There is one stream of period (2^19937)−1, and
> the initial
On 2017-01-27 12:58, Leigh wrote:
On 27 January 2017 at 02:52, Yasuo Ohgaki wrote:
Since mt_rand is predictable PRNG, there is possibility to be known to
attackers always.
What I would like to change is
- there is only 2^32 initial states
This needs to be thought of as 2^32 possible _strea
On 27 January 2017 at 02:52, Yasuo Ohgaki wrote:
> Since mt_rand is predictable PRNG, there is possibility to be known to
> attackers always.
>
> What I would like to change is
>
> - there is only 2^32 initial states
This needs to be thought of as 2^32 possible _streams_ with a period
of (2^1993
Hi Tom,
On Sun, Jan 22, 2017 at 1:26 AM, Tom Worster wrote:
> On 1/20/17 9:55 PM, Yasuo Ohgaki wrote:
>
>> CSPRNG failure is like BUS error, i.e. hardware error. CSPRNG shouldn't
>> fail with healthy hardware/OS.
>>
>
> One would like to think so but low entropy environments exist. The problem
>
Hi Leigh,
On Sun, Jan 22, 2017 at 6:40 PM, Leigh wrote:
> On Sat, 21 Jan 2017 at 14:41 Niklas Keller wrote:
>
>> Anyway, the "issue" with mt_rand is not the seed being predictable but
>> the internal state being recoverable from the output. But mt_rand is
>> predictable by design, so why shoul
On Sat, 21 Jan 2017 at 14:41 Niklas Keller wrote:
> Anyway, the "issue" with mt_rand is not the seed being predictable but the
> internal state being recoverable from the output. But mt_rand is
> predictable by design, so why should we even seed it with a CSPRNG by
> default?
>
>
> For the record
>
> > Anyway, unusable CSPRNG is very unlikely to happen. I may just use
> > UNEXPECTED macro for the if branch.
> >
>
> I changed my mind due to comment for uniqid() CSPRNG usage.
>
> IMO, there is no benefit for CSPRNG failure fallback. We shouldn't add
> fackback for every CSPRNG usage.
Right,
On 16.01.2017 at 08:04, Yasuo Ohgaki wrote:
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_rand.h
> #ifdef
Hi,
On Sat, Jan 21, 2017 at 11:12 AM, Yasuo Ohgaki wrote:
> On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
> wrote:
>
>> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>>
>>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>>> today's
>>> standard requires working CSPRNG, doesn't it?
Hi Lauri and Leigh,
On Thu, Jan 19, 2017 at 10:37 PM, Lauri Kenttä
wrote:
> On 2017-01-19 13:46, Yasuo Ohgaki wrote:
>
>> However, PHP as a whole cannot work reliable way w/o CSPRNG and
>> today's
>> standard requires working CSPRNG, doesn't it?
>>
>
> No.
>
> Why do you think that PHP can't wor
On 19 January 2017 at 11:46, Yasuo Ohgaki wrote:
> How many of us are willing to allow very weak mt_rand fallback?
> This could be RFC vote option, if there are few.
Everyone who cares about stability.
I agree, if you want to introduce breaking changes, this needs to go to RFC.
Therefore the si
On 2017-01-19 13:46, Yasuo Ohgaki wrote:
However, PHP as a whole cannot work reliable way w/o CSPRNG and
today's
standard requires working CSPRNG, doesn't it?
No.
Why do you think that PHP can't work without CSPRNG?
PHP is a general-purpose programming language. It can be used in a
closed en
Hi Leigh,
On Thu, Jan 19, 2017 at 8:25 PM, Leigh wrote:
>
> You _do_ have to care if it fails. This is a breaking change if it is
> not handled. mt_rand is _not_ a CSPRNG, and therefore the absence of a
> CSPRNG should not make mt_rand unusable.
If we consider mt_rand only, your statement is t
On 19 January 2017 at 01:10, Yasuo Ohgaki wrote:
>
> Thank you. I have to be able to modify patch, so I'll fetch your change to
> my repo
> and make PR. BTW, I don't think we have to care for failing CSPRNG. If it
> failed,
> application should fail properly, i.e. should terminate process/code.
>
Hi Lauri,
On Thu, Jan 19, 2017 at 1:06 AM, Lauri Kenttä
wrote:
> On 2017-01-18 08:04, Yasuo Ohgaki wrote:
>
>> Lauri,
>> You wrote the patch. Could you make Pull Request to github's php-src
>> repo?If you prefer not to, I'll make the PR.
>>
>> I think your patch should be applied from PHP-7.0 br
On 18 January 2017 at 16:06, Lauri Kenttä wrote:
>
> If it's not acceptable to randomize the whole state, I'd recommend using
> php_random_int_silent() to generate a single seed. This would be easy to
> implement by simply changing GENERATE_SEED() into a function which first
> tries php_random_int
On Wed, Jan 18, 2017 at 10:22 AM, Nikita Popov
The patch initializes the full MT state vector, approximately 2.5KB
of memory, from a CSPRNG. To put this into perspective, 16 bytes are
generally considered to be sufficient for cryptographic keying
material. Does this seem somewhat disproportionat
On Wed, 18 Jan 2017 at 06:05 Yasuo Ohgaki wrote:
> It could be. I haven't read and research MT rand initialization code
> carefully yet.
I have, it stretches 4 bytes of seed material into 624 * 4 bytes of
material. There are only 2^32 possible initial states from direct seeding.
After the stat
On Wed, Jan 18, 2017 at 10:22 AM, Nikita Popov wrote:
> On Wed, Jan 18, 2017 at 1:44 AM, Yasuo Ohgaki wrote:
>
>> Hi Lauri,
>>
>> On Tue, Jan 17, 2017 at 11:59 PM, Lauri Kenttä
>> wrote:
>>
>> > On 2017-01-17 16:18, Lauri Kenttä wrote:
>> >
>> >> On 2017-01-17 02:34, Yasuo Ohgaki wrote:
>> >>
>
On Wed, Jan 18, 2017 at 1:44 AM, Yasuo Ohgaki wrote:
> Hi Lauri,
>
> On Tue, Jan 17, 2017 at 11:59 PM, Lauri Kenttä
> wrote:
>
> > On 2017-01-17 16:18, Lauri Kenttä wrote:
> >
> >> On 2017-01-17 02:34, Yasuo Ohgaki wrote:
> >>
> >>> Set state somewhere between MT rand's 2^19937−1 cycle.
> >>>
>
Hi Lauri,
On Tue, Jan 17, 2017 at 11:59 PM, Lauri Kenttä
wrote:
> On 2017-01-17 16:18, Lauri Kenttä wrote:
>
>> On 2017-01-17 02:34, Yasuo Ohgaki wrote:
>>
>>> Set state somewhere between MT rand's 2^19937−1 cycle.
>>>
>>
>> This is exactly what my patch does.
>>
>
> Or, to be honest, my patch p
On 2017-01-17 16:18, Lauri Kenttä wrote:
On 2017-01-17 02:34, Yasuo Ohgaki wrote:
Set state somewhere between MT rand's 2^19937−1 cycle.
This is exactly what my patch does.
Or, to be honest, my patch provides 2^19936 possible states,
which should be more than enough.
To get all 2^19937−1, y
On 2017-01-17 02:34, Yasuo Ohgaki wrote:
Set state somewhere between MT rand's 2^19937−1 cycle.
This is exactly what my patch does.
--
Lauri Kenttä
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
Hi Lauri,
On Tue, Jan 17, 2017 at 2:34 AM, Lauri Kenttä
wrote:
> On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki wrote:
>
>> We know this kind of seed is guessable. i.e. Our session id is compromised
>> by this kind of code.
>>
>
> Maybe you should fix session id instead of (or in addition to) mt
On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki
wrote:
We know this kind of seed is guessable. i.e. Our session id is
compromised
by this kind of code.
Maybe you should fix session id instead of (or in addition to) mt_rand.
On 2017-01-16 09:16, Yasuo Ohgaki wrote:
Comments are appreciated.
On Mon, Jan 16, 2017 at 4:04 PM, Yasuo Ohgaki wrote:
> Since I was about to improve uniqid()'s entropy by replacing
> php_combined_lcg() to php_random_int(), I spent time to check other places
> that could be a problem.
>
> mt_rand()'s is seeded as follows by default.
>
> ext/standard/php_rand.h
45 matches
Mail list logo
