聊天软件端对端加密疑问

原理是，你用私钥加密消息，然后把密文和公钥发给服务器？

举报，被下架了说明是真的有端到端加密，没下架就是假的

@biubiuF 好方法,哈哈哈哈哈

微信的话，有权限可以看到你所有的通讯记录，但是其他具有恶意的第三方比较困难（有 tls ，懂得都懂。但除了 tls 之外，没有其他的了），想端对端加密就发邮件。

通常说的是，客户端到客户端加密，但国内特色“端到端”一般指客户端到服务端

自己用 PGP

Signal. 不过我觉得强制手机号注册的聊天软件都很恶心。即使在手机号不实名制的国家，手机号的匿名性和邮箱也不是一个级别的

闭源的软件的话, 感觉有点难验证, 端对端加密意味着只有会话方可以解密, 要验证这点可能很难, 至于是不是加密倒是很容易验证, 如果是使用 https 交流, 可以自己做中间人, 但即使读取了 https 的密文发现聊天内容的确额外进行了加密, 你也无法确定持有解密密钥是不是只有会话方.
开源如 Telegram 则可以通过看源码来确定.

理论上有端到端加密的聊天软件，电脑和手机同时登录一个账号，同一时间的聊天信息应当只有一个设备可以看到。即：电脑和手机不应当（通过服务端）交换私钥。

微信那个就别说了，18 年不是曝光有一个有关部门的 elasticsearch 未加密，里面全是聊天记录么。

中华人民共和国国家互联网信息工作室《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》：

第三条 互联网信息服务提供者具有下列情形之一的，应当依照本规定自行开展安全评估，并对评估结果负责：　
（一）具有舆论属性或社会动员能力的信息服务上线，或者信息服务增设相关功能的；

第五条 互联网信息服务提供者开展安全评估，应当对信息服务和新技术新应用的合法性，落实法律、行政法规、部门规章和标准规定的安全措施的有效性，防控安全风险的有效性等情况进行全面评估，并重点评估下列内容：
（三）对用户的账号、操作时间、操作类型、网络源地址和目标地址、网络源端口、客户端硬件特征等日志信息，以及用户发布信息记录的留存措施；
（四）对用户账号和通讯群组名称、昵称、简介、备注、标识，信息发布、转发、评论和通讯群组等服务功能中违法有害信息的防范处置和有关记录保存措施；
（七）建立为网信部门依法履行互联网信息服务监督管理职责提供技术、数据支持和协助的工作机制的情况；
（八）建立为公安机关、国家安全机关依法维护国家安全和查处违法犯罪提供技术、数据支持和协助的工作机制的情况。

国内内容都要监管, 公开的应用基本不可能端对端加密? dddd

端到端就没法做过滤 /鉴黄这些,国内如果没有这个能力,是不能上架的

你为什么会想到去小米商店里面下载正儿八经的端对端加密软件。

能上架的想都不用想，肯定不是端对端

@BBCCBB 端到端加密是可以内容监管的，靠举报者上传解密的内容，发送者老被举报的话封号。
如果消息加密前生成一个摘要上传，被举报了之后批量拉黑这个摘要，可以在不泄露信息内容的情况下批量对信息限流。
但这种监管，国内肯定觉得不够。

国内监管的要求，群聊肯定是可以解密的，一对一聊天不太清楚。
要验证端对端加密，要查客户端在创建密钥对的时候，绝对不会上传私钥，以及客户端发信的时候，只会问服务器要目标客户的公钥，而不是偷偷摸摸给王晶也发一份。
目前好像没人研究这个，因为默认国内都是可以看到的

没有被墙的就不是端到端加密。

国外端到端只有一个叫 signal 的吧, 电报都不能算.

@TomChaai 这样举报岂不是很容易伪造证据（聊天截图和文本内容）？

@liuidetmks 电报 1 对 1 是端到端加密吧，群聊不是加密而已。

@caqiko 并不是用户可以直接干预的上传功能，由客户端封闭实现。
此外我提到的摘要功能也可以防伪。

@caqiko 此外仔细一想，根本不需要额外的摘要做防伪，只要上传的消息内容，和用公钥重新加密出来的内容不一致，就可以确认是伪造的举报了

"至于什么原因不清楚": 政策原因

"检验软件是否采用了端对端加密": 连续多次说反动言论, 看是否喝茶

Signal 强制绑定手机号，而且还能显示，再怎么加密有个 P 用。
真要加密，用 MATRIX 自建吧。

你在国内做通讯软件还想端对端加密

没法检验，通常只能通过签订保密协议来确保法律上的保密义务，你要真想做到端对端安全只能对通讯工具的代码、部署环境、运营方管理方式等进行审计。

国内有法定管控义务，所以不大可能有真端对端加密的工具合法经营，除非是企业团体自建自用，反正谁运营谁负责。

国内不可以加密，老大哥看不见你们聊什么，心里不舒服

pidgin 有 gnupg 插件，以前聊 msn 就可以加密。 但是普通人真没有加密需求。 况且输入法也能泄密。

@aeli 电报 1 对 1 的端对端加密要手动打开才行

二楼的方法, 应该可行
分享一个应用
keybase.io
End-to-end encryption for things that matter.
Keybase is secure messaging and file-sharing.

keybase +1

客端源是端到端加密的必要件，不源的就不用看了，真假都意

建用 matrix

或者用第三方源加密工具：
t/832302

端对端就是一个伪命题，所有的设备都需要有一个公网 ip 才行，你一个局域网怎么端对端，路由不给你开映射，歇菜。
只要经过服务器中转的基本就不安全。就看要不要保存你的信息了。 在牛逼的加密， 只要有服务器存的样本数据够多，理论上来说都是可以推导破解出来。

看到附言，回复一下 OP 的问题：
- 我前一条复制了《具有舆论属性或社会动员能力的互联网信息服务安全评估规定》，现在上架的 IM 软件应该都要提交自我评估表，也就是说它们都不是「不能完全被监管」；
- 它们声称「端到端加密」，但是也可能是话术，是指「客户端到服务端」；
- 在技术上无法简单检验是否真的是「端到端加密」，需要抓包传输的数据，逆向软件的行为等操作。即使是开源软件，你也无法保证在商店上架的版本是完全按照公开的源码编译构造的。这是安全和信任的问题，绝对的安全就需要自己审计代码和编译。WhatsApp 和 Line 也只能靠厂商承诺。

@jones2000 除非一次一密，再牛逼的加密都能爆破，无非资源问题，这不废话。

@caqiko telegram 也有举报功能啊，什么也不需要提交

宣称是端对端的，实际上服务器都能解密能力的，不然不满足监管要求

只能能连上，端对端加密是很好实现的，公钥加密私钥解密即可，“连接上”这个阶段，技术上也是没难度的，但是监管上的难度比上天都难。

@DonDonc #34 开源这个肯定有人去验证过上架版本的 hash 跟自己编译源码的 hash 是否一致的情况

看看能不能发送 100 汉字 如果没分片 会报错

@cxe2v 编译环境可能无法做到一致，发布时需要加上证书等情况，最后哈希会不同，现在开源软件会靠自动编译以及公开编译脚本。但是依旧没办法 100%保证靠谱。绝对的安全代价很大，普通人只能相信某个权威。

comingchat 了解下，隐私聊天，支持 web3, 数字钱包等。https://www.coming.chat/

我的理解

现有的用户不自行保存私钥的情况下实现的端到端加密方式如下：

用户 A 用户 B 分别生成私钥+公钥

然后将 公钥发送到中心化的服务端

A B 之间通讯时需要先去查询获取对方的公钥

然后彼此的消息使用对方的公钥加密，对方使用私钥解密

当然了这样性能不够好，可以按时间生成对称加密密钥，两者仅需在一段时间内协商好对称密钥即可

此时会存在一个小问题，如果 A 或 B 用户完全退出登录 APP 清楚数据

重新登录后将失去查看历史记录消息的能力

因为私钥是不可以上传的服务器的

即仅可以在客户端可见

同时若多客户端同时登录一账户也会存在问题，新的设备没办法获取当前的私钥

当前服务商可以选择从旧设备上面加密获取

但是此操作可能会被服务商利用

比较好的处理方式就是，新设备登录时需要任意一个旧设备点击确认（点击确认就代表把旧设备的私钥以安全的方式传输给新设备）

这样可以实现多客户端同时登录


-----------------------------------------------------------

回归原题，检测是否为端到端加密，那就是审核客户端代码了，只要客户端的代码中没有将客户端生成的公钥上传的服务端那就没问题！或者说即使有上传私钥的情况也是必须经过用户确认授权然后加密传输到新设备的！

PS：事实上这种确认授权的方式依旧可能被服务商利用，然后获取你本地的私钥，即使需要用户确认（因为服务商可以返回一个伪装的新的客户端的公钥）

除非旧设备直接扫码获得新设备的公钥，然后直接上传服务商传输

那么此时的私钥传输是安全的

---------------------------------------------------------------

事实上对于普通用户，想要完全验证几乎不可能的！！！

因为即使客户端代码开源，但是上架到 app store ，google play 以及其他平台的客户端编译后的软件你没办法确认是否携带了私货

此时大概能有以下几种方案进行解决
一，抓包验证，客户端的所有请求都是可以被抓包后解密出原文的，可以通过此 APP 的全部网络通讯来确定不存在上传额外的信息
二，自行编译源码

--------------------------------------------------------------

其实也有另外的实现方式，那就是用户自行保存私钥的模式

这就是目前 web3 社交 /聊天项目的实现了

@imtianx 都不开源 隐私与安全只能靠项目方嘴保证了

@8520ccc 文中提到，有哪些 web3 社交 /聊天项目的实现了，我好像只发现了 signal

@versacep 还有 session 了解一下，匿名注册，去中心化区块链，洋葱浏览器分布式