I'd like to tuck the attached patch into the PHP 5 branch.
It provides the following functions, and does not modify the behavior
of any of the others:
openssl_bignum_from_bin
openssl_bignum_from_hex
openssl_bignum_from_dec
openssl_bignum_to_string
openssl_dh_generate_key
openssl_dh_compute_key
openssl_dh_get_params
openssl_dh_generate_parameters
openssl_dsa_verify
These functions allow one to implement OpenID and TypeKey
authentication schemes without resorting to writing crypto code in
user-space PHP--aside from the speed advantage, you have the benefit
of using the tried and trusted OpenSSL for your DH kex.
--Wez.
Hi Wez,
I'd like to tuck the attached patch into the PHP 5 branch.
It provides the following functions, and does not modify the behavior
of any of the others:openssl_bignum_from_bin
openssl_bignum_from_hex
openssl_bignum_from_dec
openssl_bignum_to_stringopenssl_dh_generate_key
openssl_dh_compute_key
openssl_dh_get_params
openssl_dh_generate_parametersopenssl_dsa_verify
These functions allow one to implement OpenID and TypeKey
authentication schemes without resorting to writing crypto code in
user-space PHP--aside from the speed advantage, you have the benefit
of using the tried and trusted OpenSSL for your DH kex.
As the idea is good (we discussed it many times), I would like a
cleaner approach. The main problem in ext/openssl is its API. We
added new functions for each small features addition, even if the
feature itself is 99% the same as an existing function.
The Big numbers API is not an exception. It can be even worst as it is
really a single instance (a openssl big number) which can be processed
(BN operations), exported or set.
If you are in a hurry, I can clean my patch for the OO interface and
prepare a php5 version. I think it would definitively better. However,
if other prefers to go with your new functions for now, it will not be
a big problem, it only clutters the api a bit more ;).
Cheers,
--Pierre
Doesn't seem like this ever got commited.
Can we include this in PHP 5.2.2? It doesn't break existing APIs so I
think it's a good idea.
Andi
-----Original Message-----
From: Wez Furlong [mailto:wez@omniti.com]
Sent: Saturday, February 10, 2007 6:17 AM
To: internals@lists.php.net
Subject: [PHP-DEV] OpenID enabling patch for OpenSSL and PHP 5I'd like to tuck the attached patch into the PHP 5 branch.
It provides the following functions, and does not modify the
behavior of any of the others:openssl_bignum_from_bin
openssl_bignum_from_hex
openssl_bignum_from_dec
openssl_bignum_to_stringopenssl_dh_generate_key
openssl_dh_compute_key
openssl_dh_get_params
openssl_dh_generate_parametersopenssl_dsa_verify
These functions allow one to implement OpenID and TypeKey
authentication schemes without resorting to writing crypto
code in user-space PHP--aside from the speed advantage, you
have the benefit of using the tried and trusted OpenSSL for
your DH kex.--Wez.
Doesn't seem like this ever got commited.
Can we include this in PHP 5.2.2? It doesn't break existing APIs so I
think it's a good idea.
I think adding bignum functions is OK (though it duplicates GMP to a
measure) - while we are at it, why not add implementation for
btwoc(number) also?
I think this patch is a bit narrow-purpose - why we have specific DSA
verify and not for other algorithms? Why we have DSA verify but not DSA
sign? Also, can't be dsa_verify plugged into openssl_verify()? I
understand that it not receives hash and not data, but I see that
practical use described here: http://netevil.org/node.php?nid=949
generates hash from data, so no problem passing data either. So maybe we
could instead of having separate verify functions have functions that
compose keys from parameters for existing openssl_verify?
Also, some small things:
openssl_dh_generate_key on failure doesn't set return value to false.
openssl_dh_generate_parameters on failure doesn't set return value.
openssl_bignum_from_zval alsway increases resource refcount, but in
openssl_dh_generate_key when key is generated successfully refcount is
not decreased, so it's not clear if participating bignums would ever be
freed.
Stanislav Malyshev, Zend Products Engineer
stas@zend.com http://www.zend.com/
Doesn't seem like this ever got commited.
Can we include this in PHP 5.2.2? It doesn't break existing APIs so I
think it's a good idea.I think adding bignum functions is OK (though it duplicates GMP to a
measure) - while we are at it, why not add implementation for
btwoc(number) also?
I'd suggest making big_int (in PECL) into a bundled extension. I know
the original author hasn't touched it since 2005, but I've been using
the underlying library in a few applications and would be willing to
take over maintenance on it (Alexander Valyalkin released it into the
public domain -- So bundling it is not an issue).
I'd also like to expand it with things like DSA/RSA implementations and
some additional number theory applications like euclidean inversion and
the like.
I know that bc would be a reasonable candidate for this kind of
exploitation, but the fact is that bc was designed with base10 in mind
and isn't particularly performant when comparsed against
gmp/openssl/big_int.
Of those three, big_int is the only one with the clean licensing (and
ultra-small footprint) to make bundling it feasible.
-Sara
P.S. - Not that there's anything wrong with the OpenSSL implementation
Wez did... Just tossing out my thoughts on the long-term direction to
take with big number libraries.