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

[busier]

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

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

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

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

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

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

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

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

[fruitmonster]

第一个问题：给谁用，使用场景是啥

[busier]

@fruitmonster 场景就是加密传输临时消息啊，又不想被别人获取。比方说打个加密压缩包传给同事，但是密码又不想明文发过去。

只讨论技术实现及缺陷，这类其它问题不再讨论范畴。

[makaflow]

国内是不行，无法监管就会被叫停

[7lQM1uTy635LOmbu]

@busier 服务器不要留存信息，转发的消息确认送达后直接删除，并且应该设置 ttl ，最大存活时间，可以由发送方自定义，并且由发送方决定超时是否由服务器代替发送超时通知，但最大不能超过 x ，超时直接删除。

即便是同一对通信用户，请定期 rotate 密钥对，确保历史消息不可被物理解除后恢复。

至于安全交换公钥，印象中有看到过相关方案，反正是个已经解决的问题。

如何防止中间人攻击？（比如劫持，代理）

[cassidy0134]

@busier 本人 ops 一枚，有多台海外服务器（ sg ，us ），我不想暴露自己但想帮 op 测试这个页面和 app ，ops 相关的工作可以全部我来，你只要写代码即可，如果愿意，请给我一个临时联系方式。

[cassidy0134]

其实我也早就想做这件事，奈何不会写代码~

[shinsekai]

telegram web 算 OP 所说的吗？

[ltkun]

如果不是 web 可以选择 k9mail 这种 使用普通 email 就能端到端的 app

[x2420390517]

都通过其它渠道交换公钥了，我干嘛不直接通过那个渠道顺便把加密消息一起发了得了？

[dislazy2023]

感觉可行，这个用来做临时聊天还是很有用处，我也一直在找这样的开源 web ，不太好找

[jeesk]

肯定可行, 不过没什么鸟用呀

[jeesk]

使用场景? 如果仅仅是分享问价? 那么直接临时启动一个 http-server 即可

[ooolooo]

@shinsekai 不算, tg 有账号系统
tg 也没有默认端到端加密, web 更不是

[wushenlun]

email pgp 加密不就好了 或者 whatsapp

[ArthurSS]

webrtc 不是可以直接支持？

[ArthurSS]

很早以前写了一个小 demo ，用的免费信令服务器，国内不一定能连接上： https://arthursuz.github.io/peer-link/
输入另外一边的 id ，既可建立连接，完全 p2p

[Nazz]

可行, 逻辑全部走 WASM

[Nazz]

内置证书

[superkkk]

https://www.v2ex.com/t/1043160

[Conda]

我歪个楼，我们业务里的埋点和日志这类通用的服务就是基于 protobuf 传输的，发送前加密通过正常的 http 发送加密后的字符串，服务端拿到之后再解密，这个思路和你的聊天工具也是类似的吧，只要按我的格式传过来就行。

[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 文件，或者用个外部软件来提供保障，那这也就和你原文中 "客户端浏览器纯前端"、 "浏览器加载页面时" 矛盾了。

[busier]

确实存在 raw0xff “ 你可能没有意识到在不能保证用户访问的第一个页面的完整性的前提下 e2ee 并不安全。”说的问题

此设计中，前端本就是纯静态，分发前端 HTML 方案可行。

[raw0xff]

大概分三个问题：用户身份验证、私钥安全存储、页面完整性校验

目前被困在页面完整性实时校验问题上。

[raw0xff]

@Nazz 我对逆向工程不懂，wasm 嵌入证书的话是否会被逆向出来？ wasm 中的变量是否会被恶意 js 脚本读出来？

[busier]

@raw0xff
考虑运行时选择通信服务器。至于页面分发部分就独立出来，让用户通过自己的受信渠道分发。

[Nazz]

@raw0xff 逆向没那么容易

[qfdk]

双认证 吧 试试？