PHP 7.1 Cryptography Projects

Hi!

1. Pluggable Cryptography Frontend

Work is currently underway for a PHP prototype for this idea
originally suggested by ircmaxell, that will basically be like PDO for
cryptography. Our current project name, subject to change, is PHP
Crypto Objects (PCO).

It would be nice to see full RFC (or other extensively documented
proposal) about this. I like the idea, though I wonder isn't mcrypt
essentially doing the same? It would be nice to see the description of
the added value provided over mcrypt, openssl, etc. extensions.

2. Cache-timing-safe character encoding functions

Alternatives for existing functions that should function like their
unsafe counterparts, but without branches or data-based index lookups.

• hex2bin() -> hex2bin_ts()
• bin2hex() -> bin2hex_ts()
• base64_encode() -> base64_encode_ts()
• base64_decode() -> base64_decode_ts()

Why specifically these functions? It would be nice to hear rationale for
this.

• Improving the OpenSSL API, or at least the documentation

Improving documentation is always a worthy goal!

• Adding streaming encryption/decryption support to OpenSSL

Hm... Implementing streaming cyphers right is not trivial, and if we'd
be doing our own crypto (as opposed to providing API to existing
libraries) we need a real lot of review to be confident it's done right.

What I need from you is guidance on what features or changes you want
to see in 7.1 and which can be put off until later (or never proposed
as an RFC at all).

Seriously, all I need is your opinion and whether or not you'd like to
see any of these happen. If you have specific implementation details
you'd like to discuss or requests, of course those are welcome too. :D

I think it'd be nice to see more details on the proposal. I.e.
"improving OpenSSL API" - how? PCO - great, but what API would it offer
and how that API is better than what we have now? The idea of making
crypto easier is great, but if we want to make specific plans as of
which features we want, we need more detailed proposals I think.

--
Stas Malyshev
smalyshev@gmail.com

Hi Stanislav,

It would be nice to see full RFC (or other extensively documented
proposal) about this. I like the idea, though I wonder isn't mcrypt
essentially doing the same? It would be nice to see the description of
the added value provided over mcrypt, openssl, etc. extensions.

The idea here isn't too far removed from what PDO does versus mysql_,
mssql_, pgsql_*, etc. except it's probably more critical: Switch
crypto backends with almost zero refactoring; just change your
constructor.

Also, libmcrypt has been abandoned and we should look into rm -rf /ing
ext/mcrypt in a future PHP version (say, 8.0).

https://paragonie.com/blog/2015/05/if-you-re-typing-word-mcrypt-into-your-code-you-re-doing-it-wrong

Why specifically these functions? It would be nice to hear rationale for
this.

Developers are, quite rationally, going to want to store their
encryption key in configuration files. (INI, JSON, XML, YAML, .env
files, etc.) In doing so, they will generally choose to encode these
functions in base-16 or base-64 for storage purposes.

Offering timing-safe encoding functions adds no negligible cost but
prevents cache-timing attacks (especially relevant if you're doing
cryptography in "the cloud" -- check out FLUSH+RELOAD attacks, for
example) that could otherwise leak your secret key.

Hm... Implementing streaming cyphers right is not trivial, and if we'd
be doing our own crypto (as opposed to providing API to existing
libraries) we need a real lot of review to be confident it's done right.

You're right. Luckily this is a road I've already traveled with
defuse/php-encryption.

https://github.com/defuse/php-encryption/pull/78

Anyone who wants to help everyone using PHP 5 while also providing
guidance and words of caution that we can reference when developing
this feature for 7.1 is invited to hammer at that PR.

I think it'd be nice to see more details on the proposal. I.e.
"improving OpenSSL API" - how? PCO - great, but what API would it offer
and how that API is better than what we have now? The idea of making
crypto easier is great, but if we want to make specific plans as of
which features we want, we need more detailed proposals I think.

Which brings me to the meat of the proposal: Although the interface I
introduced in the first post only mentions encrypt() and decrypt(),
that's actually not the whole truth. PCO\Symmetric will only ever, and
this is not negotiable, offer Authenticated Encryption modes:

• AES-CBC + HMAC-SHA256
• AES-CTR + HMAC-SHA256
• AES-GCM
• XSalsa20 + Poly1305
• Salsa20 + Poly1305
• ChaCha20 + Poly1305

openssl_encrypt() does not authenticate ciphertexts for you.
mcrypt_encrypt() does not authenticate ciphertexts for you.
\Sodium\crypto_secretbox() DOES authenticate ciphertexts for you.

If anyone is unclear on why authenticated encryption is important,
I've explained it in great detail here:
https://paragonie.com/blog/2015/05/using-encryption-and-authentication-correctly

Unless your driver does this (e.g. libsodium),
\PCO\Symmetric::encrypt() will always Encrypt then MAC, and verify the
MAC (in constant time!) before decrypting, and the user never has to
concern themselves with such details. All they will know is that their
messages are encrypted, and tampering with the encrypted data throws
an exception when they try to decrypt it afterwards.

There will also be an aeadEncrypt() and aeadDecrypt() interface, which
allows you to authenticate associated data which is not encrypted.

This will all be documented in the RFC when it comes time to open it
(as well as the Github repository for the PHP extension when we get to
this point), so if anyone misses this email don't worry. :)

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

• Adding streaming encryption/decryption support to OpenSSL

Hm... Implementing streaming cyphers right is not trivial, and if we'd
be doing our own crypto (as opposed to providing API to existing
libraries) we need a real lot of review to be confident it's done right.

I totally agree. Except bundling existing widely used code (if really
necessary, like what we did for blowfish for example), I would
strongly recommend to never even try to implement our own crypto
features.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org

>
>
>> $AES = new \PCO\Symmetric('openssl:cipher=AES-128');
>>
>
> It would be great if you could just ask for cipher=AES-128 without
> explicitly specifying the provider (openssl).
>
>
Even better would be splitting arguments up. There's not much point to
multi-valued arguments, they're just harder to parse/memorize.
If you need a common constructor, use a configuration object instead of a
made-up string format.

Apart from that, thumbs up on this!


--

WWW: plphp.dk / plind.dk
CV: careers.stackoverflow.com/peterlind
LinkedIn: plind
Twitter: kafe15

$AES = new \PCO\Symmetric('openssl:cipher=AES-128');

It would be great if you could just ask for cipher=AES-128 without
explicitly specifying the provider (openssl).

--
Lauri Kenttä

Hi Lauri,

That's a good suggestion that has come up before in the draft discussion.

We're still discussing the DSN string for the constructor. These are
what the options look like, currently:

• ":cipher=AES-256;mode=GCM" should use whatever driver allows
  aes-256-gcm`or throw an exception if none are available
• "openssl:cipher=AES-256;mode=GCM" should use specifically openssl
  for aes-256-gcm, and throw an exception if openssl is not installed
• "libsodium" should use libsodium (or throw an exception if it's not
  installed) in the default configuration
• "openssl" should use openssl in a secure, sane default
• "openssl:cipher=AES-128;mode=ECB" should throw an exception because
  we do not allow secure modes
• "openssl:cipher=AES-128;hash=SHA256" should use AES-128-CTR with HMAC-SHA-256
• "openssl:cipher=AES-192;mode=CBC;hash=SHA384" should use AES-192-CBC
  with HMAC-SHA-384

Version and configuration information (not what is passed, but what is
used) will be stored in the first few bytes of ciphertext output.

Cheers,

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

Hi,

On Mon, Aug 3, 2015 at 9:54 PM, Scott Arciszewski scott@paragonie.com
wrote:

Hi,

I would like to make it easier for PHP developers to implement
cryptography features in their applications. I intend to work on some
of these ideas and submit them for inclusion in PHP 7.1.

Some of these might be familiar to some of you.

1. Pluggable Cryptography Frontend

Work is currently underway for a PHP prototype for this idea
originally suggested by ircmaxell, that will basically be like PDO for
cryptography. Our current project name, subject to change, is PHP
Crypto Objects (PCO).

The idea is that you could write code like this to add secure
authenticated encryption to your application without having to worry
about the details.

$AES = new \PCO\Symmetric('openssl:cipher=AES-128');
$ciphertext = $AES->encrypt($plaintext, $someKey);

$PKC = new \PCO\Asymmetric('libsodium');
$offlineDecryptable = $PKC->seal($plaintext, $someX25519PublicKey);

When it's finished, I'd like to turn it into a PECL extension so users
can play with it in PHP 7.0 and submit it for inclusion in 7.1.

2. Cache-timing-safe character encoding functions

Alternatives for existing functions that should function like their
unsafe counterparts, but without branches or data-based index lookups.

• hex2bin() -> hex2bin_ts()
• bin2hex() -> bin2hex_ts()
• base64_encode() -> base64_encode_ts()
• base64_decode() -> base64_decode_ts()

Other formats are out of scope, unless someone can make the case that
we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
Service integration).

3. Other ideas (not yet committed to at all, but might be of interest
   to others):

• Improving the OpenSSL API, or at least the documentation
• Adding streaming encryption/decryption support to OpenSSL
• Adding AE and AEAD interfaces to OpenSSL
• Aliasing MCRYPT_AES -> MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR

What I need from you is guidance on what features or changes you want
to see in 7.1 and which can be put off until later (or never proposed
as an RFC at all).

Seriously, all I need is your opinion and whether or not you'd like to
see any of these happen. If you have specific implementation details
you'd like to discuss or requests, of course those are welcome too. :D

I have been actually working on something similar for some time. It's
already on PECL and it's called php-crypto:

https://github.com/bukka/php-crypto

I have been doing lots of changes and fixes including support for PHP 7 (it
also supports PHP 5 using https://github.com/bukka/phpc wrapper) and php
streams. The internal part has been almost completely rewritten since
version 0.1.0 and I plan to release soon 0.2.0 so I will send some update
then.

I'm currently working on fixing some issues, improving tests and mainly
documentation that is still very incomplete (just hash is partially
documented in the main readme) so probably the best doc at the moment is
generated api doc:

https://github.com/bukka/php-crypto/blob/master/docs/Crypto.php

There also are some examples in
https://github.com/bukka/php-crypto/blob/master/examples and even more
examples in tests where is about 70 tests:
https://github.com/bukka/php-crypto/blob/master/tests

In case you are interested in what I plan to do in the near future, it's all
in my TODO list: https://github.com/bukka/php-crypto/blob/master/TODO.md

In the long term I would like to add support for asymmetric encryption. I
actually wrote an extension called php-rsa (
https://github.com/bukka/php-rsa ) just to play with OpenSSL rsa.h (there is
no doc but you can look to the tests if you are interested). However the way
how it should be done in crypto is more about using PKEY which is much more
flexible but it will be supported only for OpenSSL 1.0.0+.

The providers (pluggable api) is a nice thing but it will require quite a
bit of thinking to make it right from the internal PoV (address all needs of
particular libs - especially OpenSSL) and it's quite a bit of work as well
:) But it would be definitely nice to have and I have been thinking about it
for some time. But the priority is a creating of a good wrapper for OpenSSL
first and then split it to more layers.

Cheers

Jakub

This does not appear to authenticate ciphertexts, nor does it serve as
a gateway to Libsodium / OpenSSL.

We are, in fact, working on different projects with different goals.

In the long term I would like to add support for asymmetric encryption. I
actually wrote an extension called php-rsa (
https://github.com/bukka/php-rsa ) just to play with OpenSSL rsa.h (there is
no doc but you can look to the tests if you are interested). However the way
how it should be done in crypto is more about using PKEY which is much more
flexible but it will be supported only for OpenSSL 1.0.0+.

Strictly personally speaking, I'm far more interested in EdDSA and
ECDH than I am in RSA.

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

Hi,

I would like to make it easier for PHP developers to implement
cryptography features in their applications. I intend to work on some
of these ideas and submit them for inclusion in PHP 7.1.

Awesome and long due work :)

Some of these might be familiar to some of you.

1. Pluggable Cryptography Frontend

Work is currently underway for a PHP prototype for this idea
originally suggested by ircmaxell, that will basically be like PDO for
cryptography. Our current project name, subject to change, is PHP
Crypto Objects (PCO).

The idea is that you could write code like this to add secure
authenticated encryption to your application without having to worry
about the details.

$AES = new \PCO\Symmetric('openssl:cipher=AES-128');
$ciphertext = $AES->encrypt($plaintext, $someKey);

$PKC = new \PCO\Asymmetric('libsodium');
$offlineDecryptable = $PKC->seal($plaintext, $someX25519PublicKey);

When it's finished, I'd like to turn it into a PECL extension so users
can play with it in PHP 7.0 and submit it for inclusion in 7.1.

I like the idea of a common API for all possible supported backend. I
am however really convinced about the one proposed here. That's
something we will need to really design well and userfriendly.

2. Cache-timing-safe character encoding functions

Alternatives for existing functions that should function like their
unsafe counterparts, but without branches or data-based index lookups.

• hex2bin() -> hex2bin_ts()
• bin2hex() -> bin2hex_ts()
• base64_encode() -> base64_encode_ts()
• base64_decode() -> base64_decode_ts()

For most functions I would prefer an option.

--
Pierre

@pierrejoye | http://www.libgd.org

This isn't a replacement, they're alternatives. -> means related to in
this case, not "becomes" :)

Or do you mean to add a parameter to the existing functions to make
them constant time?

Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises

Am 3.8.2015 um 22:54 schrieb Scott Arciszewski scott@paragonie.com:

Hi,

I would like to make it easier for PHP developers to implement
cryptography features in their applications. I intend to work on some
of these ideas and submit them for inclusion in PHP 7.1.

Some of these might be familiar to some of you.

1. Pluggable Cryptography Frontend

Work is currently underway for a PHP prototype for this idea
originally suggested by ircmaxell, that will basically be like PDO for
cryptography. Our current project name, subject to change, is PHP
Crypto Objects (PCO).

The idea is that you could write code like this to add secure
authenticated encryption to your application without having to worry
about the details.

$AES = new \PCO\Symmetric('openssl:cipher=AES-128');
$ciphertext = $AES->encrypt($plaintext, $someKey);

$PKC = new \PCO\Asymmetric('libsodium');
$offlineDecryptable = $PKC->seal($plaintext, $someX25519PublicKey);

When it's finished, I'd like to turn it into a PECL extension so users
can play with it in PHP 7.0 and submit it for inclusion in 7.1.

2. Cache-timing-safe character encoding functions

Alternatives for existing functions that should function like their
unsafe counterparts, but without branches or data-based index lookups.

• hex2bin() -> hex2bin_ts()
• bin2hex() -> bin2hex_ts()
• base64_encode() -> base64_encode_ts()
• base64_decode() -> base64_decode_ts()

Other formats are out of scope, unless someone can make the case that
we need to support RFC 4648 base32 encoding (e.g. for Tor Hidden
Service integration).

3. Other ideas (not yet committed to at all, but might be of interest
   to others):

• Improving the OpenSSL API, or at least the documentation
• Adding streaming encryption/decryption support to OpenSSL
• Adding AE and AEAD interfaces to OpenSSL
• Aliasing MCRYPT_AES -> MCRYPT_RIJNDAEL_128, adding MCYPT_MODE_CTR

What I need from you is guidance on what features or changes you want
to see in 7.1 and which can be put off until later (or never proposed
as an RFC at all).

Seriously, all I need is your opinion and whether or not you'd like to
see any of these happen. If you have specific implementation details
you'd like to discuss or requests, of course those are welcome too. :D

"With great ubiquity comes great responsibility." - Matthew Green
https://twitter.com/matthew_d_green/status/578567678492733440

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

Hey,

I went ahead and just made bin2hex()/hex2bin() timing safe as a first step.

See https://github.com/php/php-src/pull/1453 https://github.com/php/php-src/pull/1453

Note that it does not add extra functions, but just because performance is just about as good as before [or even better in cases of severe mispredictions].

Nice work :)

If there’s no negative feedback, I’m going to merge that in a few days into master.

We are in feature freeze so please hang on the push.

Also time safe functions may be trickier than it looks. We have to be
very careful by declaring one timesafe (or safe at all) so a peer
reviews are a must here. A RFC too. Let not rush and push something
possibly buggy too early.

Cheers,

Pierre

@pierrejoye | http://www.libgd.org