Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87633
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.192.175 as permitted sender)
To: Scott Arciszewski <scott@paragonie.com>
References: <CAKws9z1fatmSR2YLaeBn0zVv-s3iwCj7OUKjW949QC0L_VndpA@mail.gmail.com>
 <55C0685E.2070202@gmail.com>
 <CAKws9z3gBf+_0cSPvo3Sh4NAxuPRZT5EbQoqbvhnLxpyjY4F8g@mail.gmail.com>
Cc: PHP Internals <internals@lists.php.net>
Message-ID: <55C15F1B.9010401@gmail.com>
Date: Tue, 4 Aug 2015 17:55:55 -0700
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.1.0
MIME-Version: 1.0
In-Reply-To: <CAKws9z3gBf+_0cSPvo3Sh4NAxuPRZT5EbQoqbvhnLxpyjY4F8g@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] PHP 7.1 Cryptography Projects
From: smalyshev@gmail.com (Stanislav Malyshev)

Hi!

> The idea here isn't too far removed from what PDO does versus mysql_*,
> mssql_*, pgsql_*, etc. except it's probably more critical: Switch
> crypto backends with almost zero refactoring; just change your
> constructor.

So my question here is - how important task is switching crypto backends
easily? Moreover, what would be the reason for me, as an app developer,
to target more than one crypto backend? I can see why I may want to
target mysql and say, SQL server - these two platforms have different
advantages, etc. But if OpenSSL works for my app, why would I need to
support any other backend? Do I have a chance of a client saying "oh, we
don't run apps using OpenSSL, only libsodium"? Abstraction is a nice
thing, but in this case I'm not sure about the added value. Of course,
if crypto library goes out of support - like mcrypt - it can be handy,
but given that each library probably will have own peculiarities, I'm
not sure abstraction would allow for clean switch anyway.

> Developers are, quite rationally, going to want to store their
> encryption key in configuration files. (INI, JSON, XML, YAML, .env
> files, etc.) In doing so, they will generally choose to encode these
> functions in base-16 or base-64 for storage purposes.

OK, that makes sense. Do current base64 decoding libs have timing
problems allowing to devise key bits? The code seems pretty simple,
though it does have a lookup there, so in theory that might influence
the timing.

>> Hm... Implementing streaming cyphers right is not trivial, and if we'd
>> be doing our own crypto (as opposed to providing API to existing
>> libraries) we need a real lot of review to be confident it's done right.
> 
> You're right. Luckily this is a road I've already traveled with
> defuse/php-encryption.
> 
> https://github.com/defuse/php-encryption/pull/78

By traveled, do you mean that this library has been reviewed and
approved by professional cryptologists and crypt-analysts?

> Which brings me to the meat of the proposal: Although the interface I
> introduced in the first post only mentions encrypt() and decrypt(),
> that's actually not the whole truth. PCO\Symmetric will only ever, and
> this is not negotiable, offer Authenticated Encryption modes:

OK, that looks like added value. Doing authenticated encryption right
now is not obvious and easy to mess up.

> There will also be an aeadEncrypt() and aeadDecrypt() interface, which
> allows you to authenticate associated data which is not encrypted.

This also sounds good but I'm worried about data formats - encrypted
data tend to be exchanged between heterogeneous systems, so I think we
should make decoding the resulting message easy without implementing
special code (which also could have security problems).

> This will all be documented in the RFC when it comes time to open it
> (as well as the Github repository for the PHP extension when we get to
> this point), so if anyone misses this email don't worry. :)

Thanks, that sounds good!
-- 
Stas Malyshev
smalyshev@gmail.com