实现一个纯 Web 界面的端到端加密临时聊天对话思路是否可行？

[busier]

假如想实现一个纯 Web 界面的端到端加密临时聊天对话

通过 openpgpjs 项目，在客户端浏览器纯前端实现 PGP 加解密

服务器端只负责交换公钥和转发客户端传过来的加密消息，保证服务器管理员无法解密阅读消息内容

免用户注册机制，服务器通过 PGP 公钥来标识用户，列出在线用户及 PGP 公钥

用户"密钥对"在用户浏览器加载页面时随机生成，不上传不保存私钥，关闭浏览器私钥丢失，所有消息将被废弃不可解密。

这样的设计思路有无技术可行性，或者有什么重大缺陷？

已知问题：无法确认对方身份，需要通过其它渠道交换公钥来确认身份。

其它问答题希望听听大家意见

[shadowyue]

可行，但是功能单一估计用户太少怕维持运营成本都难。看你怎么在其他方面上发挥，比如约炮啥的🤣

[lingo]

http://element.io

自己 docker 开个服务器就好

[ZhiyuanLin]

传输可以走 WebRTC ，双客户端之间通过 WebSocket signalling 建立 WebRTC 直连，大文件传输不用经过服务器。
之前搞得科研项目用用到这俩技术。

[ZhiyuanLin]

缺点是双方都是 symmetric NAT 的话是没法建立连接的，除非你提供 TURN server

[ZhiyuanLin]

WebRTC 在 Signalling 期间本身就确立了端对端加密，所以你其实不用搞 openpgpjs 之类麻烦东西。

[ZhiyuanLin]

Ref: https://webrtc-security.github.io
https://www.tutorialspoint.com/webrtc/webrtc_text_demo.htm
https://github.com/feross/simple-peer
https://github.com/webRTC-io/webrtc.io-demo

[ZhiyuanLin]

关于公钥的交换，可以直接提取 WebRTC 的公钥在其他渠道交换。

[kkocdko]

可行而且早就有人实现过了，善用 google

[luxor]

element.io

[meeop]

可行,但没用,以及已经有很多人实现过了,以及 99%场景用电报之类就行,再不行分享网盘邮箱之类

[busier]

@nevadax "如何防止中间人攻击？（比如劫持，代理）"
我说过了：“无法确认对方身份，需要通过其它渠道交换公钥来确认身份。”
公钥一旦确认，中间人问题就解决了！

@x2420390517 “都通过其它渠道交换公钥了，我干嘛不直接通过那个渠道顺便把加密消息一起发了得了？”
已有渠道并不提供方便的端 PGP 加解密操作。你要来回复制粘贴密文来操作么！！！

@jeesk “使用场景? 如果仅仅是分享问价? 那么直接临时启动一个 http-server 即可”
与 http-server 单分享是不同的。端到端的加密，要求服务器端也获取不到明文内容。

[keithwhisper]

可以看下 ECash Chat

[0o0O0o0O0o]

推荐这篇讨论 https://news.ycombinator.com/item?id=39436238 浏览器有往这方面发展的趋势，但并不够

E2EE 可以让用户只信任客户端，我个人对 E2EE 应用的要求是：开源的客户端、客户端会执行的代码在编译后就是确定的、客户端经过审计。而对于你的 "纯 Web 界面的端到端加密"，用户还必须信任浏览器每次加载的页面，你作为网站管理员被胁迫了或者你服务器被黑了怎么办？你用的 CDN 被黑了怎么办？还是说你打算单独分发前端源码文件？

[raw0xff]

@Nazz 全走 wasm 的目的是？

客户端浏览器临时生成密钥对除了 webcrypto api 和在 wasm 中生成，还有哪些方式？（不算浏览器扩展的话）
window.crypto.subtle.generateKey 时 extractable:ture 的话可以导出私钥，我觉得还是有一定风险的。
所以你说的全走 wasm 意思是在 wasm 沙盒中生成公私钥对吗？ wasm 存私钥的变量是否会被 js 读出来？

楼主可以看看去年的 nostr 项目，应该也属于 e2ee.

[raw0xff]

@0o0O0o0O0o 哈哈总会碰到 oo 大佬，你这个链接也给过我。

[chinni]

邮件 gpg 呗

[Nazz]

@raw0xff 保护密钥和源代码

[busier]

@0o0O0o0O0o 在终端加密的目的就是解决服务器不可靠时，管理员也获取不到明文信息，包括 CDN 也是。
你所提到的页面被黑被撰改问题，这在所有 Web 网站都存在此风险。并不是我这个设计特有的，算不得此设计缺陷。
话所说回来，加解密部分的代码是静态不改变且开源的，用户只要校对这部分代码(或设计个校对功能)便不是问题。

[raw0xff]

@busier 你可能没有意识到在不能保证用户访问的第一个页面的完整性的前提下 e2ee 并不安全。

[0o0O0o0O0o]

@busier #38

我在 #33 并没有将你的应用跟“所有 Web 网站”对比，我是将你的应用与常见的 E2EE 应用做对比。它们解决了，而你的方案或者说浏览器没解决，在这个重要问题没有解决的时候说 "解决服务器不可靠"、"管理员也获取不到明文信息，包括 CDN 也是" 就是不对的。

> 加解密部分的代码是静态不改变且开源的
> 用户只要校对这部分代码(或设计个校对功能)便不是问题

首先，我认为不可能只审计一部分代码，而是你的网站前端的所有代码都要审计，而目前 Web 的运作方式让这个事情失去它应有的意义，因为作为用户根本没办法保证下一次请求的代码不会变。除非你自己分发前端 HTML 文件，或者用个外部软件来提供保障，那这也就和你原文中 "客户端浏览器纯前端"、 "浏览器加载页面时" 矛盾了。