Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:90466
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 74.125.82.54 as permitted sender)
To: Scott Arciszewski <scott@paragonie.com>,
 PHP Internals <internals@lists.php.net>
References: <CAKws9z3Bdi=ehFn+QMah2BR7NQJSq91-WimPCdro=7i2CQSiQg@mail.gmail.com>
 <5692B742.5030303@gmail.com>
 <CAKws9z0XOrO+0YYbdvzvS6zeLoe82VvJ_C5DqADaVWd6=9kuVA@mail.gmail.com>
Message-ID: <5692D18B.6000308@gmail.com>
Date: Sun, 10 Jan 2016 21:47:55 +0000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101
 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <CAKws9z0XOrO+0YYbdvzvS6zeLoe82VvJ_C5DqADaVWd6=9kuVA@mail.gmail.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [PHP-DEV] [RFC] PHP 7.1 - Simple Cryptography Interface
From: rowan.collins@gmail.com (Rowan Collins)

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.

On 10/01/2016 20:08, Scott Arciszewski wrote:
> 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]