As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
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?
Hi!
As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
Looks ok to me. Would probably not hurt also add tests for various error
conditions.
--
Stas Malyshev
smalyshev@gmail.com
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
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;
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
As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
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
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
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
0b111111111111111111111111111111111111111111111111111111111111111 (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
On Wed, Oct 19, 2016 at 1:48 AM, Daniel Morris daniel@honestempire.com
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
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
smalyshev@gmail.com
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
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
smalyshev@gmail.com
Hi Sara,
Sara Golemon wrote:
As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
If I'm reading the patch correctly, do all the methods accepting BigNums
also accept PHP integers and strings, including hexadecimal strings?
Also, what happens for floats, or numeric strings with a decimal point
or exponent? Will it be accepted, rejected, silently truncated? I'm
guessing it won't produce PHP 7.1's notices and warnings for invalid
numeric strings (though I don't suggest cloning that specific behaviour,
an outright error would be better).
Thanks!
--
Andrea Faulds
https://ajf.me/
As it says on the tin: Wrap the BN (BigNumber) library in OpenSSL.
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