aes_decrypt() aes_encrypt() (was Re: crypto_something)

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.