Implementar algoritmos criptográficos de manera segura es difícil. Debería saberlo. Los algoritmos criptográficos concentran los secretos en claves, que son muy valiosos, y muchas filtraciones relacionadas con la implementación (por ejemplo, pequeñas variaciones del tiempo de ejecución) pueden ser desastrosas cuando se aplican a la criptografía.
Hay formas de evitar este tipo de fugas, pero requieren atención, mucho ensayo y error y, sobre todo, un amplio conocimiento del comportamiento de bajo nivel del motor de ejecución. Como regla general, cuanto más lejos esté del hardware, más difícil será asegurar el código contra ataques de canal lateral. PHP está mucho más lejos del código de metal que de C.
Ahora no digo que no es posible ; por ejemplo, una implementación resistente a los ataques de tiempo de un algoritmo criptográfico es bastante posible en Java o .NET. Así que debería ser factible en PHP también. Pero, como es habitual, se requerirá una gran cantidad de escrutinio externo para determinarlo.
Recuerde que new is bad en criptografía; La seguridad se gana a través de la exposición prolongada. A pesar de todas sus deficiencias, OpenSSL ha tenido mucha exposición a lo largo de los años. phpseclib es más nuevo y utiliza un marco "algo hostil" cuando se trata de fugas de canal lateral, por lo que es demasiado pronto para declararlo apto para la producción.
No sé lo que quieres decir con "problema X.509". Quiero decir, X.509 es un engendro del infierno; pero no veo cómo una implementación en PHP funcionaría mejor. El único punto positivo de PHP aquí es que PHP tiene controles en los límites de la matriz, lo que limita las consecuencias de los desbordamientos de búfer (bloqueo de la aplicación en lugar de desbordar el búfer); esto es importante para X.509 solo porque parece que muchas personas no pueden implementar la codificación / decodificación ASN.1 correctamente, sin disparar estos búferes. Pero aparte de eso, la complejidad de X.509 no cambia, ya sea que use C o PHP.
La idea de reescribir todo desde cero, "por simplicidad", surge regularmente cuando se habla de X.509. Pero el "problema" de X.509 no es que las implementaciones habituales sean malas; es que X.509 es inherentemente complejo, porque trata de resolver por adelantado el tema complejo de la delegación de confianza (todas las soluciones en competencia intentan evitarlo); y X.509 (el estándar) ha acumulado una gran cantidad de basura heredada. Reescribirlo desde cero no lo hará más sencillo, a menos que elimine las partes del estándar que no le gustan, en cuyo caso será más simple, pero no funcionará.