Re: [RFC] Libsodium - Discussion

On Wed, Jun 1, 2016 at 9:46 AM, Marco Pivetta <ocramius@gmail.com> wrote: > On 1 June 2016 at 15:45, Scott Arciszewski <scott@paragonie.com> wrote: > >> On Wed, Jun 1, 2016 at 6:48 AM, Marco Pivetta <ocramius@gmail.com> wrote: >> >>> Hey Scott, >>> >>> On 1 June 2016 at 09:49, Scott Arciszewski <scott@paragonie.com> wrote: >>> >>>> Hi PHP Internals Team, >>>> >>>> Let's begin discussing the prospect of adding libsodium as a core >>>> extension >>>> in PHP 7.1. I've updated the RFC to explain why this would be a good >>>> idea >>>> and the benefits it offers. >>>> >>>> https://wiki.php.net/rfc/libsodium >>>> >>>> If the subsequent discussion goes smoothly, I would like to open voting >>>> on >>>> June 15. >>>> >>>> Together, let's make PHP cryptography so safe that it becomes boring. >>>> >>> >>> First, thanks for providing better alternatives to crypto in PHP! >>> >>> I also agree with Remi on naming: let's avoid calling the extension >>> libsodium. >>> >>> I have some concerns that are just about code quality, not about >>> functionality. Consider that I didn't look at the underlying library (and I >>> really care little about it, from a consumer perspective). >>> >>> 1. is there a particular reason why abbreviations are used? For >>> instance, why sodium_randombytes_buf() instead of >>> sodium_random_bytes_buffer()? >>> 2. from a naming perspective, I'd expect >>> sodium_randombytes_buf() to >>> give me a buffer of random bytes (probably as a stream), but it returns the >>> actual string of random bytes. Again: confusing naming >>> 3. can we avoid using "themed" naming? For example, instead of >>> sodium_crypto_secretbox(), it would be best to express >>> what it actually >>> does, like sodium_encrypt_and_sign(). While the naming >>> may be emerging >>> from lower layers, I still (like I did with other RFCs) disagree with >>> inheriting confusing naming. This will just cause users to look up the >>> naming up when reading or writing code, and ultimately add up to silly >>> bugs. I can already foresee that people will use the API incorrectly just >>> because of the naming. >>> 4. can't we just keep it namespaced under Sodium, >>> instead of adding >>> more stuff to the root level namespace? Does anyone have a reference to the >>> coding standards that would cause the rename? >>> >>> Cheers, >>> >>> Marco Pivetta >>> >>> http://twitter.com/Ocramius >>> >>> http://ocramius.github.com/ >>> >>> >> ​I'd love to just keep the namespace personally >> ​ ( >> Ke >> ​eping \Sodium\foo() and \SODIUM\FOO means code I've written today will >> work in 7.1 for non-PECL users >> ​, and less work we thrust on Frank Denis)​ >> ​ >> but it was previously expressed that doing so violates the coding >> standard. >> ​ Changing to sodium_* would mean less bikeshedding and automatic "No" >> votes. >> > > Weird... I guess we could add a subsection to the vote? > > >> As for the function names, that's what they were called in NaCl. >> https://nacl.cr.yp.to/secretbox.html >> >> I believe randombytes_buf() was named in a similar spirit to OpenBSD's >> arc4random_buf(). >> > > Yeh, that is software archaeology though, not software design ;-) > > Marco Pivetta > > http://twitter.com/Ocramius > > http://ocramius.github.com/ > > Strictly speaking, ​ our​ random_bytes()​ ​ is every bit good enough without \Sodium\randombytes_buf(), for the PHP use case. We might be able to trim some redundant features (however, unless we make all the PHP encoding functions cache-timing-safe, will insist on keeping \Sodium\bin2hex and \Sodium\hex2bin). Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com/>