Is phpseclib a secure and reliable alternative to OpenSSL?

Question

I know that OpenSSL needs to be installed and activated via apache and the config files, which can be cumbersome or even impossible, and that phpseclib is more flexible and easier to handle than OpenSSL (X.509 problem/ in certain situations the PHP implementation of OpenSSL needs a X.509 certificate in order to create a valid keypair), so i'd like to use phpseclib instead of OpenSSL.

BUT, and this is the question, is it really a viable alternative securitywise? Isn't it problematic to have its source code lying around on the server? Are there some negative secucity implications using phpseclib, or any php implementation of RSA for that matter?

Situation:

• OpenSSL: +native +binary -less flexible -less versatile -sometimes config problems
• phpseclib: +flexible +portable +more versatile -non native -not compiled

Question:

• Security?

EDIT: I use OpenSSL to create a keypair and then encrypt data directly to the DB (client request, no way around it). But the question here is a general one, independent of the final application.

Answer 1

Implementing cryptographic algorithms securely is hard. I should know. Cryptographic algorithms concentrate secrets into keys, which thus are very valuable, and a lot of implementation-related leaks (e.g. small variations of execution time) can become disastrous when applied to cryptography.

There are ways to avoid such leaks, but they require care, a lot of trial-and-error, and, above all else, extensive knowledge of the low-level behaviour of the execution engine. As a rule, the farther you are from the hardware, the harder it gets to secure the code against side-channel attacks. PHP is much further from the metal than C code.

Now I don't say that it is not possible; for instance, a timing-attack resistant implementation of a cryptographic algorithm is quite possible in Java or .NET. So it should be doable in PHP as well. But, as usual, it will require a lot of external scrutiny to ascertain.

Remember that new is bad in cryptography; security is gained through prolonged exposure. For all its shortcomings, OpenSSL has had a lot of exposure over the years. phpseclib is newer, and uses a "somewhat hostile" framework when it comes to side-channel leaks, so it is much too early to declare it fit for production.

---

I don't know what you mean by "X.509 problem". I mean, X.509 is a spawn of Hell; but I don't see how an implementation in PHP would fare better. The one good point of PHP here is that PHP has checks on array bounds, thus limiting the consequences of buffer overflows (application crash instead of actually overflowing the buffer); this matters for X.509 only because it seems that many people are incapable of implementing ASN.1 encoding/decoding properly, without tripping on these buffers. But apart from that, the complexity of X.509 is unchanged, whether it uses C or PHP.

The idea of rewriting everything from scratch, "for simplicity", arises regularly when talking about X.509. But the "problem" of X.509 is not that usual implementations are bad; it is that X.509 is inherently complex, because it tries to deal upfront with the complex issue of trust delegation (all competing solutions just try to side-step it); and X.509 (the standard) has accumulated a lot of legacy crud. Rewriting it from scratch won't make it simpler, unless you remove the parts of the standard which you don't like, in which case it will be simpler, but it won't work.

Answer 2

No.

phpseclib is not nearly as well-vetted as OpenSSL, the latter of which is easily on the top-10 list of most carefully-scrutinized code in use.

While future bugs are difficult to predict, the more attention a bit of software gets, the more quickly the bugs (and security problems in particular) get weeded out. OpenSSL is very mature. On the other hand, phpseclib is most definitely not.

That's not to say that phpseclib is clearly insecure; it may be a very reasonable bit of code. But it's not on the same level as OpenSSL because it hasn't seen the level of scrutiny from the caliber of auditors that OpenSSL has.

Also, if you're intending to use phpseclib instead of Apache/SSL for doing HTTPS, then you're definitely doing it wrong. And whatever the "X.509 Problem" is that you're talking about, this is not a reasonable solution.