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?


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


  • 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.

  • What are you using OpenSSL for? – Adi Oct 28 '13 at 19:33
  • I use OpenSSL to encrypt data asynchronously to the DB (client request, no way around it, i know it is not optimal to encrypt the data directly with the public/private keypair) – Larzan Oct 29 '13 at 8:24
  • 1
    Why the -1, is there a rule i wasn't aware of that i broke with this post? – Larzan Oct 29 '13 at 8:40
  • 1
    I'd recommend reading Choosing the Right Cryptography Library for your PHP Project: A Guide as there's some very good analysis there. – colan Jul 26 '17 at 15:30

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.

| improve this answer | |
  • I assumed that it was common knowledge that OpenSSL makes it sometimes a bit cumbersome (at least the PHP implementation) to create a private key and store it to a file, as it requires in certain cases an X.509 certificate to do so. That makes is less straight forward as phpseclib. But what you pointed out is exactly what i was worried about (further from the hardware, newer). Thanks – Larzan Oct 29 '13 at 8:18
  • I think phpseclib is a great solution but Thomas and tyleri are right - it's going to be hard to dethrone OpenSSL, which has a ton more scrutiny due to it's much greater level of popularity. Also, FWIW, phpseclib does use OpenSSL, if it's available, for RSA and biginteger operations. That would seem to suggest that even the phpseclib author thinks OpenSSL is better in a lot of cases. – neubert Oct 29 '13 at 15:03


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.

| improve this answer | |
  • For that matter, OpenSSL has FIPS certification, which, as I understand it, can cost upwards of $100,000 USD. For some reason I don't imagine the phpseclib community is big enough to pony up that kind of cash. – neubert Oct 29 '13 at 15:18

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.