L'implementazione sicura degli algoritmi crittografici è difficile. Dovrei saperlo. Gli algoritmi crittografici concentrano i segreti nelle chiavi, che quindi sono molto preziosi e molte perdite legate all'implementazione (ad esempio piccole variazioni del tempo di esecuzione) possono diventare disastrose se applicate alla crittografia.
Ci sono modi per evitare tali perdite, ma richiedono attenzione, un sacco di tentativi ed errori e, soprattutto, una conoscenza approfondita del comportamento a basso livello del motore di esecuzione. Di norma, più ti allontani dall'hardware, più è difficile ottenere il codice dagli attacchi del canale laterale. PHP è molto più lontano dal metallo rispetto al codice C.
Ora non dico che non è possibile ; per esempio, un'implementazione resistente alla temporizzazione di un algoritmo crittografico è abbastanza possibile in Java o .NET. Quindi dovrebbe essere fattibile anche in PHP. Ma, come al solito, richiederà parecchio controllo esterno per accertare.
Ricorda che new is bad in crittografia; sicurezza è acquisita attraverso l'esposizione prolungata. Nonostante tutte le sue carenze, OpenSSL ha avuto molta esposizione nel corso degli anni. phpseclib è più recente e utilizza un framework "un po 'ostile" quando si tratta di perdite di canale laterale, quindi è troppo presto per dichiararlo adatto alla produzione.
Non so cosa intendi per "problema X.509". Voglio dire, X.509 è una progenie dell'inferno; ma non vedo come una implementazione in PHP farebbe meglio. L'unico punto buono di PHP è che PHP ha controlli sui limiti degli array, limitando così le conseguenze degli overflow del buffer (crash dell'applicazione invece di sovraccaricare il buffer); questo è importante per X.509 solo perché sembra che molte persone non siano in grado di implementare correttamente la codifica / decodifica ASN.1, senza inciampare su questi buffer. Ma a parte questo, la complessità di X.509 è invariata, sia che usi C o PHP.
L'idea di riscrivere tutto da zero, "per semplicità", si presenta regolarmente quando si parla di X.509. Ma il "problema" di X.509 non è che le normali implementazioni siano cattive; è che X.509 è un complesso intrinsecamente , perché cerca di affrontare in anticipo la complessa questione della delega di fiducia (tutte le soluzioni in competizione cercano semplicemente di farla da parte); e X.509 (lo standard) ha accumulato un sacco di legacy crud. Riscrivendolo da zero non lo renderà più semplice, a meno che non rimuovi le parti dello standard che non ti piacciono, nel qual caso sarà più semplice, ma non funzionerà.