Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-23 Thread Stanislav Malyshev 
Hi!

> Is the feedback then that we should expose /more/ of the OpenSSL API?

Well, not exactly more of the API I think but ways to link bignums to
others OpenSSL functions. Think about it this way: what people
frequently use bignums for? Doing some kind of crypto-like stuff. But if
you want to do crypto-like stuff, being able to combine it, for example,
with something like openssl_x509_read might probably be useful? Etc.
At least that was my idea :)
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-23 Thread Sara Golemon 
On Sun, Oct 23, 2016 at 5:06 PM, Stanislav Malyshev  wrote:
>> What are the specific reasons for choosing OpenSSL Bignums over GMP,
>> outside of extension availability (which is totally a path I don't want us
>> to go down -- see also recent attempts to duplicate ext/mbstring into
>> ext/standard)? Are there any particular properties of the openssl
>> implementation that are beneficial for certain applications?
>
> I'd say having it for free when you have OpenSSL is a factor. If it were
> separate extension, I'd say the right route is to just make PECL ext as
> usual, but since this kind of has the natural place in openssl, it may
> be a bit different.
>
> I do see a point though that somehow integrating with the rest of
> OpenSSL would be a good thing then. After all, if you have code that
> does some interesting stuff with data but you can't use openssl pkey
> functions to input/output the results, it turns into reimplementing the
> whole crypto system and that's usually not a good idea.
>
Is the feedback then that we should expose /more/ of the OpenSSL API?
I'm happy to expand this to encompass more of the crypto library
functions.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-23 Thread Stanislav Malyshev 
Hi!

> What are the specific reasons for choosing OpenSSL Bignums over GMP,
> outside of extension availability (which is totally a path I don't want us
> to go down -- see also recent attempts to duplicate ext/mbstring into
> ext/standard)? Are there any particular properties of the openssl
> implementation that are beneficial for certain applications?

I'd say having it for free when you have OpenSSL is a factor. If it were
separate extension, I'd say the right route is to just make PECL ext as
usual, but since this kind of has the natural place in openssl, it may
be a bit different.

I do see a point though that somehow integrating with the rest of
OpenSSL would be a good thing then. After all, if you have code that
does some interesting stuff with data but you can't use openssl pkey
functions to input/output the results, it turns into reimplementing the
whole crypto system and that's usually not a good idea.
-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-23 Thread Jakub Zelenka 
On Tue, Oct 18, 2016 at 2:35 AM, Sara Golemon  wrote:

> As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> https://wiki.php.net/rfc/openssl.bignum
>
>
I don't see any reason why we should expose BN API if it's not integrated
with PKEY algorithms. This proposal doesn't really fit with the current
functions IMHO so in this case it doesn't make much sense to introduce it
unless you would also add classes like OpenSSL\RSA , OpenSSL\EC\Key and so
on. I think that having just BigNum in OpenSSL namespace is kind of strange
as BN is just a supporting API in for crypto operations in OpenSSL... If it
was a functional API, than it would probably fit better with current
functions and it would just need to be integrated with openssl_pkey_new
which is more achievable and would be a bit more consistent.

Cheers

Jakub

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-19 Thread Nikita Popov 
On Wed, Oct 19, 2016 at 1:48 AM, Daniel Morris 
wrote:

> On Tue, 18 Oct 2016, at 09:22 AM, Nikita Popov wrote:
> > On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:
> >
> > > As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> Why do we need GMP when we have BCMath?


Because GMP implements big integer arithmetic, while BCMath implements big
decimal arithmetic.


> GMP is faster (from what I've
> seen so far from various tests and blog posts) – whilst they do similar
> ops, they are chosen for specific reasons, all this does is expose the
> existing interfaces for arbitrary precision arithmetic made available
> with the OpenSSL layer, and I think anyone implementing them would want
> the API there, it requires minimal maintenance. Sara, I think the best
> route is too match the method names within OpenSSL, it will avoid some
> initial confusion, unless people want to change libraries, but I think
> that is probably less likely.
>

What are the specific reasons for choosing OpenSSL Bignums over GMP,
outside of extension availability (which is totally a path I don't want us
to go down -- see also recent attempts to duplicate ext/mbstring into
ext/standard)? Are there any particular properties of the openssl
implementation that are beneficial for certain applications?

Nikita

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Daniel Morris 
And sorry for the  spam (this should have been mentioned in the last
email), as far as I can tell, there is no-way to say "I want a either a
signed or unsigned integer with an N bits", I've come across this
recently whilst trying to implement Murmur3 (128-bit) in PHP, I can
of-course binary AND into
0b111 (e.g.
$x & 0b11...) and it will yield result of 9,223,372,036,854,775,807
((2^63)- 1 (PHP_INT_MAX)) but adding an additional 1 (radix 10) will
yield a double(9.2233720368548E+18) and it's at that point it becomes
incredibly difficult to work with to work with natural numbers.

(Unrelated to Sara's RFC, just a thought I'd mention incase someone is
interested...)

I personally think this RFC is fine despite the existing libraries that
do similar (BCMath and GMP), it's more of an interface to the lower
layer (and OpenSSL specific) rather than an implementation. We're just
keeping up with existing implementations.

Sara, I'm happy to implement additional tests and look at fast ZPP for
methods tomorrow if you're too busy and think this is going somewhere...

DM

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Daniel Morris 
On Tue, 18 Oct 2016, at 09:22 AM, Nikita Popov wrote:
> On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:
> 
> > As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.

Why do we need GMP when we have BCMath? GMP is faster (from what I've
seen so far from various tests and blog posts) – whilst they do similar
ops, they are chosen for specific reasons, all this does is expose the
existing interfaces for arbitrary precision arithmetic made available
with the OpenSSL layer, and I think anyone implementing them would want
the API there, it requires minimal maintenance. Sara, I think the best
route is too match the method names within OpenSSL, it will avoid some
initial confusion, unless people want to change libraries, but I think
that is probably less likely.

DM

--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Nikita Popov 
On Tue, Oct 18, 2016 at 3:35 AM, Sara Golemon  wrote:

> As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
>
> https://wiki.php.net/rfc/openssl.bignum
>

Why do we need this when we already have GMP?

If the only reason is "not all environments install GMP" then I'm -1 on
this.

Nikita

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Sara Golemon 
On Mon, Oct 17, 2016 at 11:41 PM, Sebastian Bergmann  wrote:
> Am 18.10.2016 um 08:23 schrieb Sara Golemon:
>> I'm mostly curious about thoughts on API decisions.
>
> * public static function createFromBinary(string $number): BigNum;
> * public static function createFromInteger(int $number): BigNum;
> * public static function createFromString(string $number): BigNum;
>
I did consider that (though with a required base parameter for
createFromString() (which, due to OpenSSL's API would be constrained
to 10 or 16).

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Sebastian Bergmann 
Am 18.10.2016 um 08:23 schrieb Sara Golemon:
> I'm mostly curious about thoughts on API decisions.

Can we make the constructor non-public and instead only have named
constructors?

* public static function createFromBinary(string $number): BigNum;
* public static function createFromInteger(int $number): BigNum;
* public static function createFromString(string $number): BigNum;


-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-18 Thread Sara Golemon 
> Looks ok to me. Would probably not hurt also add tests for various error
> conditions.
>
There's one TypeError test in there, but I can easily add more. (And
probably will on my flight tomorrow.)

> I realise this is only exposing functionality already available with
> OpenSSL but is it worth adding tests that cover some arbitrary precision
> arithmetic? The tests at the moment cover integers that PHP already
> handles natively without requiring either GMP or BCMath.
>
This type of test is certainly worth including.  I'll add some it these as well.

I'm mostly curious about thoughts on API decisions.  For example: Do
we want this in a namespace? Would we rather match GMP's function
based API for consistency? I like the decisions I made, but I can
imagine disagreement.

-Sara

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-17 Thread Stanislav Malyshev 
Hi!

> As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
> 
> https://wiki.php.net/rfc/openssl.bignum

Looks ok to me. Would probably not hurt also add tests for various error
conditions.

-- 
Stas Malyshev
smalys...@gmail.com

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Re: [PHP-DEV] [RFC] OpenSSL BigNum support

2016-10-17 Thread Daniel Morris 
I realise this is only exposing functionality already available with
OpenSSL but is it worth adding tests that cover some arbitrary precision
arithmetic? The tests at the moment cover integers that PHP already
handles natively without requiring either GMP or BCMath.

There's usage of zend_parse_parameters_throw, is it possible to change
this to use the fast parameter parsing API within PHP_METHOD or is that
reserved only for PHP_FUNCTION at the moment?

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php