[RFC] PHP 7.1 - Simple Cryptography Interface

I'd like to make cryptography drop-dead simple in PHP 7.1 and
thereafter. The simplest thing to do is to provide a simple front-end
API, designed for human usability, that abstracts away the
complexities of cryptography engineering.

I've started writing an RFC draft here: https://wiki.php.net/rfc/php71-crypto

These are the rules I'd like everyone to keep in mind when proposing
changes to these features:

1. Security is the first priority. It is absolutely unacceptable to
   add a cryptographic side-channel or render this library vulnerable to
   any sort of chosen-ciphertext attack.ECB mode is completely off the
   table.
2. Simple is good. Developers should not need to know what a nonce is,
   nor should they be given the opportunity to weaken the protocol by
   providing their own.

Some general guidelines that I feel particularly strong about but
others might contest:

For 7.1, we will only allow elliptic curve public key cryptography. In
the future, we might expand to include post-quantum cryptography. We
must absolutely not support RSA or classic (non-EC) Diffie Hellman.

This is the overall process I'd like to follow for getting this ready
for PHP 7.1.

1. Develop a PHP extension, available in PECL, so developers can
   implement it in PHP 7.0 projects to test it out. This process starts
   today. I've set up a GIthub repository at
   https://github.com/paragonie/php71_crypto for any developers that
   would like to help.

2. The RFC/voting process. This starts as soon as we have a stable
   implementation and drivers for both libsodium and openssl ready to go.

3. Formal code review from a third-party team of security experts
   (Depending on how successful I am in my business ventures this year, I
   might be able to cover the cost of this personally. I can't promise
   anything today, however.)

4. Merge it into the PHP core before 7.1.0 is released.

Everyone is welcome to contribute, even if you're not a cryptography
expert. Non-experts are the people I intend to be able to use it, so
your feedback will be incredibly valuable.

Together, I believe we can make PHP 7.1 the pinnacle of usable security. :)

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com

Hi Scott,

Note: you forgot to copy the list in on your mail. I've not snipped any
of your comments, so others can read them.

Hi Rowan,

(although in that case things will need to be very well documented - as a
non-expert, I would not know when to use seal() vs encrypt() vs aeadEncrypt()
for instance)
Of course.

However, some of the time the cryptography work people want to do is to
interact with other systems. These might require selection of specific
algorithms, which might not be the latest and greatest, but still need to be
implemented somewhere. It would be odd if I wanted to implement, say, OAuth
or XML-Sig, and there were no functions under \Php\Crypto\ to help me with
that.
I'm personally of the opinion that, should you need to integrate with
a specific protocol, you should also be provided a well-studied
library that does that for you by the people you're integrating with,
or otherwise by a cryptography expert in your employment.

But what primitives should those well-studied libraries be built on top
of? Should every such library have to be distributed as a C extension
(annoying for users), or implement low-level bit manipulation in PHP
(slow!)?

The idea of a "PDO-like" library would be to provide the building blocks
for those libraries to work with, so that they didn't have to either
reimplement all their own encryption primitives (surely a bad idea) or
force a dependency on a particular php extension (which is how mcrypt
has become such an albatross).

I wouldn't want to widen the scope here for this project to
incorporate whatever weird requirements other projects have (e.g.
Fernet, with its 0x80 header), because not every protocol is secure.
See also: https://auth0.com/blog/2015/03/31/critical-vulnerabilities-in-json-web-token-libraries/

We shouldn't be accepting responsibility for other peoples' mistakes
here, we should instead aim to prevent them. By providing an
opinionated, conservative, and incredibly easy-to-use correctly
cryptography interface, we ensure that projects whose requirements are
"This needs to be encrypted" are easier for neophytes to get correct.
Also, newer protocols can be constructed atop what we provide.

In that case, I think this needs to be clearer in the proposal, and even
in the name of the extension. Maybe "SimpleCrypto", like "SimpleXML", if
that's not already taken?

Essentially, this is not a library for doing arbitrary encryption, it is
a particular toolkit with its own serialization formats, methods of
operation, etc. It's actually a step higher-level than the abstractions
other people have been talking about, and could be built on top of it:

libsodium (C library) -> pco_sodium (PHP Crypto Objects driver) -> PCO
(framework abstracting crypto implementations) -> SimpleCrypto ("an
opinionated, conservative, and incredibly easy-to-use correctly
cryptography interface").

Ultimately, one of my broader goals is to develop compatibility
interfaces for other languages (in particular: Node.js, Java, C#,
Python, and Ruby) once we have something in place, to promote
interoperability. (These other libraries would be either MIT, WTFPL,
or CC0 licensed by the way.)

This is another good reason to give the extension a snappy name - if you
got your way and this extension lived in the \Crpytography namespace,
how would you signal that a particular Node.js library was intended to
interact with it?

Regards,

--
Rowan Collins
[IMSoP]