Re: [RFC] Libsodium - Discussion

On Sun, Jun 5, 2016 at 4:31 AM, Fleshgrinder <php@fleshgrinder.com> wrote: > On 6/5/2016 10:23 AM, Scott Arciszewski wrote: >> I'm trying to keep concerns separate. I do want to make the pluggable >> crypto API happen, but I barely have time for this libsodium RFC and I >> don't want to conflate the two. (Even worse: I wouldn't want the mere >> thought of an abstract high-level API to block libsodium from getting >> accepted.) >> >> Instead of /completely redesigning/ the libsodium API, what are some >> changes that need to be made to alleviate the majority of concerns >> ("it's not the pluggable crypto API" notwithstanding)? >> >> Two things to keep in mind: >> >> 1. If it breaks existing code that uses libsodium-php in a nontrivial >> way, I'm going to resist the change unless it can be proven necessary >> for the sake of everyone's sanity. >> 2. If it greatly deviates from the experience of using libsodium in >> other programming languages (e.g. renaming crypto_box), you no longer >> have libsodium and thus I will resist it. >> >> Getting rid of redundant features (by improving existing ones, not >> just cutting them!) is fine. Dropping scrypt, etc. is fine. >> > > Keeping sodium as an extension solves all your problems. You can keep > evolving it in any way you like without having to argue with others. No > breaking changes, nothing. It can even be used after another API is > introduced in core. All my problems? How do I get non-root users to install it? > We can achieve this by introducing a different API in core that uses > sodium in the background. This also allows us to exchange it without any > interruptions in userland in the future. That's the pluggable crypto API RFC, which I probably won't be able to propose until 7.2. Feel free to pick it up if you'd rather advocate for that. > If existing functions like bin2hex or hex2bin are really not good enough > than let us patch them. No need to introduce another function that does > exactly the same. Whether the two are consistent in time or not does not > change anything for userland. The resulting string is always the same. I > think that the patch for aforementioned functions would even be possible > without an RFC. Okay, that's fine by me. > The usage of names like secret box and box is simply not known to the > average user and that makes them really bad. People will have to search > the manual and dig deep until they find out that it is just about > asymmetric and symmetric encryption. We already have enough stuff that > makes no sense to the general public but to some. Put yourself in the shoes of, say, a Python developer who uses libsodium all the time who comes to PHP. If they don't find crypto_box and crypto_secretbox, they're going to get confused. > -- > Richard "Fleshgrinder" Fussenegger > Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises <https://paragonie.com>