Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:84050
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain thefsb.org designates 173.203.187.115 as permitted sender)
User-Agent: Microsoft-MacOutlook/14.4.8.150116
Date: Fri, 27 Feb 2015 16:14:00 -0500
To: php-internals <internals@lists.php.net>
Message-ID: <D1164848.5E222%fsb@thefsb.org>
Thread-Topic: aes_decrypt() aes_encrypt() (was Re: crypto_something)
Mime-version: 1.0
Content-type: text/plain;
	charset="UTF-8"
Content-transfer-encoding: 7bit
Subject: aes_decrypt() aes_encrypt() (was Re: crypto_something)
From: fsb@thefsb.org (Tom Worster)

On 2/26/15 11:12 AM, Leigh wrote:> On 26 February 2015 at 15:37, Tom
Worster <fsb@thefsb.org> wrote:

> I've spoken with Anthony and a couple of others about something in the
> same vein as the new csprng functions. I think core needs a pair of
> functions that handles the needs of the 99%. Those functions are.
> 
> aes_encrypt(string $data, string $key): string
> 
> aes_decrypt(string $data, string $key): string
> 
> I have discussed this briefly with Anthony and Nikita, and we haven't
> reached a consensus on whether AES-n would be determined by key-length
> (adding complexity for the user), or whether $key should be
> $passphrase and should have key-stretching performed (this would avoid
> the case where people pass in hex for a key), in which case we would
> default to AES-128.
> 
> The default mode would be CTR
> 
> An IV would be taken from the csprng random functions, and would be
> prepended to the result.
> 
> A strong MAC would be calculated and appended to the result.
> 
> This doesn't leave any room for interoperability where things are done
> differently, but it also doesn't leave any room for people to mess it
> up. I think it's important that when it comes to crypto, we give
> people the ability to "just get it right", without having to know
> about why something is right or wrong.
> 
> I welcome any thoughts on this.


I agree with this direction and have a few comments.

1. You say it "doesn't leave any room for interoperability" but I'm
not sure I agree. I invite you again to look at the Cryptography lib
for Python. The Fernet protocol is published. It implements basically
what you are describing above but with a couple of interesting extras:

 - protocol version number

 - timestamp, useful for receivers tracking for possible replay

I don't see why we couldn't sponsor an effort to encourage adoption
of this or some such interoperability protocol. Go to FIG, see if the
Rails, Node and Django people are interested, and so fourth...

2. At this stage I think PHP should be thinking beyond AES. There are
a number of arguments about phasing out AES that you can find online.
Regardless of the merits of these arguments, the demand for newer
ciphers is only going to increase. Meanwhile, it's going to be years
before anything we discuss here now is mainstream in PHP and more
years before that gets upgraded. So I think we may as well have a
pluggable backend for algorithm implementations and a means for users
to upgrade ciphers, perhaps by introducing new version numbers in the
above mentioned protocol from time to time. That said, I'm not in
favor of a function that lets users choose among lots of ciphers. I
just want an easier way to evolve than introducing new functions,
like, idk, threefish_encrypt().

3. When we did this in the yii\base\Security component we choose to
have separate methods for encryptByPassword() and encryptByKey(). The
main advantages are:

- it makes the API simpler and easier to explain

- it encourages the developer to think about the difference

- it gives us a soapbox to encourage people to avoid passwords when
  possible

And I encourage PHP to do the same if you want to allow users to do
either. Users will sometimes need to encrypt with a password so its
best to make it hard to screw up.

4. We included a salt in the message for PBKDF2, and, just to keep
the message format the same both ways, used one also for key-based
encrypt.

Tom


Btw: owing to the volume on this list, I am not normally subscribed.
I occasionally check activity using nntp but cannot seem to reply
that way. In any case, if there's something you want me to see,
please send it to my email address.