Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87637
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.215.42 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <BLU436-SMTP1208EA3398A3A6DDB850C9E2760@phx.gbl>
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
	<BLU436-SMTP1208EA3398A3A6DDB850C9E2760@phx.gbl>
Date: Wed, 5 Aug 2015 09:57:24 +0700
Message-ID: <CAEZPtU5_e_Npo2riZZh77sQ-xTDC243zv+OTjNfSUvDgcn56GQ@mail.gmail.com>
To: Bob Weinand <bobwei9@hotmail.com>
Cc: Scott Arciszewski <scott@paragonie.com>, PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: pierre.php@gmail.com (Pierre Joye)

On Wed, Aug 5, 2015 at 3:40 AM, Bob Weinand <bobwei9@hotmail.com> wrote:
>
>> Am 3.8.2015 um 22:54 schrieb Scott Arciszewski <scott@paragonie.com>:
>>
>> Hi,
>>
>> 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.
>>
>> Some of these might be familiar to some of you.
>>
>> 1. Pluggable Cryptography Frontend
>>
>> 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).
>>
>> 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.
>>
>>    $AES =3D new \PCO\Symmetric('openssl:cipher=3DAES-128');
>>    $ciphertext =3D $AES->encrypt($plaintext, $someKey);
>>
>>    $PKC =3D new \PCO\Asymmetric('libsodium');
>>    $offlineDecryptable =3D $PKC->seal($plaintext, $someX25519PublicKey);
>>
>> 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.
>>
>> 2. Cache-timing-safe character encoding functions
>>
>> Alternatives for existing functions that should function like their
>> unsafe counterparts, but without branches or data-based index lookups.
>>
>> * hex2bin() -> hex2bin_ts()
>> * bin2hex() -> bin2hex_ts()
>> * base64_encode() -> base64_encode_ts()
>> * base64_decode() -> base64_decode_ts()
>>
>> 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).
>>
>> 3. Other ideas (not yet committed to at all, but might be of interest
>> to others):
>>
>> * 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
>>
>> 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).
>>
>> 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
>>
>>    "With great ubiquity comes great responsibility." - Matthew Green
>> <https://twitter.com/matthew_d_green/status/578567678492733440>
>>
>> Scott Arciszewski
>> Chief Development Officer
>> Paragon Initiative Enterprises <https://paragonie.com>
>
> Hey,
>
> I went ahead and just made bin2hex()/hex2bin() timing safe as a first ste=
p.
>
> See https://github.com/php/php-src/pull/1453 <https://github.com/php/php-=
src/pull/1453>
>
> Note that it does not add extra functions, but just because performance i=
s just about as good as before [or even better in cases of severe mispredic=
tions].

Nice work :)


> If there=E2=80=99s no negative feedback, I=E2=80=99m going to merge that =
in a few days into master.

We are in feature freeze so please hang on the push.

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.

Cheers,
--=20
Pierre

@pierrejoye | http://www.libgd.org