javascript - 进出代码点火器的加密和解密

Question

我正在创建一个基于codeigniter的应用程序，并且将以API Centric应用程序的身份工作，我想实现安全性，以便从自己的门户访问API的用户应从我的门户获取公钥和私钥，然后他们发送的每个请求到我的服务器以获取数据应使用公钥加密，服务器应使用私钥解密数据以获取存储在数据库中的私钥

现在的问题是，我该如何实现它，以使用户不应该费劲地使用公钥来加密数据，并且我也应该能够在代码点火器中使用私钥来解密信息。并且即使加密是由javascript进行的，仍应通过codeigniter对其进行解密。我需要一些安全的方法来做到这一点，这样我就可以避免中级攻击和其他威胁

谢谢

Answer 1

简单的答案是使用TLS。

如果您已经将服务器接口实现为Web API，那么这就像配置Web服务器前端以接受HTTPS上的连接一样简单。然后，您的Web服务器（以及客户端上的浏览器/ HTTPS客户端库）将为您处理大多数复杂的握手，身份验证和加密详细信息。

TLS远非完美的安全协议，但是，如果使用得当，它通常可以完成工作，而且与设计自己的协议相比，它的麻烦或出错机会要少得多。



如果您真的想“推出自己的”安全通信方案，则首先必须熟悉密码学理论和各种可用算法。特别是，要实施有效的hybrid cryptosystem，您将需要：


经过认证的基于公钥的key agreement protocol（最好是基于Diffie–Hellman key exchange的某种东西，因此提供forward secrecy）为客户端和服务器提供临时共享密钥；
authenticated symmetric encryption算法，使用共享密钥在客户端和服务器之间提供安全通道；和
如果在安全信道内将数据作为离散消息发送，则能够检测message replay attacks的通信协议（例如，通过使用顺序消息号）。


虽然所有这些都可以仅使用几个离散的加密原语来实现-分组密码（例如AES），公钥加密/签名算法（例如RSA）以及可能的哈希函数（例如SHA-256）和某种方式为Diffie-Hellman进行模幂运算—使用您的密码库已经实现了高级接口的协议和方案通常更容易。

不幸的是，实施最广泛的方案也往往是较旧的方案，与较现代的方案相比，它可能更慢并且安全性较弱。就是说，如果我有选择的话（请记住，我绝不是真正的加密专家），那么我会选择以下方法：


如果客户端需要使用密码进行身份验证，我会选择SRP作为密钥协议协议。如果双方都有对方已知的公共signature密钥，则问题会稍微简单一些，可以通过使用原始Diffie-Hellman然后让双方签署DH共享密钥或使用类似< aa>。 （请注意，即使使用SRP，您可能仍希望服务器使用比仅了解客户端密码验证程序更强的功能向客户端进行身份验证。）

对于签名算法，只要密钥长度足够，STS（带有RSA），proper padding或DSA中的任何一个都可以。 （什么才算足够取决于算法。）在需要散列算法的地方，我暂时使用ECDSA;一旦确定了SHA-2标准，它也是一个有效的选择。
对于对称加密部分，我会选择SIV（SHA-3）以获得最大的安全性，或者如果速度至关重要或需要对大消息进行“在线”加密，则可以使用RFC 5297（并且您不需要必须自己实施）。如果GCM足以满足您的目的，并且OCB也非常好，即使不是绝对最快，也可以选择patent exemptions。另请参见EAX。

分组密码（例如How to choose an Authenticated Encryption mode中）和CTR mode的通用组成也可以使用，只要您确保在加密后将MAC应用到消息上即可（在解密之前结束验证）。任何体面的MAC都应该这样做，但是MAC通常是安全可靠的选择，如果您具有可用的良好散列函数并且不需要极高的速度。 （如果这样做，可能值得考虑使用像HMAC这样的快速Carter–Wegman MAC。）如果可以的话，请尽量避免使用旧的CBC-MAC；请尽量避免使用旧的CBC-MAC。 poly1305-AES更好。
无论如何，我认为目前没有很好的理由为基础块密码选择除CMAC以外的任何内容，尽管设计协议始终是一件好事，以便可以轻松引入新的密码选项（并且不赞成使用不安全的旧密码选项）在将来。
要从DH / SRP共享密钥中获得对称加密密钥，您需要AES generally； HKDF（key derivation function）是此工作的不错选择，特别是如果您已经使用哈希函数的话。 （不过，不应将它用于RFC 5869-用于散列密码；为此，您需要像alone, at least或PBKDF2这样的键拉伸KDF。）
同样，如前所述，我将设计我的通信协议，以便所有消息都带有顺序的消息号和显式的发送者/接收者指定，并且将具有重复消息号或无效指定的消息作为伪造丢弃。方便地，这些消息号+指示符也可以用作对称加密协议的scrypt（可能在哈希之后，如果它们太长的话）。

这些消息号和指示符不必加密（尽管它们确实需要作为“关联数据”进行身份验证）；不加密它们的优点是，即使在尝试解密之前，您也可以立即拒绝任何带有假数字或标识符的消息。
最后，请始终记住，我上面的建议或您选择应用建议的方式可能存在可利用的空白。在将协议和实现用于任何实际重要的事情之前，请确保让尽可能多的合格安全专家来审核您的协议和实现。


至于您提到的各种语言的特定加密库或API，我并不是特别熟悉它们，因此无法提供详细的建议。只需看一下标准加密库的文档，看看它们提供了什么。