是否可以在 Javascript 中进行端到端加密？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/28526464/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Is End-to-end encryption possible in Javascript?
提问by Dominique
I'm currently researching the possibilities for creating a (peer2peer) messaging client in terms of encryption thus security. This application will be based on web technologies (if possible).
我目前正在研究在加密和安全方面创建（peer2peer）消息客户端的可能性。此应用程序将基于网络技术（如果可能）。
My questions are: is end-to-end encryption possible with only javascript (client & node.js/peer.js)? If yes: is it correct to look into the HMAC (RSA) kind of encryption techniques? I already tried to understand a bit how these libraries work but I have no luck so far :)
我的问题是：是否可以仅使用 javascript（客户端和 node.js/peer.js）进行端到端加密？如果是：研究 HMAC (RSA) 类型的加密技术是否正确？我已经尝试了解这些库是如何工作的，但到目前为止我还没有运气:)
lib's I find interesting but i don't (completely) understand and know how to implement (in this use-case):
lib 我觉得很有趣，但我不（完全）理解也不知道如何实现（在这个用例中）：
- http://bitwiseshiftleft.github.io/sjcl/
- https://github.com/Caligatio/jsSHA
- https://code.google.com/p/crypto-js/
- http://bitwiseshiftleft.github.io/sjcl/
- https://github.com/Caligatio/jsSHA
- https://code.google.com/p/crypto-js/
I can try to elaborate more if needed.
如果需要，我可以尝试详细说明。
UPDATE: The application is going to be a mobile application. The use of web technologies is a bit proof-of-concept.
更新：该应用程序将成为一个移动应用程序。网络技术的使用有点概念验证。
回答by Maarten Bodewes
You are currently looking at security implementations. If you don't understand the security model & cryptography behind these libraries, your solution will - to a high certainty - not be secure.
您目前正在研究安全实施。如果您不了解这些库背后的安全模型和密码学，您的解决方案将 - 非常肯定 - 不安全。
Artjom is correct in indicating that for peer to peer encryption you most likely need authentication of both parties. That is not provided by normal SSL/TLS, you'll need client authentication. But for client and server authentication you need to have established trust. On normal browsers this is provided by the internal certificate store. It is however much trickier to trust the clients.
Artjom 正确地指出，对于点对点加密，您很可能需要双方的身份验证。这不是由普通 SSL/TLS 提供的，您需要客户端身份验证。但是对于客户端和服务器身份验证，您需要建立信任。在普通浏览器上，这是由内部证书存储提供的。然而，信任客户要困难得多。
All the other stuff (like how RSA is not a HMAC) are implementation details. You should however not be implementing anything related to securityright now. First focus on your use case, threat scenario and protocol design.
所有其他的东西（比如 RSA 如何不是 HMAC）都是实现细节。但是，您现在不应该实施与安全相关的任何事情。首先关注您的用例、威胁场景和协议设计。
回答by Snowman
At most, you can have "novelty" end-to-end encryption using Javascript in a web browser. That is, it'll look and feel like end-to-end encryption, but the implementation will most likely be scoffed at by cryptographers.
最多，您可以在 Web 浏览器中使用 Javascript 进行“新颖”的端到端加密。也就是说，它看起来和感觉上都像端到端加密，但该实现很可能会被密码学家嘲笑。
The main reason is that no matter what piece of puzzle you put in to encrypt data on the frontend, your client ultimately depends on what the server sends it.
主要原因是，无论您在前端加密数据时放入什么谜题，您的客户端最终都取决于服务器发送的内容。
Required reading:
必读：
回答by TheGreatContini
The goal of end-to-end encryption is that users can be certain of the security of the communication even if the central server is cheating. There are two main challenges that need to be solved:
端到端加密的目标是即使中央服务器作弊，用户也可以确定通信的安全性。有两个主要挑战需要解决：
(1) Users need to be 100% certain that they are communicating with whom they think they are communicating. This is to prevent man-in-the-middle (MITM) attacks, where the man-in-the-middle could be anybody including the server itself (example: Apple iMessage has this weakness).
(1) 用户需要 100% 确定他们正在与他们认为他们正在交流的人进行交流。这是为了防止中间人 (MITM) 攻击，中间人可以是任何人，包括服务器本身（例如：Apple iMessage 有这个弱点）。
(2) You need to be 100% sure the client-side code is not cheating. For example, is it really encrypting the data using the other person's public key, or is it just sending it in the plaintext somewhere else, and then encrypting from there. Given that whoever has access to the server can swap the JavaScript any time, this is a huge challenge.
(2) 您需要 100% 确定客户端代码没有作弊。例如，它是真的使用其他人的公钥加密数据，还是只是将其以明文形式发送到其他地方，然后从那里加密。鉴于可以访问服务器的任何人都可以随时交换 JavaScript，这是一个巨大的挑战。
Both problems seem solvable.
这两个问题似乎都可以解决。
For (1), users can verify public keys out-of-band, as is done in PGP/GPG(unfortunately many people skip this step, but for true end-to-end security, you need it) or keybase.io.
对于 (1)，用户可以在带外验证公钥，就像在PGP/GPG 中所做的那样（不幸的是，很多人跳过了这一步，但为了真正的端到端安全，你需要它）或keybase.io。
For (2), a group from MIT claims to have solved this in their Mylardesign. See section 6. It should be stated that researchers have found security issues with Mylar, but to my knowledge, their solution to client-side code integrity has not been compromised.
对于 (2)，麻省理工学院的一个小组声称已经在他们的Mylar设计中解决了这个问题。参见第 6 节。应该说明的是，研究人员已经发现了 Mylar 的安全问题，但据我所知，他们的客户端代码完整性解决方案并未受到损害。
So in theory, end-to-end encryption can be done entirely in JavaScript (what server language is used is not so relevant). In practice ... it will not be easy.
所以理论上，端到端加密完全可以在 JavaScript 中完成（使用什么服务器语言并不那么重要）。在实践中......这并不容易。
