[RFC] [PHP 7.1] libsodium

On 21.05.2015 03:15, Scott Arciszewski wrote:

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:

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 6. 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,

Scott, On Wed, May 20, 2015 at 9:15 PM, Scott Arciszewski <scott@paragonie.com> wrote:

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