# [RFC] Libsodium - Thread: https://externals.io/message/90249 - Original archive: https://news-web.php.net/php.internals/90249 - Started by Scott Arciszewski on 2016-01-07T13:26:52+00:00 - Messages: 25 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #90249 — Scott Arciszewski — 2016-01-07T13:26:52+00:00 URL: https://externals.io/message/90249#90249 Hi everyone, I've updated the RFC to make libsodium a core PHP extension in 7.1, to include references to the online documentation. https://wiki.php.net/rfc/libsodium All new functions and classes would exist in the Sodium namespace. e.g. $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair); This is part of an overall effort to improve PHP's cryptography; up next will be the pluggable crypto API that supports multiple backends (with a scope limited to openssl and libsodium at the time of release) but always provide conservative defaults. Then I'd like to look at deprecating ext/mcrypt back to PECL and add more hash functions to ext/hash. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises wrote: > I've updated the RFC to make libsodium a core PHP extension in 7.1, to > include references to the online documentation. > > https://wiki.php.net/rfc/libsodium > > All new functions and classes would exist in the Sodium namespace. e.g. > > $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair); > > This is part of an overall effort to improve PHP's cryptography; up > next will be the pluggable crypto API that supports multiple backends > (with a scope limited to openssl and libsodium at the time of release) > but always provide conservative defaults. Then I'd like to look at > deprecating ext/mcrypt back to PECL and add more hash functions to > ext/hash. > +1. Only comment is on namespace: how about \Php\Ext\Sodium? I don't know if namespacing PHP engine components has been standardized, but I feel we should limit how often the engine consumes names in the global namespace. E.g, I could see a user wanting "Sodium" for an app name, but couldn't use it simultaneously with the libsodium extension. --- ## #90253 — Scott Arciszewski — 2016-01-07T15:31:59+00:00 URL: https://externals.io/message/90249#90253 · In reply to: #90252 > On Thu, Jan 7, 2016 at 8:26 AM, Scott Arciszewski > wrote: > > […] > > > +1. Only comment is on namespace: how about \Php\Ext\Sodium? I don't know > if namespacing PHP engine components has been standardized, but I feel we > should limit how often the engine consumes names in the global namespace. > E.g, I could see a user wanting "Sodium" for an app name, but couldn't use > it simultaneously with the libsodium extension. Originally it was Sodium::function_name, but people complained. I don't personally have a stake in this course of discussion. I'm fine with almost anything, but the PECL extension, which has a "stable" release, uses \Sodium\* already. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises Hi everyone, > > I've updated the RFC to make libsodium a core PHP extension in 7.1, to > include references to the online documentation. > > https://wiki.php.net/rfc/libsodium > > All new functions and classes would exist in the Sodium namespace. e.g. > > $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair); As much as I like libsodium, yet another extension with yet another library in the core sounds like a risk to me, long term. I would rather prefer to focus on a larger effort to provide the necessary features in the most easiest way using new APIs or existing extensions, as you mentioned already in previous discussions and in this mail. That's why I won't be in favor of bundling this one. > This is part of an overall effort to improve PHP's cryptography; up > next will be the pluggable crypto API that supports multiple backends > (with a scope limited to openssl and libsodium at the time of release) > but always provide conservative defaults. Then I'd like to look at > deprecating ext/mcrypt back to PECL and add more hash functions to > ext/hash. This is definitely the way. Thanks for your great work :) Cheers, Pierre --- ## #90255 — me@rouvenwessling.de — 2016-01-07T15:52:50+00:00 URL: https://externals.io/message/90249#90255 · In reply to: #90249 Hi Scott, questions inline. > > > I've updated the RFC to make libsodium a core PHP extension in 7.1, to > include references to the online documentation. > > https://wiki.php.net/rfc/libsodium I know this is made difficult by the fact that this is an existing, stable PECL extension, which also supports older PHP versions but I don’t think it’s a good idea to introduce more functions that duplicate things handled already in core (I don’t mean in ext-openssl as lib sodium would be an alternative to that extension). I’d rather see less duplication, not more. From a quick glance the following functions seems to be already covered: \Sodium\memcmp \Sodium\bin2hex \Sodium\hex2bin \Sodium\randombytes_buf \Sodium\randombytes_uniform \Sodium\randombytes_random16 If their implementation is better than the core implementation, core should be fixed. Do the hashing functions have any advantage over those provided by ext-hash? There are also a couple of other functions whose value I’d question, I’ll send an email about those later. > This is part of an overall effort to improve PHP's cryptography; up > next will be the pluggable crypto API that supports multiple backends > (with a scope limited to openssl and libsodium at the time of release) > but always provide conservative defaults. A more general question: I haven’t looked at your prototype for a higher level API yet, but I’m wondering if it’s still necessary to introduce another low level API? When would I choose to use the latter? Best regards Rouven --- ## #90257 — Scott Arciszewski — 2016-01-07T15:54:51+00:00 URL: https://externals.io/message/90249#90257 · In reply to: #90255 > Hi Scott, > > questions inline. > > > […] > > I know this is made difficult by the fact that this is an existing, stable PECL extension, which also supports older PHP versions but I don’t think it’s a good idea to introduce more functions that duplicate things handled already in core (I don’t mean in ext-openssl as lib sodium would be an alternative to that extension). I’d rather see less duplication, not more. > > From a quick glance the following functions seems to be already covered: > \Sodium\memcmp > \Sodium\bin2hex > \Sodium\hex2bin > \Sodium\randombytes_buf > \Sodium\randombytes_uniform > \Sodium\randombytes_random16 > > If their implementation is better than the core implementation, core should be fixed. > > Do the hashing functions have any advantage over those provided by ext-hash? > > There are also a couple of other functions whose value I’d question, I’ll send an email about those later. > > > […] > > A more general question: I haven’t looked at your prototype for a higher level API yet, but I’m wondering if it’s still necessary to introduce another low level API? When would I choose to use the latter? > > Best regards > Rouven The high-level API ties the user's hands and doesn't give them direct access to primitives. You can't use it for AES-256-ECB, you can only use it for AES-256-CTR+HMAC-SHA-384, with an encoded and version-tagged output, for example. You still need ext/libsodium if you need to use any of its features directly, such as \Sodium\memzero(). Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > > […] > > The high-level API ties the user's hands and doesn't give them direct > access to primitives. You can't use it for AES-256-ECB, you can only > use it for AES-256-CTR+HMAC-SHA-384, with an encoded and > version-tagged output, for example. > > You still need ext/libsodium if you need to use any of its features > directly, such as \Sodium\memzero(). > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises To clarify: You can swap out AES-256 for AES-192, or SHA-384 for SHA-256, etc. You cannot swap out the protocol construction for anything other than Encrypt then MAC. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises HI Scott, > > > > […] > > As much as I like libsodium, yet another extension with yet another > library in the core sounds like a risk to me, long term. I would > rather prefer to focus on a larger effort to provide the necessary > features in the most easiest way using new APIs or existing > extensions, as you mentioned already in previous discussions and in > this mail. That's why I won't be in favor of bundling this one. > > > […] > > This is definitely the way. Thanks for your great work :) > > Cheers, > Pierre Hi Pierre, > As much as I like libsodium, yet another extension with yet another > library in the core sounds like a risk to me, long term. I would > rather prefer to focus on a larger effort to provide the necessary > features in the most easiest way using new APIs or existing > extensions, as you mentioned already in previous discussions and in > this mail. That's why I won't be in favor of bundling this one. Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd see it as a risk? ---------------- Let me state this clearly: I'm personally not going to bother pushing for a pluggable crypto API if the only option is to use OpenSSL and all its legacy cruft. I especially don't have lukewarm feelings towards RSA or ECDSA, which are your only real options with it. I feel that it simply would not be a worthwhile use of my time to do so. If Internals decides "no libsodium" but "yes pluggable crypto API", you'll have to find someone else to spearhead it. And I've said everything that needs to be said about mcrypt when I said, "Kill it with fire!" Now that we have `random_bytes()` there is nothing redeemable about it. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > > […] > > Hi Pierre, > > > […] > > Even if we axe mcrypt and in with a net-gain of 0 extensions, you'd > see it as a risk? Except that we already refused to kill mcrypt, and it is not like I did not try to convince us to kill it. Does your extension provide a compatibility layer? I may have missed that :) > ---------------- > > Let me state this clearly: I'm personally not going to bother pushing > for a pluggable crypto API if the only option is to use OpenSSL and > all its legacy cruft. I especially don't have lukewarm feelings > towards RSA or ECDSA, which are your only real options with it. > > I feel that it simply would not be a worthwhile use of my time to do > so. If Internals decides "no libsodium" but "yes pluggable crypto > API", you'll have to find someone else to spearhead it. Sorry, my point was not clear. I do like the concept of a pluggable crypto API. Very much. I said it before and I say it again. I love the concept and will do what I can to support it :) What I do not like too much is the addition of an extension with (relatively) low level functions for one specific library. It does not really matter how good is this specific library, I simply do not see such addition as a good strategic move. > And I've said everything that needs to be said about mcrypt when I > said, "Kill it with fire!" Now that we have `random_bytes()` there is > nothing redeemable about it. Full ack. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #90265 — Anthony Ferrara — 2016-01-07T16:30:14+00:00 URL: https://externals.io/message/90249#90265 · In reply to: #90262 Pierre, > > […] > > Except that we already refused to kill mcrypt, and it is not like I > did not try to convince us to kill it. We decided not to kill it for 7.0. That doesn't mean it got a permanent buy... > > […] > > Sorry, my point was not clear. > > I do like the concept of a pluggable crypto API. Very much. I said it > before and I say it again. I love the concept and will do what I can > to support it :) > > What I do not like too much is the addition of an extension with > (relatively) low level functions for one specific library. It does not > really matter how good is this specific library, I simply do not see > such addition as a good strategic move. I agree with you in principle, but in this particular case I think that there's enough justification considering how measurably bad mcrypt is, and how little some people trust openssl. That leaves no room in core. So in this case I think it *may* be worth it to add it. Anthony --- ## #90266 — Pierre Joye — 2016-01-07T16:33:42+00:00 URL: https://externals.io/message/90249#90266 · In reply to: #90265 > Pierre, > > > […] > > We decided not to kill it for 7.0. That doesn't mean it got a permanent buy... It is pretty much a 7.x permanent buy, yes. And that's why we pushed hard to kill it before. Unless we consider killing extensions in minor releases a non BC break ;-) > > […] > > I agree with you in principle, but in this particular case I think > that there's enough justification considering how measurably bad > mcrypt is, and how little some people trust openssl. That leaves no > room in core. So in this case I think it *may* be worth it to add it. If the pluggable API one won't show up before 7.2/3, yes. If we potentially can sort it out for 7.1/2/3, then no. Cheers, -- Pierre @pierrejoye | http://www.libgd.org --- ## #90270 — Remi Collet — 2016-01-07T16:42:26+00:00 URL: https://externals.io/message/90249#90270 · In reply to: #90249 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Le 07/01/2016 14:26, Scott Arciszewski a écrit : > Hi everyone, > > I've updated the RFC to make libsodium a core PHP extension in 7.1, > to include references to the online documentation. > > https://wiki.php.net/rfc/libsodium Nice extension. IMHO it can be simpler to keep such extension in PECL, especially as libsodium (the library) is quite active, and have recently introduce some API changes (soname bump). I mean, if the extension API have to change, it is easier to do this "outside" of PHP [1]. I only hate the extension name. libsodium is not a library (and libsodium.so on linux is very confusing, for users, and for build system ) I really prefer a non confusing name, like "sodium" (which also match the used namespace). Remi. [1] this didn't means I'm against the idea to have it in core php-src. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlaOlW4ACgkQYUppBSnxahh8rACgj71wFRl1te+jbzhYYhfoMz2f Ky8An1a4zwYOn09o7RgdSH2UIxxtnvVy =ZXOi -----END PGP SIGNATURE --- ## #90276 — Jan Ehrhardt — 2016-01-07T16:58:51+00:00 URL: https://externals.io/message/90249#90276 · In reply to: #90265 Anthony Ferrara in php.internals (Thu, 7 Jan 2016 11:30:14 -0500): >I agree with you in principle, but in this particular case I think >that there's enough justification considering how measurably bad >mcrypt is, and how little some people trust openssl. OTH, OpenSSL has made progress and the quality is improving as far as I can tell as a bystander. -- Jan --- ## #90277 — Scott Arciszewski — 2016-01-07T17:05:50+00:00 URL: https://externals.io/message/90249#90277 · In reply to: #90276 > Anthony Ferrara in php.internals (Thu, 7 Jan 2016 11:30:14 -0500): > > […] > > OTH, OpenSSL has made progress and the quality is improving as far as I > can tell as a bystander. > -- > Jan > > -- > > > Their cipher implementations are OK. Their userspace "CS"PRNG needs to be [any violent metaphor for "deleted" here] in favor of using the kernel's. Then again, LibreSSL is also guilty of this. BoringSSL does it right. Their certificate validation code, last I checked, is the stuff of nightmares. I recall an 800+ line C function. (Have fun auditing that!) Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises What I do not like too much is the addition of an extension with > (relatively) low level functions for one specific library. It does not > really matter how good is this specific library, I simply do not see > such addition as a good strategic move. I also worry that it's yet another thing to maintain. The more API you offer to the PHP programmer, the more responsibility you take on. Tom --- ## #90460 — Scott Arciszewski — 2016-01-10T20:39:17+00:00 URL: https://externals.io/message/90249#90460 · In reply to: #90459 > > > […] > > > I also worry that it's yet another thing to maintain. The more API you offer > to the PHP programmer, the more responsibility you take on. > > Tom Except two things: 1. I'm trying to get rid of mcrypt, bringing the net change of cryptography libraries to maintain to 0, but still improving the cryptography library availability significantly. 2. I'm willing to maintain it, so you're gaining manpower with this change. I'd argue that, strategically, what I've proposed across several RFCs is superior to maintaining the status quo. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > > […] > >Except two things: > >1. I'm trying to get rid of mcrypt, bringing the net change of >cryptography libraries to maintain to 0, but still improving the >cryptography library availability significantly. >2. I'm willing to maintain it, so you're gaining manpower with this >change. > >I'd argue that, strategically, what I've proposed across several RFCs >is superior to maintaining the status quo. A high-level API that plugs into Sodium, Open,Libre,BoringSSL (and maybe etc.) in addition to a low-level libsodium API is more responsibility in total than only high-level API. So "relative to the status quo" isn't the only interesting perspective. Unless I misunderstand your proposal. Are you saying that you are only interested in working on the high-level API if libsodium moves to core? In that case the other perspective isn't relevant. Tom --- ## #90464 — Rowan Collins — 2016-01-10T21:31:34+00:00 URL: https://externals.io/message/90249#90464 · In reply to: #90260 > I'm personally not going to bother pushing > for a pluggable crypto API if the only option is to use OpenSSL and > all its legacy cruft. I think what people are suggesting is not that libsodium shouldn't be supported under-the-hood, just that the fact you're using it shouldn't be exposed to userland. A PDO-like encryption interface (which as I understand it is not what you proposed in your other thread) would allow us to add libsodium in such a way that a relatively painless migration path can be created if it goes the way of mcrypt. So the pluggable API removes the need for any of the sodium_* / Sodium::* / \Sodium\* functions. Regards, -- Rowan Collins [IMSoP] --- ## #90465 — Scott Arciszewski — 2016-01-10T21:41:25+00:00 URL: https://externals.io/message/90249#90465 · In reply to: #90464 > > > […] > > > I think what people are suggesting is not that libsodium shouldn't be > supported under-the-hood, just that the fact you're using it shouldn't be > exposed to userland. A PDO-like encryption interface (which as I understand > it is not what you proposed in your other thread) would allow us to add > libsodium in such a way that a relatively painless migration path can be > created if it goes the way of mcrypt. So the pluggable API removes the need > for any of the sodium_* / Sodium::* / \Sodium\* functions. > > Regards, > > -- > Rowan Collins > [IMSoP] > > > > -- > > > Hi Rowan, > I think what people are suggesting is not that libsodium shouldn't be > supported under-the-hood, just that the fact you're using it shouldn't be > exposed to userland. These are separate concerns. Let's call them Sodium and SimpleSodium. With Sodium, power users gain the ability to write software that directly uses low-level primitives in PHP without requiring their users to install dependencies (i.e. from PECL). Halite 2.0.0 is going to ship with an API for Axolotl, which is the ratcheting protocol used by Signal (formerly TextSecure + RedPhone). Being able to offer Signal integration in SMS-based two factor authentication schemes is a very attractive proposition; even moreso if Sodium is a core extension. SimpleSodium is a driver for the simple cryptography wrapper. You can have SimpleSodium without Sodium, but if we don't get Sodium into core I will, personally, not be putting forth one more ounce of time or effort into helping the PHP core so who knows maybe not? Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises Hi Rowan, > > > […] > These are separate concerns. Let's call them Sodium and SimpleSodium. > > With Sodium, power users gain the ability to write software that > directly uses low-level primitives in PHP without requiring their > users to install dependencies (i.e. from PECL). [ > > SimpleSodium is a driver for the simple cryptography wrapper. As noted on the other thread, I think what people are looking for is actually somewhere between the two - something for power users to use *without tying their code to libsodium*. Code written using mcrypt_* functions is now facing an annoying upgrade path; code written with sodium_* functions now may face the same some years in the future, who knows? PHP should not be maintaining its own low-level implementations of crypto, but it should seem to the user as though it does - they should be asking PHP for a particular cipher / mode / etc, not asking libsodium for one via a thin PHP wrapper. > You can have SimpleSodium without Sodium, but if we don't get Sodium into core > I will, personally, not be putting forth one more ounce of time or > effort into helping the PHP core so who knows maybe not? Obviously, this is entirely your prerogative, but it seems quite a black-and-white stance - maybe leave a bit of leeway for understanding other people's concerns before threatening to abandon work which would be very much appreciated. Regards, -- Rowan Collins [IMSoP] --- ## #90468 — Scott Arciszewski — 2016-01-10T22:22:00+00:00 URL: https://externals.io/message/90249#90468 · In reply to: #90467 > > > […] > > > As noted on the other thread, I think what people are looking for is > actually somewhere between the two - something for power users to use > *without tying their code to libsodium*. Code written using mcrypt_* > functions is now facing an annoying upgrade path; code written with sodium_* > functions now may face the same some years in the future, who knows? > > PHP should not be maintaining its own low-level implementations of crypto, > but it should seem to the user as though it does - they should be asking PHP > for a particular cipher / mode / etc, not asking libsodium for one via a > thin PHP wrapper. > > > > […] > > > Obviously, this is entirely your prerogative, but it seems quite a > black-and-white stance - maybe leave a bit of leeway for understanding other > people's concerns before threatening to abandon work which would be very > much appreciated. > > > Regards, > > -- > Rowan Collins > [IMSoP] > > > -- > > > Hi Rowan, > As noted on the other thread, I think what people are looking for is > actually somewhere between the two - something for power users to use > *without tying their code to libsodium*. Code written using mcrypt_* > functions is now facing an annoying upgrade path; code written with sodium_* > functions now may face the same some years in the future, who knows? And I'm of the opinion that most users need a library that does everything for them, and power users need a toolkit, and we shouldn't try to solve both use cases with the same library. Some people might be allergic to having two separate tools for two separate jobs, but I am not one of them. Power-users will need low-level cipher implementations, most developers will only write insecure code if we let them. If libsodium gets obsoleted (unlikely), it will be because of the availability of practical quantum computers, which also obsoletes openssl and all existing public-key cryptography. Mcrypt is unique in that it was completely abandoned (and poorly designed, to boot) after adoption. I don't think this is a meaningful discussion to have right now, given how widespread it is. https://download.libsodium.org/doc/bindings_for_other_languages/index.html > PHP should not be maintaining its own low-level implementations of crypto, > but it should seem to the user as though it does - they should be asking PHP > for a particular cipher / mode / etc, not asking libsodium for one via a > thin PHP wrapper. There is little in common between openssl and libsodium. Go look at the cipher options in libsodium; it forces you to use conservative, secure ciphers. OpenSSL lets you encrypt in DES-ECB without complaint. > Obviously, this is entirely your prerogative, but it seems quite a > black-and-white stance - maybe leave a bit of leeway for understanding other > people's concerns before threatening to abandon work which would be very > much appreciated. I'm just letting it be known now where I stand with this now rather than later, so if this libsodium initiative doesn't pass and I suddenly drop off internals and delete the relevant Github repositories for the other projects I proposed, there will be no question as to why. I believe in being explicit and forthcoming. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises And I'm of the opinion that most users need a library that does > everything for them, and power users need a toolkit, and we shouldn't > try to solve both use cases with the same library. I don't think anyone is arguing against that, they just see a different pair of tools: a toolkit which is abstracted slightly away from libsodium but still has all its flexibility, and a crypto-for-dummies interface on top of that. > If libsodium gets obsoleted (unlikely), it will be because of the > availability of practical quantum computers, which also obsoletes > openssl and all existing public-key cryptography. Mcrypt is unique in > that it was completely abandoned (and poorly designed, to boot) after > adoption. I don't think this is a meaningful discussion to have right > now, given how widespread it is. OpenSSL was incredibly widespread when Heartbleed was uncovered; it still is, and from your other mails you're still not a fan. Without a crystal ball, we can't know that Sodium is going to last forever, so are looking for a way to integrate its functionality into PHP in such a way that if an alternative comes along later, it is relatively easy to port code from one to the other, rather than tying PHP code directly to Sodium's API. It may even turn out - I honestly don't know - that the only thing we need to change in Sodium's API is the word "Sodium", and we could simply present the functions as "a toolbox of encryption primitives, currently implemented using libsodium". Regards, -- Rowan Collins [IMSoP] --- ## #90470 — David Zuelke — 2016-01-10T23:56:57+00:00 URL: https://externals.io/message/90249#90470 · In reply to: #90249 Can we call that extension "sodium" please without the "lib" prefix? David > > > Hi everyone, > > I've updated the RFC to make libsodium a core PHP extension in 7.1, to > include references to the online documentation. > > https://wiki.php.net/rfc/libsodium > > All new functions and classes would exist in the Sodium namespace. e.g. > > $ciphertext = \Sodium\crypto_box($message, $nonce, $keypair); > > This is part of an overall effort to improve PHP's cryptography; up > next will be the pluggable crypto API that supports multiple backends > (with a scope limited to openssl and libsodium at the time of release) > but always provide conservative defaults. Then I'd like to look at > deprecating ext/mcrypt back to PECL and add more hash functions to > ext/hash. > > Scott Arciszewski > Chief Development Officer > Paragon Initiative Enterprises Can we call that extension "sodium" please without the "lib" prefix? > > David > > > > […] Yes, I don't think that would be controversial. The underlying library is libsodium, but we don't have to refer to our bindings as such. Scott Arciszewski Chief Development Officer Paragon Initiative Enterprises > On Sun, Jan 10, 2016 at 4:59 PM, Rowan Collins wrote: > > […] shouldn't > > […] sodium_* > > […] crypto, > > […] asking PHP > > […] into > > […] other > > […] > > Hi Rowan, > > > […] sodium_* > > […] > > And I'm of the opinion that most users need a library that does > everything for them, and power users need a toolkit, and we shouldn't > try to solve both use cases with the same library. This is a valid and good point. Also agree on the need of the two. Now whether the toolkit should be an extension or userland can be discussed as well. Whether sodium (or other) are in the core or not, the discussions about a more powerful (also proposing a wider range of options for various tasks, even using bad cyphers) sound like a good thing and may as well answer the question about your libsodium binding proposal. > Some people might > be allergic to having two separate tools for two separate jobs, On the other hand they have things in common. But I totally agree on the userland side. PHP needs a password-like APIs for crypto, where users will have a hard time to do it wrong. > but I > am not one of them. Power-users will need low-level cipher > implementations, most developers will only write insecure code if we > let them. > > If libsodium gets obsoleted (unlikely), it will be because of the > availability of practical quantum computers, which also obsoletes > openssl and all existing public-key cryptography. Mcrypt is unique in > that it was completely abandoned (and poorly designed, to boot) after > adoption. I don't think this is a meaningful discussion to have right > now, given how widespread it is. > > https://download.libsodium.org/doc/bindings_for_other_languages/index.html > > I'm just letting it be known now where I stand with this now rather > than later, so if this libsodium initiative doesn't pass and I > suddenly drop off internals and delete the relevant Github > repositories for the other projects I proposed, there will be no > question as to why. This is your choice and you are indeed free to do it. I cannot agree on both the killing of repositories in general and even less of threatens to do so if a given proposal is not accept. It goes against my principles. In any case, given that we can have a constructive discussions about the design and needs, I am sure we will find answers to these questions in the next couple of weeks.