Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87655
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain hotmail.com designates 65.55.111.92 as permitted sender)
Message-ID: <BLU436-SMTP98E6DEF5BB40265F5111B5E2750@phx.gbl>
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_4C187B1E-5ACF-498A-AB04-620C1FFACBF9"
MIME-Version: 1.0 (Mac OS X Mail 8.2 \(2098\))
In-Reply-To: <CAEZPtU5_e_Npo2riZZh77sQ-xTDC243zv+OTjNfSUvDgcn56GQ@mail.gmail.com>
Date: Wed, 5 Aug 2015 21:35:43 +0200
CC: Scott Arciszewski <scott@paragonie.com>,
 PHP Internals <internals@lists.php.net>
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com> <BLU436-SMTP1208EA3398A3A6DDB850C9E2760@phx.gbl> <CAEZPtU5_e_Npo2riZZh77sQ-xTDC243zv+OTjNfSUvDgcn56GQ@mail.gmail.com>
To: Pierre Joye <pierre.php@gmail.com>
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: bobwei9@hotmail.com (Bob Weinand)

--Apple-Mail=_4C187B1E-5ACF-498A-AB04-620C1FFACBF9
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

> Am 05.08.2015 um 04:57 schrieb Pierre Joye <pierre.php@gmail.com>:
>=20
> On Wed, Aug 5, 2015 at 3:40 AM, Bob Weinand <bobwei9@hotmail.com> =
wrote:
>>=20
>>> Am 3.8.2015 um 22:54 schrieb Scott Arciszewski =
<scott@paragonie.com>:
>>>=20
>>> Hi,
>>>=20
>>> I would like to make it easier for PHP developers to implement
>>> cryptography features in their applications. I intend to work on =
some
>>> of these ideas and submit them for inclusion in PHP 7.1.
>>>=20
>>> Some of these might be familiar to some of you.
>>>=20
>>> 1. Pluggable Cryptography Frontend
>>>=20
>>> Work is currently underway for a PHP prototype for this idea
>>> originally suggested by ircmaxell, that will basically be like PDO =
for
>>> cryptography. Our current project name, subject to change, is PHP
>>> Crypto Objects (PCO).
>>>=20
>>> The idea is that you could write code like this to add secure
>>> authenticated encryption to your application without having to worry
>>> about the details.
>>>=20
>>>   $AES =3D new \PCO\Symmetric('openssl:cipher=3DAES-128');
>>>   $ciphertext =3D $AES->encrypt($plaintext, $someKey);
>>>=20
>>>   $PKC =3D new \PCO\Asymmetric('libsodium');
>>>   $offlineDecryptable =3D $PKC->seal($plaintext, =
$someX25519PublicKey);
>>>=20
>>> When it's finished, I'd like to turn it into a PECL extension so =
users
>>> can play with it in PHP 7.0 and submit it for inclusion in 7.1.
>>>=20
>>> 2. Cache-timing-safe character encoding functions
>>>=20
>>> Alternatives for existing functions that should function like their
>>> unsafe counterparts, but without branches or data-based index =
lookups.
>>>=20
>>> * hex2bin() -> hex2bin_ts()
>>> * bin2hex() -> bin2hex_ts()
>>> * base64_encode() -> base64_encode_ts()
>>> * base64_decode() -> base64_decode_ts()
>>>=20
>>> Other formats are out of scope, unless someone can make the case =
that
>>> we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
>>> Service integration).
>>>=20
>>> 3. Other ideas (not yet committed to at all, but might be of =
interest
>>> to others):
>>>=20
>>> * Improving the OpenSSL API, or at least the documentation
>>> * Adding streaming encryption/decryption support to OpenSSL
>>> * Adding AE and AEAD interfaces to OpenSSL
>>> * Aliasing MCRYPT_AES -> MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR
>>>=20
>>> What I need from you is guidance on what features or changes you =
want
>>> to see in 7.1 and which can be put off until later (or never =
proposed
>>> as an RFC at all).
>>>=20
>>> Seriously, all I need is your opinion and whether or not you'd like =
to
>>> see any of these happen. If you have specific implementation details
>>> you'd like to discuss or requests, of course those are welcome too. =
:D
>>>=20
>>>   "With great ubiquity comes great responsibility." - Matthew Green
>>> <https://twitter.com/matthew_d_green/status/578567678492733440>
>>>=20
>>> Scott Arciszewski
>>> Chief Development Officer
>>> Paragon Initiative Enterprises <https://paragonie.com>
>>=20
>> Hey,
>>=20
>> I went ahead and just made bin2hex()/hex2bin() timing safe as a first =
step.
>>=20
>> See https://github.com/php/php-src/pull/1453 =
<https://github.com/php/php-src/pull/1453>
>>=20
>> Note that it does not add extra functions, but just because =
performance is just about as good as before [or even better in cases of =
severe mispredictions].
>=20
> Nice work :)
>=20
>=20
>> If there=E2=80=99s no negative feedback, I=E2=80=99m going to merge =
that in a few days into master.
>=20
> We are in feature freeze so please hang on the push.
>=20
> Also time safe functions may be trickier than it looks. We have to be
> very careful by declaring one timesafe (or safe at all) so a peer
> reviews are a must here. A RFC too. Let not rush and push something
> possibly buggy too early.
>=20
> Cheers,
> --=20
> Pierre
>=20
> @pierrejoye | http://www.libgd.org <http://www.libgd.org/>
Not sure what the point of a RFC here is. It is obviously okay to do =
that=E2=80=A6 the only discussion is whether it's really safe. We need =
people with deep understanding of these things to look at, not a generic =
RFC.
The pull request already provides all info needed. I don't know who to =
ask specifically for review? I'd rather ask a few experts than throwing =
this at a community where 99% of people have no deep understanding in =
this field.

Bob

P.s.: yes, we are in *feature* freeze. Not sure if a (timing) safety fix =
falls in the feature category.=

--Apple-Mail=_4C187B1E-5ACF-498A-AB04-620C1FFACBF9--