我知道 OpenSSL 需要通过 apache 和配置文件安装和激活，这可能很麻烦甚至不可能，而且phpseclib比 OpenSSL 更灵活、更容易处理（X.509 问题/在某些情况下 PHP 实现OpenSSL 需要 X.509 证书才能创建有效的密钥对），所以我想使用 phpseclib 而不是 OpenSSL。
但是，这就是问题所在，这真的是一种可行的安全替代方案吗？将其源代码放在服务器上不是问题吗？使用 phpseclib 或 RSA 的任何 php 实现是否有一些负面的安全影响？
情况：
问题：
编辑：我使用 OpenSSL 创建一个密钥对，然后将数据直接加密到数据库（客户端请求，无法解决）。但这里的问题是一般性的，与最终应用无关。
安全地实施加密算法很困难。我应该知道。密码算法将秘密集中在密钥中，因此非常有价值，并且在应用于密码学时，许多与实现相关的泄漏（例如执行时间的微小变化）可能会成为灾难性的。
有一些方法可以避免此类泄漏，但它们需要小心、大量的反复试验，最重要的是，需要对执行引擎的低级行为有广泛的了解。通常，您离硬件越远，就越难以保护代码免受侧信道攻击。PHP 比 C 代码更远离金属。
现在我不是说不可能；例如，在 Java 或 .NET 中，密码算法的抗时序攻击实现是完全可能的。所以它在 PHP 中也应该是可行的。但是，像往常一样，这需要大量的外部审查才能确定。
请记住，新的密码学不好；安全是通过长时间暴露获得的。尽管存在所有缺点，但 OpenSSL 多年来一直受到广泛关注。phpseclib是较新的，并且在涉及侧通道泄漏时使用“有点敌对”的框架，因此现在宣布它适合生产还为时过早。
我不知道您所说的“X.509 问题”是什么意思。我的意思是，X.509 是地狱的产物；但我看不出 PHP 中的实现会如何更好。这里 PHP 的一个优点是 PHP 对数组边界进行了检查，从而限制了缓冲区溢出的后果（应用程序崩溃而不是实际溢出缓冲区）；这对 X.509 很重要，因为似乎很多人无法正确实现 ASN.1 编码/解码，而不会在这些缓冲区上绊倒。但除此之外，X.509 的复杂性并没有改变，无论是使用 C 还是 PHP。
在谈论 X.509 时，经常会出现“为了简单”从头开始重写所有内容的想法。但是 X.509 的“问题”并不在于通常的实现很糟糕。X.509本质上是复杂的，因为它试图预先处理复杂的信任委托问题（所有竞争的解决方案都试图回避它）；而 X.509（标准）已经积累了很多遗留的 crud。从头开始重写不会让它变得更简单，除非你删除了你不喜欢的标准部分，在这种情况下它会更简单，但它不会起作用。
不。
phpseclib 不像 OpenSSL 那样经过严格审查，后者很容易在使用中最仔细审查的代码的前 10 名列表中。
虽然未来的 bug 很难预测，但软件得到的关注越多，bug（尤其是安全问题）被清除的速度就越快。OpenSSL 非常成熟。另一方面，phpseclib 绝对不是。
这并不是说 phpseclib 显然不安全。这可能是一段非常合理的代码。但它与 OpenSSL 不在同一级别，因为它没有看到 OpenSSL 拥有的审计员的审查水平。
此外，如果您打算使用 phpseclib 而不是 Apache/SSL 来执行 HTTPS，那么您肯定做错了。无论您所说的“X.509 问题”是什么，这都不是一个合理的解决方案。