>
> Note for others: "The extract step in HKDF can concentrate existing
> entropy
> but cannot amplify entropy." is not came from the RFC. If a RFC states
> this I would be stunned. Please read on you'll see the evidence.
>
This is ridiculous. Be stunned. It's right in the section about
applicat
Hi Niklas,
On Fri, Sep 8, 2017 at 4:57 PM, Niklas Keller wrote:
> Note for others: "The extract step in HKDF can concentrate existing
>> entropy
>> but cannot amplify entropy." is not came from the RFC. If a RFC states
>> this I would be stunned. Please read on you'll see the evidence.
>>
>
>
Hi all,
I finally find out what's wrong.
Andrey and Nikita, you missed
RFC 5689 - https://tools.ietf.org/html/rfc5869#section-3.3
In some applications, the input key material IKM may already be
present as a cryptographically strong key. In this case, one can skip the
extract part and us
Yeah, I keep thinking about this.
I'm not sure there's a really good reason why PHP shouldn't come with
best-in-class image support, if it's available - which it sounds like it
is; libvips looks more modern, lower memory and CPU overhead, better
overall really, and appears to be stable and up-to-d
>
> I finally find out what's wrong.
>
No, you didn't. You still want to use user-supplied passwords as IKM. HKDF
is not suited for that purpose.
> RFC 5689 - https://tools.ietf.org/html/rfc5869#section-3.3
>
> In some applications, the input key material IKM may already be
> present as
Hi Niklas,
On Fri, Sep 8, 2017 at 6:38 PM, Niklas Keller wrote:
> I finally find out what's wrong.
>>
>
> No, you didn't. You still want to use user-supplied passwords as IKM. HKDF
> is not suited for that purpose.
>
Andrey and Nikita clearly misunderstood the RFC 5869.
This is what was wrong i
Hi Niklas,
On Fri, Sep 8, 2017 at 7:27 PM, Yasuo Ohgaki wrote:
> Hi Niklas,
>
> On Fri, Sep 8, 2017 at 6:38 PM, Niklas Keller wrote:
>
>> I finally find out what's wrong.
>>>
>>
>> No, you didn't. You still want to use user-supplied passwords as IKM.
>> HKDF is not suited for that purpose.
>>
>
From: Nikita Popov
Sorry for the long delay. I've just applied
https://github.com/php/php-src/commit/fd07302024bc47082b13b32217147fd39d1e9e61
to the 7.2 branch.
Davey, Joe, do we want to take action here for 7.1? It's a pretty
severe
bias, but fixing it is going to change seed sequences. I t
On Fri, Sep 08, 2017 at 07:56:23AM -0400, Tom Worster wrote:
> From: Nikita Popov
> >
> >Sorry for the long delay. I've just applied
> >https://github.com/php/php-src/commit/fd07302024bc47082b13b32217147fd39d1e9e61
> >to the 7.2 branch.
> >
> >Davey, Joe, do we want to take action here for 7.1? It
Feels too late for 7.1
Cheers
Joe
On Fri, Sep 8, 2017 at 1:31 PM, Solar Designer wrote:
> On Fri, Sep 08, 2017 at 07:56:23AM -0400, Tom Worster wrote:
> > From: Nikita Popov
> > >
> > >Sorry for the long delay. I've just applied
> > >https://github.com/php/php-src/commit/fd07302024bc47082b13b3
On 8 Sep 2017, at 8:31, Solar Designer wrote:
On Fri, Sep 08, 2017 at 07:56:23AM -0400, Tom Worster wrote:
From: Nikita Popov
Sorry for the long delay. I've just applied
https://github.com/php/php-src/commit/fd07302024bc47082b13b32217147fd39d1e9e61
to the 7.2 branch.
Davey, Joe, do we want
Hi,
On Do, 2017-09-07 at 15:13 -0300, David Rodrigues wrote:
> I understand that array_filter() should costs more than for/foreach
> because
> it is a function call that call another function for each item, while
> the
> for/foreach is a language constructor that works on a way totally
> different
On Fri, Sep 8, 2017 at 9:06 AM, Johannes Schlüter
wrote:
> Hi,
>
> On Do, 2017-09-07 at 15:13 -0300, David Rodrigues wrote:
>> I understand that array_filter() should costs more than for/foreach
>> because
>> it is a function call that call another function for each item, while
>> the
>> for/forea
On Fri, Sep 8, 2017 at 8:06 AM, Johannes Schlüter
wrote:
> On Do, 2017-09-07 at 15:13 -0300, David Rodrigues wrote:
>> I understand that array_filter() should costs more than for/foreach
>> because
>> it is a function call that call another function for each item, while
>> the
>> for/foreach is a
Hi everyone!
Here's an RFC for a small, simple, self-contained feature with no
backwards-compatibility breaks and which in fact doesn't even touch the
language's syntax (it's 50%+1 eligible!) but which could make PHP a bit
more expressive and consistent, especially with potential later
featur
On Fri, Sep 8, 2017 at 11:41 PM, Andrea Faulds wrote:
> Hi everyone!
>
> Here's an RFC for a small, simple, self-contained feature with no
> backwards-compatibility breaks and which in fact doesn't even touch the
> language's syntax (it's 50%+1 eligible!) but which could make PHP a bit
> more exp
Results for project PHP master, build date 2017-09-07 19:24:07-07:00
commit: c5dfbcf
previous commit:d254a2c
revision date: 2017-09-07 17:37:43-04:00
environment:Haswell-EP
cpu:Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz 2x18 cores,
stepping 2, LLC 45 MB
On 8 Sep 2017, at 17:41, Andrea Faulds wrote:
Hi everyone!
Here's an RFC for a small, simple, self-contained feature with no
backwards-compatibility breaks and which in fact doesn't even touch
the language's syntax (it's 50%+1 eligible!) but which could make PHP
a bit more expressive and con
> On 1 Sep 2017, at 22:25, Niklas Keller wrote:
>
> A potential way around that (might be a stupid idea I just had): Allow
> defining "wrappers" per file, that auto-wrap marked functions.
Amp need these wrapper functions because we cannot yield a generator from
its sub function call. So if we i
> On 2 Sep 2017, at 20:19, Rowan Collins wrote:
>
> On 1 September 2017 14:02:29 BST, Haitao Lv wrote:
>>
>> Fiber is a lightweight thread. Please see
>> https://en.wikipedia.org/wiki/Fiber_(computer_science)
>> And ruby support Fiber. Please see
>> https://ruby-doc.org/core-2.4.1/Fiber.html
>
the best corotine . must be golang go and chan. very easy to use. non blocking.
On Sat, Sep 9, 2017 at 2:28 PM +0800, "Haitao Lv" wrote:
> On 2 Sep 2017, at 20:19, Rowan Collins wrote:
>
> On 1 September 2017 14:02:29 BST, Haitao Lv wrote:
>>
>> Fiber is a lightweight thread. P
21 matches
Mail list logo
