Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this 
year, and many of you might not want to discuss what 7.1.x looks like yet.
The current state of cryptography in PHP is, well, abysmal. Our two main 
choices for handling symmetric cryptography are libmcrypt (collecting dust 
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic) 
and GCM support.
While mcrypt is slowly decomposing in the corner and code is being 
desperately migrated towards openssl in case a critical vulnerability is 
discovered in the abandonware choice, the libsodium extension has been 
growing steadily. Thanks to Remi, it should soon be compatible with both 
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself has 
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by 
the next Ubuntu LTS is released.
I think now is a good time to talk about the possibility of making 
libsodium a core PHP extension, depending on where things are when we near 
the 7.1 feature freeze.
I've just opened an RFC for precisely this purpose: 
https://wiki.php.net/rfc/libsodium
Regards,
Scott Arciszewski 
Chief Development Officer 
Paragon Initiative Enterprises <https://paragonie.com
I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
From https://github.com/jedisct1/libsodium-php :
// Binary to hexadecimal 
$hex = Sodium::sodium_bin2hex($bin);
// Hexadecimal to binary 
$bin = Sodium::sodium_hex2bin($hex);
// Hexadecimal to binary, ignoring a set of characters 
$bin = Sodium::sodium_hex2bin($hex, $string_of_characters_to_ignore);
What's the reason for this redundancy (Sodium::sodium_*) ?
thanks,
- Markus
Hi Scott,
On Thu, May 21, 2015 at 10:15 AM, Scott Arciszewski scott@paragonie.com 
wrote:
Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
year, and many of you might not want to discuss what 7.1.x looks like yet.The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting dust
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
and GCM support.While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
the next Ubuntu LTS is released.I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
These are examples from github
$nonce = Sodium::randombytes_buf(Sodium::CRYPTO_SECRETBOX_NONCEBYTES); 
$key = [a binary string that must be CRYPTO_SECRETBOX_KEYBYTES long]; 
$ciphertext = Sodium::crypto_secretbox('test', $nonce, $key); 
$plaintext = Sodium::crypto_secretbox_open($ciphertext, $nonce, $key);
We have coding standard. 
https://github.com/php/php-src/blob/master/CODING_STANDARDS
- 
Method names follow the 'studlyCaps' (also referred to as 'bumpy case' 
 or 'camel caps') naming convention, with care taken to minimize the
 letter count. The initial letter of the name is lowercase, and each
 letter that starts a new 'word' is capitalized::Good: 
 'connect()'
 'getData()'
 'buildSomeWidget()'Bad: 
 'get_Data()'
 'buildsomewidget'
 'getI()'
To include as a core extension, you need standard method names. 
Keeping old names as alias is fine for me, but main names should be 
standard names.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
How should we reconcile your standard recommendations with NaCl proper and 
how libsodium is used in other languages?
I'll try to loop Frank Denis in on this conversation again, but any 
specific objections (esp. bikeshedding) would probably be best moved 
towards new issues on the jedisct1/libsodium GitHub repository.
Hi Scott,
On Thu, May 21, 2015 at 10:15 AM, Scott Arciszewski scott@paragonie.com
wrote:Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
year, and many of you might not want to discuss what 7.1.x looks like yet.The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting dust
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
and GCM support.While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself
has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
the next Ubuntu LTS is released.I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodiumThese are examples from github
$nonce = Sodium::randombytes_buf(Sodium::CRYPTO_SECRETBOX_NONCEBYTES);
$key = [a binary string that must be CRYPTO_SECRETBOX_KEYBYTES long];
$ciphertext = Sodium::crypto_secretbox('test', $nonce, $key);
$plaintext = Sodium::crypto_secretbox_open($ciphertext, $nonce, $key);We have coding standard.
https://github.com/php/php-src/blob/master/CODING_STANDARDS
Method names follow the 'studlyCaps' (also referred to as 'bumpy case'
or 'camel caps') naming convention, with care taken to minimize the
letter count. The initial letter of the name is lowercase, and each
letter that starts a new 'word' is capitalized::Good:
'connect()'
'getData()'
'buildSomeWidget()'Bad:
'get_Data()'
'buildsomewidget'
'getI()'To include as a core extension, you need standard method names.
Keeping old names as alias is fine for me, but main names should be
standard names.Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net
Hi Scott,
On Mon, May 25, 2015 at 6:42 PM, Scott Arciszewski scott@paragonie.com 
wrote:
How should we reconcile your standard recommendations with NaCl proper and
how libsodium is used in other languages?I'll try to loop Frank Denis in on this conversation again, but any
specific objections (esp. bikeshedding) would probably be best moved
towards new issues on the jedisct1/libsodium GitHub repository.
If you look into PHP core modules, you'll notice that almost all 
functions/methods/classes 
that are recently added have standard names.  I'm aware of there are 
exceptions, like old 
names before standards, named wrongly by mistake. These are exceptions. 
Unless 
we honor the standard, we'll never achieve naming consistency.
PHP module should have its own names if function/method names underlying 
library does 
not match the standard. You may name them whatever you think appropriate. 
Getting rid of 
"_" might be good enough for most methods.
Regards,
-- 
Yasuo Ohgaki 
yohgaki@ohgaki.net
Scott,
Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later this
year, and many of you might not want to discuss what 7.1.x looks like yet.The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting dust
since 2007) and openssl, which lacks a streaming API (e.g. mcrypt_generic)
and GCM support.While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist by
the next Ubuntu LTS is released.I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we near
the 7.1 feature freeze.I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodium
While I definitely do like libsodium and consider it a step in the 
right direction, I am hesitant overall. The main reason is precisely 
what happened with mcrypt. In that a library goes unmaintained, and 
all of a sudden we're stuck using unsupported crypto.
I wonder if a PDO-style approach would be better. Where we can have 
multiple pluggable backends, and provide backend-specific 
functionality if needed. Targetting a high-level API, not exposing 
primitives. Something like:
$enc = new SymmetricEncryption(":cipher=aes128;hash=sha256"); 
// Use any available backend which can do aes128+sha256 mac 
var_dump($enc->encrypt("plaintext", $key));
$enc = new SymmetricEncryption("openssl:cipher=arc4;mode=ctr"); 
// Use any available backend which can do aes128+sha256 mac 
var_dump($enc->encrypt("plaintext", $key));
The concept would be that while parts of the algorithm are 
controllable by the end-user (like cipher choice, possibly mode, etc), 
we would attempt to prevent insecure usages (no ECB).
If you have a need for custom encryption (web service uses a custom 
format), then use primitives yourself (like openssl/mcrypt/etc).
My one issue with libsodium is that if you need NIST compliance, it 
does nothing for you (considering it uses XSalsa20+ Poly1305). While 
this is an advantage for some, it's a disadvantage for many.
Ideally, I'd like to see a prototype of this library built in PHP that 
we can play with prior to making into a PECL extension (and ultimately 
proposed for core).
I'd just rather try to get this right, rather than yet another 
maybe-good-enough-for-now solution.
Anthony
That's fair, and one of the reasons I wanted to make ext/libsodium part of 
the core was so that segueing into a PDO-style cryptography API would be 
more natural. Instead of "wrap openssl and maybe wrap libsodium if it's 
already installed" it would be "wrap what the language already has".
Am I mistaken in believing this would be the way forward?
Scott Arciszewski 
Chief Development Officer 
Paragon Initiative Enterprises https://paragonie.com
On Tue, May 26, 2015 at 6:47 PM, Anthony Ferrara ircmaxell@gmail.com 
wrote:
Scott,
On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski scott@paragonie.com
wrote:Hi Internals Team,
I'm sure everyone is really focused (and excited) for PHP 7.0.0 later
this
year, and many of you might not want to discuss what 7.1.x looks like
yet.The current state of cryptography in PHP is, well, abysmal. Our two main
choices for handling symmetric cryptography are libmcrypt (collecting
dust
since 2007) and openssl, which lacks a streaming API (e.g.
mcrypt_generic)
and GCM support.While mcrypt is slowly decomposing in the corner and code is being
desperately migrated towards openssl in case a critical vulnerability is
discovered in the abandonware choice, the libsodium extension has been
growing steadily. Thanks to Remi, it should soon be compatible with both
PHP 5.x and 7.x (decided at compile-time). The libsodium library itself
has
landed in Debian 8 and Ubuntu 15.04 and adoption is expected to persist
by
the next Ubuntu LTS is released.I think now is a good time to talk about the possibility of making
libsodium a core PHP extension, depending on where things are when we
near
the 7.1 feature freeze.I've just opened an RFC for precisely this purpose:
https://wiki.php.net/rfc/libsodiumWhile I definitely do like libsodium and consider it a step in the
right direction, I am hesitant overall. The main reason is precisely
what happened with mcrypt. In that a library goes unmaintained, and
all of a sudden we're stuck using unsupported crypto.I wonder if a PDO-style approach would be better. Where we can have
multiple pluggable backends, and provide backend-specific
functionality if needed. Targetting a high-level API, not exposing
primitives. Something like:$enc = new SymmetricEncryption(":cipher=aes128;hash=sha256");
// Use any available backend which can do aes128+sha256 mac
var_dump($enc->encrypt("plaintext", $key));$enc = new SymmetricEncryption("openssl:cipher=arc4;mode=ctr");
// Use any available backend which can do aes128+sha256 mac
var_dump($enc->encrypt("plaintext", $key));The concept would be that while parts of the algorithm are
controllable by the end-user (like cipher choice, possibly mode, etc),
we would attempt to prevent insecure usages (no ECB).If you have a need for custom encryption (web service uses a custom
format), then use primitives yourself (like openssl/mcrypt/etc).My one issue with libsodium is that if you need NIST compliance, it
does nothing for you (considering it uses XSalsa20+ Poly1305). While
this is an advantage for some, it's a disadvantage for many.Ideally, I'd like to see a prototype of this library built in PHP that
we can play with prior to making into a PECL extension (and ultimately
proposed for core).I'd just rather try to get this right, rather than yet another
maybe-good-enough-for-now solution.Anthony
That's fair, and one of the reasons I wanted to make ext/libsodium part of
the core was so that segueing into a PDO-style cryptography API would be
more natural. Instead of "wrap openssl and maybe wrap libsodium if it's
already installed" it would be "wrap what the language already has".Am I mistaken in believing this would be the way forward?
Well, it doesn't quite match how PDO works, as I understand it - 
ext/pdo_pgsql isn't implemented on top of ext/pgsql, the two are 
separate extensions built on top of the libPQ library which Postgres 
provides. The "PHP Crypto Objects" equivalent would be "wrap openssl in 
ext/pco_openssl, wrap libsodium in ext/pco_sodium".
The dependency management would be no different between ext/openssl and 
ext/pco_openssl - PHP doesn't provide OpenSSL or mcrypt, it 
optionally depends on them, and the same would be true of libsodium, 
whatever the bindings looked like.
As such, bundling an extension which directly exposes libsodium's 
functions isn't really a pre-requisite for a pluggable architecture, and 
could harm the effort by being "too good" and allowing the short-term 
"good enough" solution that Anthony is afraid of.
Regards,
Rowan Collins 
[IMSoP]
Hi,
I like Anthony's idea of a crypto framework (abstracting away whatever 
underlying library is actually used). Not sure yet how this could be 
implemented though.
For what it's worth, I started playing with libtomcrypt (yet another 
crypto API) a few weeks ago as an attempt to replace the old mcrypt 
extension for my own needs. I found it quite easy to work with, plus the 
license is very permissive (WTFPL).
The result can be seen at https://github.com/fpoirotte/tomcrypt. 
This is basically a thin wrapper around libtomcrypt's API. 
The code still has many issues I need to resolve (lack of unit tests, 
parameter parsing using improper types, not ready for PHP 7 yet, etc.) 
but I found it to be pretty usable already.
Would there be any wider interest for such an extension?
Regards, 
François
That's fair, and one of the reasons I wanted to make ext/libsodium
part of
the core was so that segueing into a PDO-style cryptography API would be
more natural. Instead of "wrap openssl and maybe wrap libsodium if it's
already installed" it would be "wrap what the language already has".Am I mistaken in believing this would be the way forward?
Well, it doesn't quite match how PDO works, as I understand it -
ext/pdo_pgsql isn't implemented on top of ext/pgsql, the two are
separate extensions built on top of the libPQ library which Postgres
provides. The "PHP Crypto Objects" equivalent would be "wrap openssl in
ext/pco_openssl, wrap libsodium in ext/pco_sodium".The dependency management would be no different between ext/openssl and
ext/pco_openssl - PHP doesn't provide OpenSSL or mcrypt, it
optionally depends on them, and the same would be true of libsodium,
whatever the bindings looked like.As such, bundling an extension which directly exposes libsodium's
functions isn't really a pre-requisite for a pluggable architecture, and
could harm the effort by being "too good" and allowing the short-term
"good enough" solution that Anthony is afraid of.Regards,