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]
--
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php
