Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87642
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.177 as permitted sender)
MIME-Version: 1.0
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
In-Reply-To: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
Date: Wed, 05 Aug 2015 12:20:21 +0000
Message-ID: <CAPwsocH2twGKaJB2tU91pvNbbes3giBKY8Ev7PGqNnRUv_qk2Q@mail.gmail.com>
To: Scott Arciszewski <scott@paragonie.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d042182adc55a47051c8f6df6
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: leight@gmail.com (Leigh)

--f46d042182adc55a47051c8f6df6
Content-Type: text/plain; charset=UTF-8

On Mon, 3 Aug 2015 at 21:54 Scott Arciszewski <scott@paragonie.com> wrote:

> 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 = new \PCO\Symmetric('openssl:cipher=AES-128');
>     $ciphertext = $AES->encrypt($plaintext, $someKey);
>
>     $PKC = new \PCO\Asymmetric('libsodium');
>     $offlineDecryptable = $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
>

I wrote about something similar earlier in the year, although the timing
was probably pretty bad with all of the scalar type arguments going on.

http://marc.info/?l=php-internals&m=142365688004941&w=2

I'm obvious +1 on the concept.

There's a couple of other things I would like to see in addition to what
you have proposed.

* AES-*-CTR native without a back-end. There is a ton of trusted reference
code for this, and (probably) removes the reliance on an extension for the
majority of PHP crypto use-cases.

* As others have said, lets try and avoid the evil DSN - we're trying to
make it easy for users to get it right here. Ideally there should be enough
metadata so a user can request a cipher without a back-end, and appropriate
back-end will be selected if available.

* I'd like to see some hashes as part of this, not everything from
ext/hash, but being able to have a hash as a stream filter would be great

* An API that makes it easy for extensions to register metadata /
implementation for a cipher/hash/whatever they provide

--f46d042182adc55a47051c8f6df6--