On 2/26/15, 12:59 AM, "Sammy Kaye Powers" wrote:
>I don't know why everyone says the internals list is so scary - you guys
>are great! :)
Clearly php-internals participants are all very fine people. I am
nevertheless scared brickless of php-internals, which is not the
same thing;)
>I actually
On 26 February 2015 at 15:04, Tom Worster wrote:
>>I actually started down this RFC path out of frustration on this very
>>point of needing secure random alphanumeric stings. The originally RFC &
>>patch contained a `random_hex()` function that would convert bytes from
>>the CSPRNG into hex.
>
> b
On Thu, Feb 26, 2015 at 12:48 AM, Stanislav Malyshev
wrote:
> Hi!
>
>> I'm cool with that idea but I also think it should be spelled out like `
>> random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
>> that's because it's what Ruby names their CSPRNG. :)
>
> The custom is tha
Hi!
> I'm cool with that idea but I also think it should be spelled out like `
> random_crypto_*()` as Pierre suggests. I like `secure_random_bytes()` but
> that's because it's what Ruby names their CSPRNG. :)
The custom is that the first word names the function group (yes, I know
old functions d
I don't know why everyone says the internals list is so scary - you guys
are great! :)
> I think the function name(s) should indicate that these functions are for
getting crypto-secure randomness. I proposed cs_random_bytes()
I'm cool with that idea but I also think it should be spelled out like
hi,
On Wed, Feb 25, 2015 at 5:39 PM, Pierre Joye wrote:
I totally forgot to mention one thing in all my replies:
I love this addition and it is cruelly needed :)
I only have doubts about the implementations and the details I
explained in my other replies. It is also something that could be
add
On Wed, Feb 25, 2015 at 2:40 PM, Leigh wrote:
> On modern OpenBSD/FreeBSD/OSX /dev/random and /dev/urandom are both
> aliases of /dev/arandom, which is quite literally an inexhaustible
> supply of CS random backed by arc4random. On Linux I think you'll be
> hard pressed to exhaust /dev/urandom fr
Might as well mention it because it has been discussed OTR.
We've thrown the idea around that we could cater for other sources of
random via a PHP extension. (I.e. if someone has a particular hardware
RNG they want to use). We're concerned that this may be misused, or
even abused as a way of delib
Tom
On Wed, Feb 25, 2015 at 6:21 PM, Tom Worster wrote:
> Hi Leigh,
>
>>We're still discussing whether a userland (non-kernel userland)
>>implementation of arc4random is wise. We need to put some feelers out
>>and consult some experts on this,
>
> I wouldn't. As Thomas Patcek put it, quoting the
Hi Leigh,
>We're still discussing whether a userland (non-kernel userland)
>implementation of arc4random is wise. We need to put some feelers out
>and consult some experts on this,
I wouldn't. As Thomas Patcek put it, quoting the article I linked
before:
You want to use the kernel's CSPRNG, beca
On 25 February 2015 at 20:24, Stanislav Malyshev wrote:
> Hi!
>
>> For example, the number of users that actually need to do something
>> better than read from /dev/urandom is small. A user that is concerned
>
> Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
> TLDR: it's ok
Hey Tom,
On 25 February 2015 at 19:39, Tom Worster wrote:
> I don't understand the requirement for crypto-secure random integers.
> I have never encountered this requirement. [Btw: the proposed patch
> implements this function using a loop that's not guaranteed to
> terminate in any given amount
On 2/25/15, 3:24 PM, "Stanislav Malyshev" wrote:
>Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
>TLDR: it's ok to use /dev/urandom.
Yes! Thanks for the link. Much shorter but with pretty much the same
message, I like:
http://sockpuppet.org/blog/2014/02/25/safely-generat
Hi!
> For example, the number of users that actually need to do something
> better than read from /dev/urandom is small. A user that is concerned
Good summary read on the topic: http://www.2uo.de/myths-about-urandom/
TLDR: it's ok to use /dev/urandom.
--
Stas Malyshev
smalys...@gmail.com
--
P
Tom,
On Wed, Feb 25, 2015 at 2:39 PM, Tom Worster wrote:
> I welcome the proposal for an easy-to-use PHP function for obtaining
> crypto-secure randomness. I have a number of comments and suggestions.
>
> I think the function name(s) should indicate that these functions are
> for getting crypto-s
Hi Larry,
I think we'd be biting off too much to be worth chewing for other
character sets. Most uses are going to revolve around characters
allowed in URLs. Expanding that, to a degree, perhaps per a additional
character list, or character list flag, might not be too far, but
things will get inte
I welcome the proposal for an easy-to-use PHP function for obtaining
crypto-secure randomness. I have a number of comments and suggestions.
I think the function name(s) should indicate that these functions are
for getting crypto-secure randomness. I proposed cs_random_bytes()
previously (https://w
On 02/24/2015 07:41 PM, Yasuo Ohgaki wrote:
Hi Padraic,
On Wed, Feb 25, 2015 at 7:54 AM, Pádraic Brady
wrote:
On 24 February 2015 at 22:08, Yasuo Ohgaki wrote:
Random bytes is better. People would use it for IV or like with the
size of IV. If we use string, users loose effective bits.
Sugg
Hi Padraic,
On Wed, Feb 25, 2015 at 7:54 AM, Pádraic Brady
wrote:
> On 24 February 2015 at 22:08, Yasuo Ohgaki wrote:
> > Random bytes is better. People would use it for IV or like with the
> > size of IV. If we use string, users loose effective bits.
>
> Suggestion was for an additional functi
Hi Yasuo,
On 24 February 2015 at 22:08, Yasuo Ohgaki wrote:
> Random bytes is better. People would use it for IV or like with the
> size of IV. If we use string, users loose effective bits.
Suggestion was for an additional function, so random_bytes() would
still be there ;).
Paddy
--
Pádraic
On Tue, Feb 24, 2015 at 1:39 PM, Leigh wrote:
> On 24 February 2015 at 20:54, Pierre Joye wrote:
>> On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote:
>>> PERHAPS, it could be written in such a way that a PECL extension can
>>> alter the RNG to accommodate that usecase. But I'd be wary of that a
Hi all,
On Wed, Feb 25, 2015 at 6:33 AM, Anthony Ferrara
wrote:
> On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady
> wrote:
> > Hi
> >
> > On 24 February 2015 at 20:04, Anthony Ferrara
> wrote:
> >> If random_bytes() is harder than uniqid(), it's a non-starter.
> >
> > Technically, it will be ha
Padraic,
>>> Technically, it will be harder than uniqid() if producing strictly
>>> random bytes (if output needs to be printable/readable).
>>> That's not a "bad" thing obviously!
>>
>> Sure. But does that indicate the need for a "random_string()" function?
>
> It would be more random than a stre
Hi
On 24 February 2015 at 21:33, Anthony Ferrara wrote:
> Padraic,
>
> On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady
> wrote:
>> Hi
>>
>> On 24 February 2015 at 20:04, Anthony Ferrara wrote:
>>> If random_bytes() is harder than uniqid(), it's a non-starter.
>>
>> Technically, it will be harde
On 24 February 2015 at 20:54, Pierre Joye wrote:
> On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote:
>> PERHAPS, it could be written in such a way that a PECL extension can
>> alter the RNG to accommodate that usecase. But I'd be wary of that and
>> core supporting userland RNGs.
>
> Yes, driver
Padraic,
On Tue, Feb 24, 2015 at 4:17 PM, Pádraic Brady wrote:
> Hi
>
> On 24 February 2015 at 20:04, Anthony Ferrara wrote:
>> If random_bytes() is harder than uniqid(), it's a non-starter.
>
> Technically, it will be harder than uniqid() if producing strictly
> random bytes (if output needs to
Hi
On 24 February 2015 at 20:04, Anthony Ferrara wrote:
> If random_bytes() is harder than uniqid(), it's a non-starter.
Technically, it will be harder than uniqid() if producing strictly
random bytes (if output needs to be printable/readable).
That's not a "bad" thing obviously!
Paddy
--
Pádr
On Feb 24, 2015 12:04 PM, "Anthony Ferrara" wrote:
>
> Pierre,
>
> >> In fact I had planned for a future RFC where we allow
> >> session.entropy_file to use using random_bytes(). So the "best" source
> >> is chosen automatically. (If you think there are better sources not
> >> covered by this patc
Pierre,
>> In fact I had planned for a future RFC where we allow
>> session.entropy_file to use using random_bytes(). So the "best" source
>> is chosen automatically. (If you think there are better sources not
>> covered by this patch, please let me know, I would like it to be
>> complete)
>
> I r
On Feb 24, 2015 3:08 AM, "Leigh" wrote:
>
> On 24 February 2015 at 10:55, Pierre Joye wrote:
> > It should use the session.entropy_file setting as it aims to be the
exact
> > same thing. It also allows custom entropy src (better ones for higher
> > demands) as well.
>
> I disagree. We want to tak
On 24 February 2015 at 10:55, Pierre Joye wrote:
> It should use the session.entropy_file setting as it aims to be the exact
> same thing. It also allows custom entropy src (better ones for higher
> demands) as well.
I disagree. We want to take responsibility away from the user to
choose the best
Hi Andrey,
On 24 February 2015 at 09:51, Andrey Andreev wrote:
> I noticed that the patch checks for /dev/arandom availability first,
> and I'm pretty sure that on systems that have it, /dev/urandom simply
> redirects to /dev/urandom, so that might be a bit redundant ... Maybe
> Leigh can say mor
It should use the session.entropy_file setting as it aims to be the exact
same thing. It also allows custom entropy src (better ones for higher
demands) as well.
On Feb 23, 2015 10:36 PM, "Sammy Kaye Powers" wrote:
> The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in
> PHP i
Hi,
On Tue, Feb 24, 2015 at 8:36 AM, Sammy Kaye Powers wrote:
> The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in
> PHP is up for discussion: https://wiki.php.net/rfc/easy_userland_csprng
>
> This proposes adding two methods: `random_bytes()` and `random_int()` that
> retur
The RFC to add a user-land API for an easy-to-use and reliable CSPRNG in
PHP is up for discussion: https://wiki.php.net/rfc/easy_userland_csprng
This proposes adding two methods: `random_bytes()` and `random_int()` that
return cryptographically secure pseudo-random data.
This has been quite a tea
35 matches
Mail list logo
