It’s Open Source Week at SitePoint! All week we’re publishing articles focused on everything Open Source, Free Software and Community, so keep checking the OSW tag for the latest updates.

Scott Arciszewski, known on Twitter as CiPHPerCoder, is to security what Chris Hartjes is to unit testing.

He’ll pounce on insecure applications, libraries, and packages, find loopholes, problems, and wrong implementations, and help people fix them. He’s the main developer of several popular security-oriented packages, including but not limited to Halite for using libsodium in a more user friendly way, gpg-mailer for sending encrypted emails, random_compat, and more.

As a big fan of the PHP extension libsodium, he’s currently trying to gauge interest from the wider community in contributing funds to a professional audit of a PHP version. In a nutshell, Scott wants to donate his time to write the PHP version polyfill (which would use libsodium as an extension, if installed), but wants to pay for a professional audit of his work in order to make sure it really is maximally secure. Here’s the thing though – professional code reviews are insanely expensive.

Scott was kind enough to find time to answer some questions about this, and we feel like a push for exposure on an impressive project like this is a perfect way to wrap up Open Source Week.

Hi Scott, thanks for taking the time to answer some questions! Can you give us a civilian-friendly tl;dr on libsodium? What the extension actually does and the contexts in which it’s most commonly used?

Libsodium is a modern and easy-to-use cryptography library currently available on PECL (although I hope to land it into PHP 7.2). It offers the best-in-class cryptographic features (symmetric encryption, public-key encryption, digital signatures, password hashing, etc.) and takes great pains to not be vulnerable to what we call side-channel cryptanalysis.

As an example: AES, when implemented in software, is vulnerable to a cache-timing attack. You can learn bits of your secret keys from an unprivileged process (or over the network) based on how much time it takes for a particular operation to complete.

Some of the more exciting features that libsodium offers include X25519 (Elliptic Curve Diffie-Hellman key agreement over Curve25519), Ed25519 (EdDSA– Edwards-based Digital Signature Algorithm– over Curve25519), Argon2i password hashing, and incredibly easy-to-use encryption APIs. For example, this snippet encrypts/decrypts a message and saves you from having to worry about chosen-ciphertext attacks:

$ciphertext = \Sodium\crypto_secretbox($message, $nonce, $key); $plaintext = \Sodium\crypto_secretbox_open($ciphertext, $nonce, $key); /* var_dump($message === $plainext); // bool(true) */

You can use all of these great cryptography features today, if you can install the PHP extension from PECL.

However, many PHP developers don’t have the capability of installing (or requiring) optional PHP extensions. There are both technical and political obstacles at play.

Despite these challenges, libsodium is highly desirable for many reasons. Its digital signature algorithm (Ed25519) is the gold standard for public key authentication. Unlike RSA (which allows message forgery if you use PKCS1v1.5 padding and set e=3, via Bleichenbacher’s ’06 attack) and ECDSA (which caused the Sony PS3 security meltdown when they repeated a nonce), Ed25519 is easily implemented in constant-time. You don’t have to worry about invalid curve attacks or twist security (or many other cryptography vulnerabilities with eccentric names) because of Curve25519. But most importantly, Ed25519 is deterministic: you’ll never repeat a nonce and leak your secret key like with classic ECDSA.

A lot of PHP software would benefit from the cryptography offered by libsodium if only they could make it a dependency today. WordPress, for example, does not use any sort of cryptographic signatures on its automatic update packages. If we could get modern cryptography deployed even on legacy systems, we could save 27% of the Internet from being hacked if api.wordpress.org got compromised. If WordPress can start out with Ed25519 instead of shoehorning in RSA and introducing backward compatibility problems down the line, that would save everyone a lot of headaches.

To that end, I’ve decided to write a pure PHP polyfill for libsodium, starting with Ed25519 first and probably Argon2i last. The polyfill is opportunistic; if the PECL extension is installed, it will use that instead of my implementation.

So far, how’s the effort going? Any indication of interest from corporations?

Development is underway. There’s enough community interest to warrant making the polyfill, but I won’t feel comfortable releasing it to the world until it’s been audited by a third party.

Truth be told, I haven’t done much in the way of reaching out to corporations, given that it’s a holiday weekend in the States. However, after I posted about this on Twitter, the Joomla team immediately began a serious discussion about how much they could pledge from their budget towards getting the polyfill audited.

The biggest beneficiary would be Automattic, along with anyone who depends on WordPress to pay their bills.

Have you already started writing the library and, if so, what have been the biggest challenges so far?

I’ve spent much of this morning porting the ref10 curve25519 code to PHP. The biggest challenges I foresee are going to be:

PHP’s signed integers, especially on 32-bit platforms without the GMP extension. When I get to Argon2i, memory limits may prove challenging.

The security challenges ( mbstring.func_overload , the fact that chr() isn’t cache-timing-safe, etc.) are the sort of problem I tackle in my day-to-day at PIE, so I’m not sweating those. I’m writing the code to be side-channel-free from day one.

The library would be fully open source, and strive for 100% parity with the libsodium extension, correct?

I might forego a few non-mainline features (e.g. crypto_pwhash_scryptsalsa208sha256 because we have Argon2i now) unless they’re explicitly needed. It will, however, be completely open source under a permissive license (either ISC like libsodium itself or something like MIT, CC0, WTFPL, or the Unlicense; I don’t have a preference and there are too many to choose from).

Apropos challenges – will you be developing the library publicly? I.e., will it be an open repo to which others can also contribute if they find the time?

Once at least all of the features of NaCl (what libsodium is based on) are implemented and well tested, the repository will be made public. From that point forward, we’ll be focusing on getting what’s implemented reviewed by other PHP security and cryptography experts and testing on weird platforms that PHP happens to support.

If (or is it “when” now?) you write the library, and we get it fully audited, whom would this benefit the most? How far reaching would the implications of something like this be?

Without a shadow of a doubt, WordPress users will benefit the most, since we’ll be able to discuss implementing secure automatic updates without bumping the minimum PHP version requirement to 7.2.

The far-reaching implications are that no PHP cryptography project would be left behind. All of them could take advantage of it, even if they support ancient versions of PHP and serve customers that can’t install PHP extensions. There won’t be any common, rational excuses left for clinging to fossils like mcrypt. The entire ecosystem beyond WordPress can move forward towards where projects like Halite and CMS Airship are today.

Like random_compat before it, I’m writing the libsodium polyfill to be compatible with PHP as far back as 5.2.4. Unlike random_compat , however, I intend to eventually fork it into two branches:

v1.x.y – PHP 5.2.x – 7.x.y compatible

v2.x.y – PHP 7.x.y only; uses scalar type declarations with strict typing

Presumably, neither branch will need to do much for PHP 7.2 and beyond.

So about the audit – tell us, how does that usually work, and which price ranges are we talking here?

A cryptography code audit is a service provided by a software security company that specializes in applied cryptography. My employer (Paragon Initiative Enterprises) is one such company that offers these services, but it wouldn’t be good hygiene to audit our own work and tell everyone to trust that we did a thorough job.

Cryptography code audits are costly. Typically, they require tens of person-days from a reputable third party, which typically bills their consultants out at a rate of $1k to $5k per person-day. But if you’re a company, this is a great investment to make, as most firms don’t have access to the security talent that a software security company does. Two other companies besides my employer that offer these services are NCC Group and Cure53. I don’t know their bill rates, but I’m certain “cheap” isn’t anywhere on the menu; they do good work.

Is this third-party audit really something that’s needed? Aren’t you in touch with all the best PHP devs out there already? Wouldn’t a well organized peer review by respected fellow devs have almost the same effect?

The unfortunate truth is that the best PHP devs rarely have more than a few hours to spare to look over anything for free. A code audit is a paid engagement with a team of security experts to carefully review your implementation for mistakes that have security consequences. The level of focus and attention is much greater. For example, the code audits I’ve done for clients are much, much more thorough than the security-related Github issues I’ve opened. Although they are conceptually similar, it’s a night-and-day difference.

You can expect the same from a small team of independent reviewers from a software security consultancy.

If this polyfill library ends up securing a quarter of websites on the Internet, then an audit is non-negotiable.

Have you considered Indiegogo or Kickstarter to fundraise for the audit?

Considered, but not committed. On the off chance that a large company comes along and says, “Hey, we need this yesterday, we’ll cover the entire cost of the third-party audit,” I’m not in a hurry to ask individuals to reach into their own wallets until I’m sure that isn’t going to happen. I almost certainly cannot pay for an audit out of my own pocket, so asking others to dip into theirs as Plan A doesn’t sit right with me.

However, if none of the big PHP companies (especially the ones that use WordPress) are willing to pitch in, crowdfunding is definitely my next step. Should this happen, none of the proceeds will be going to pay for development, so there’s not much I can offer in terms of stretch goals. Maybe I could invest anything beyond the goal into getting Defuse Security’s PHP encryption library audited too? (I’m open to suggestions, of course.)

Is there anything we or our readers can do to help this effort, other than contributing directly?

Tell your coworkers and your boss about this effort to help make it happen.

Once the library’s been audited, use it in your projects. Please let’s just bury RSA and foot-bullety ECDSA in the past where it belongs. Modern elliptic curve cryptography is the future (until quantum computers are a thing, anyway).

Anything else you’d like to share?

At least 27% of the websites on the Internet stand to gain a lot more resilience. My workplace firmly believes security starts with developers, and if successful, this will be Exhibit A when we must defend our philosophy against security vendors selling their useless $100,000 blinking boxes at information security conferences.

I may end up asking companies and (if that fails) individuals to pay a team of outside security experts to point out any mistakes I’ve made along the way.

To anyone who personally dislikes me (possibly due to my blunt security vulnerability reporting over the years), you may soon have the opportunity to literally contribute money toward hiring an expert to publicly tell me I’ve screwed something up, while making the Internet more secure in the process. Where are you going to find a sweeter deal than that?

Conclusion

The libsodium extension finally helped most of the advanced PHP world move away from mcrypt and other outdated security approaches. However, using it was far from easy for all the people on shared hosts, or those locked into outdated CMS and CRM platforms.

The PHP version of it would change that – it would help projects like WordPress, Joomla, Magento, and others implement a PHP version of libsodium and replace their outdated security methods, all without forcing shared hosts to install any custom extensions.

Naturally, PHP versions on such hosts would still be problematic in many cases, as many of these CMSes and CRMs support long dead PHP versions, but in time, an enormous part of the web ecosystem could become dramatically more secure.

If you work in a company which uses popular PHP-based CRM or CMS software, please bring this to their attention – have them read Scott’s answers and teach them about the benefits of adding libsodium to their applications and the backbone of their systems. A small financial sacrifice today can prevent incredibly expensive bugs later on.