V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
brader
V2EX  ›  程序员

真正的点对点聊天通讯隐私实现想法

  •  
  •   brader · 126 天前 · 9640 次点击
    这是一个创建于 126 天前的主题,其中的信息可能已经有所发展或是发生改变。

    实现想法:

    A 发送消息给 B

    检测是否持有 B 的公钥  
    
        若有,使用 B 的公钥对消息进行 RSA 加密并发送。  
        若无,则先请求 B 传输公钥过来,B 生成公私钥并缓存在本地。  
    
    B 收到消息后,使用自己的私钥进行消息解密。  
    

    B 发送消息给 A
    同理

    我想,这样应该才是能实现真正隐私通讯的,连服务提供方都无法窃取消息的,而不是市面上一些聊天软件慌称的“隐私”。

    这种通讯隐私方案可实现吗?会有软件愿意为了用户隐私而实现吗?

    第 1 条附言  ·  126 天前
    看了大伙回答,补充几点我的想法:
    这里我说的是解决聊天内容隐私问题。
    我看到大家说中间人攻击,我想法是这不需要我去处理吧,上一层网络通讯的时候是 HTTPS 呢,这一层可以解决。

    第二个,大家说 RSA 效率问题,这怎么会有问题呢,AB 客户端,只解自己的消息,CPU 这点能力都没有吗?这根本不在考虑问题内。
    服务端才要考虑这个问题,因为服务端 RSA 解密的话,是要面对 N 多个客户端的。
    125 条回复    2021-07-31 09:38:45 +08:00
    1  2  
    learningman
        1
    learningman  
       126 天前   ❤️ 5
    Telegram 呗
    also24
        2
    also24  
       126 天前   ❤️ 1
    『若无,则先请求 B 传输公钥过来,B 生成公私钥并缓存在本地。 』


    传输的过程被中间人了怎么办?
    Vegetable
        3
    Vegetable  
       126 天前   ❤️ 1
    这种聊天软件其实有很多...基于 matrix 开发的客户端可以轻松实现端到端加密
    官方专门有文档指导开发者如何实现带有端到端加密的客户端

    https://matrix.org/docs/guides/end-to-end-encryption-implementation-guide

    还有在大陆可以(几乎)无障碍使用的 keybase(已被 zoom 收购),也是宣称端到端加密的。

    我们生活中几乎没见过这种东西的原因,相信你也能想明白。
    SingeeKing
        4
    SingeeKing  
       126 天前
    所有的 E2EE 通信不都是这样,主要问题还是在密钥交换上面
    lzxz1234
        5
    lzxz1234  
       126 天前   ❤️ 37
    好家伙,https 诞生记
    brader
        6
    brader  
    OP
       126 天前
    @also24 公钥是可全网公开的,所以被截获是无所谓的
    also24
        7
    also24  
       126 天前
    @brader #6
    『被中间人』指的是,你怎么知道你收到的是 B 的公钥,而不是中间人 C 的呢?
    jousca
        8
    jousca  
       126 天前
    这不就是 HTTPS 的工作原理?
    dingwen07
        9
    dingwen07  
       126 天前 via iPhone
    @brader #6 建议详细了解下中间人攻击
    yfugibr
        10
    yfugibr  
       126 天前   ❤️ 25
    这种东西一直都不是技术问题。
    masterclock
        11
    masterclock  
       126 天前
    常见通信软件是不是就绿色的那个不支持 e2ee ?
    brader
        12
    brader  
    OP
       126 天前
    @also24 不使用 B 的公钥加密,B 是无法解密消息的,那么软件就无法提供正常服务,B 也能发觉异常
    also24
        13
    also24  
       126 天前
    @brader #12
    参考 9 楼,建议详细了解下中间人攻击
    finab
        14
    finab  
       126 天前
    @brader
    A 发送消息给 B
    发现没有公钥, 从 B 请求公钥, 此时中间人生成公私钥,将中间人公钥发送给 A
    并请求 B,B 返回正确的 B 公钥,中间人保存 B 公钥。

    此时 A 拿到 中间人公钥加密消息,中间人获取密文,用中间人私钥解密,将消息再由 B 公钥加密,发送给 B
    lakehylia
        15
    lakehylia  
       126 天前
    @also24 防中间人那不就是证书那一套了
    sakura1
        16
    sakura1  
       126 天前
    https 也有一段通过对称加密交互公钥的过程吧我记得,它也不全依赖技术,而是利用证书解决陌生人之间的信任问题。好吧,蹲个大佬仔细说说。
    hiplon
        17
    hiplon  
       126 天前
    PGP, autocrypt,现成的 delta chat 可以看看
    chizuo
        18
    chizuo  
       126 天前
    建议学学网络安全吧。你说的就是一个小作业而已。
    also24
        19
    also24  
       126 天前
    @lakehylia #15
    但是楼主设计的这一套里面没有类似机制,或其它能解决这个问题的机制。
    chizuo
        20
    chizuo  
       126 天前   ❤️ 2
    @chizuo 小作业都比你的要复杂一点点,因为 RSA 耗费资源多,使用的是 OTP ( one time pad ),每次消息传输都用一次性的 AES 来加密,RSA 仅加密 AES 的密钥就行了。如果感兴趣,还是建议学学网络安全,会有一个基本的认识。
    lakehylia
        21
    lakehylia  
       126 天前   ❤️ 1
    @also24 两个要隐私通讯的人,见一面,交换密钥就好了。真正的防中间人~~
    Mitt
        22
    Mitt  
       126 天前
    @brader #12 这一样防不住中间人的,中间人可以生成一份自己的公私钥分别拦截并返回给两边客户端,两边客户端的数据中间人也都能解开并重新加密,建议了解一下证书体系的信任机制
    bruce0
        23
    bruce0  
       126 天前
    @lakehylia 最靠谱的,面对面 交换秘钥 0.0
    UnknoownUser
        24
    UnknoownUser  
       126 天前
    刚学了《应用密码学》,你说的这个方案是一个仅使用非对称密码的一个很不成熟的方案。
    1. 有中间人攻击:请求 B 的公钥的时候存在中间人攻击,解决方案是使用 CA
    2. 计算效率低:使用非对称加密的计算代价都太高了,一般非对称加密用来传输对称密钥,对称密钥加密消息
    3. 不具有鉴别性:还需要用 A 的私钥对消息进行签名,来供 B 验证确定你的身份
    securityCoding
        25
    securityCoding  
       126 天前
    @sakura1 你指的是 服务端用 ca 中心的私钥加密(电子证书+服务器公钥)到浏览器,浏览器用内置的 ca 中心公钥解密并验证电子证书合法性这个过程吧
    LessonOne
        26
    LessonOne  
       126 天前
    @Vegetable 请大胆的说出来 ....
    1041412569
        27
    1041412569  
       126 天前
    跟楼主想法相似的是安全的多用途 Internet 邮件扩展 S/MIME ,而不是 https 、PGP 。
    gps949
        28
    gps949  
       126 天前
    RSA 加密?一般肯定产生会话对称密钥加密啊
    luvroot
        29
    luvroot  
       126 天前
    nat upd 打洞+定时密钥更新加密通讯 @brader
    777777
        30
    777777  
       126 天前   ❤️ 1
    对于上面所说的中间人攻击,我觉得可以用区块链解决,所有人公开公钥且公钥不和用户绑定。发消息时用公钥加密广播,仅持有此公钥的私钥的人才能看到所发消息。但存在一个消息泛滥问题,所有人都可以发消息给这个公钥,然而数字货币不会存在(因为没人会随便给你转账),这个问题可以用发消息+数字货币的方式解决。
    shansing
        31
    shansing  
       126 天前
    @777777 别什么都扯上区块链啊。去中心化的区块链恰恰就是不能解决身份认证的问题。如果只认公钥,不管现实用户是谁,简直就没有中间人冒充的余地了,哪里还需要区块链出场。
    777777
        32
    777777  
       126 天前
    @shansing 只认公钥,如何解决消息泛滥问题?
    777777
        33
    777777  
       126 天前
    @shansing 要的就是不需要身份认证,实现身份隐私+通信隐私
    NeezerGu
        34
    NeezerGu  
       126 天前
    A 和 B 在线下通过投骰子选个地儿洗个澡儿,在洗澡过程中双方全身赤裸在淋浴头下时,交换一个 10 位数以上包含字母+数字+符号的密码。

    之后双方用任意一个经得住考验的加密算法并加上这个密码(好像叫盐?)就行。

    不太懂密码学,似乎这样就 ok 了?
    qrobot
        35
    qrobot  
       126 天前
    回楼主, 有, 这个软件叫做 GnuPG , 也叫做 GPG
    tangds99
        36
    tangds99  
       126 天前
    keybase 了解下
    dallaslu
        37
    dallaslu  
       126 天前
    @1041412569 PGP 也可以加密邮件呀,和 S/MIME 功能相近
    dqzcwxb
        38
    dqzcwxb  
       126 天前   ❤️ 12
    kera0a
        39
    kera0a  
       126 天前 via iPhone
    你都 https 了,还要你这个方案干啥,毫无卵用
    gBurnX
        40
    gBurnX  
       126 天前
    @777777 你这方案第一句话就不可行: [所有人公开公钥] 。请问怎么做到这一点?
    brader
        41
    brader  
    OP
       126 天前
    @kera0a https 的话,服务器还是拿到了聊天内容啊,加了这个,服务器就也拿不到聊天内容
    Jooooooooo
        42
    Jooooooooo  
       126 天前
    端到端加密通讯早就有成熟技术并落地了...

    搜下 tg 的实现.
    expy
        43
    expy  
       126 天前
    线下提前交换公钥吧,Email + GnuPG 勉强能用。
    DeutschXP
        44
    DeutschXP  
       126 天前 via iPhone
    难道不是只有某一个聊天软件不是点对点加密么?
    所以这哪是技术问题。
    人家 WhatsApp 必须手机在线才能在电脑上使用,就是因为点对点加密,你电脑 /Web 端看到的消息是手机端解密后再加密传递过去的,服务器端是获取不到明文消息的。
    某个聊天软件也一直无法单独使用电脑端,仅仅就是为了让你不方便。
    上周 WhatsApp 开始内测多设备同时登陆并可以手机离线了,某软件这两天立刻抢先推出同时多设备的功能。
    gBurnX
        45
    gBurnX  
       126 天前
    题主的问题,是在于没有学习信息安全。

    比如题主说,HTTPS 能解决中间人攻击问题,问题是,有了 HTTPS,还要你这套东西干嘛? HTTPS 已经具备了你自己发明的这一套东西的所有功能。
    kera0a
        46
    kera0a  
       126 天前 via iPhone   ❤️ 1
    @brader
    服务器做中间人攻击不就能拿到了

    a 和 b 应该直接做 https 通信才行
    harwck
        47
    harwck  
       126 天前
    好,你说了一大堆,很牛逼,很 fancy 。
    你还问了会有软件去实现吗。
    那请问如果是你你会去实现吗?你是慈善家?
    earneet
        48
    earneet  
       126 天前
    看了你的补充想法,我再补充一点。。。
    RSA 单次加密能力,密文一定得小于密钥,那么 1024 位的密钥,一次也只能加密 128 个字节,而你遇到稍微长点的消息,就要分很多组进行加密。
    其次, 你所有消息都使用了同一组密钥进行加密,那么一旦密钥被窃(也可能是被破解),那么以前所有的记录都再无秘密可言。哪怕,你使用 DH 协议交换一个密钥都比这个来的强的多。
    最后,要真正实现隐私,要不要考虑引入 OTP ?
    catror
        49
    catror  
       126 天前 via Android
    signal,直接去看代码吧,还有端到端加密的群聊
    chairuosen
        50
    chairuosen  
       126 天前
    这跟 HTTPS 原理不一样,这是"两军问题",无解
    FS1P7dJz
        51
    FS1P7dJz  
       126 天前
    @Vegetable 你孤陋寡闻了,最常见的 imessage 就是 P2P 加密
    Vegetable
        52
    Vegetable  
       126 天前   ❤️ 1
    @FS1P7dJz 之前也有帖子讨论过类似问题。iMessage 说到底不是一个在国内诞生的产品,作为一个面向其他地区设计的产品,做成这样自然是非常合理的。它引入中国究竟没有做出牺牲我们都不知道,但是诞生在国内,并面向国内用户,宣称端到端加密的聊天软件,貌似不会有什么好下场。
    JamesMackerel
        53
    JamesMackerel  
       126 天前 via iPhone
    双方线下交换公钥,随后在使用聊天软件时,每次都把要发送的消息用对面的公钥进行 gpg 加密再发送。稳得一批,微信也可以很安全。
    jiayong2793
        54
    jiayong2793  
       126 天前
    政治上不允许
    huangmingyou
        55
    huangmingyou  
       126 天前
    我手工用 gpg 加密内容,然后通过微信发送也可以啊,解密也是手工。也许可以把加密解密做到输入法?通过现成的 im 工具传输加密后的内容?
    adsltsee94
        56
    adsltsee94  
       126 天前
    小飞机不就是么
    RainyH2O
        57
    RainyH2O  
       126 天前
    就是因为你这想法会被中间人攻击,所以才出现 CA 机构来颁发 CA 证书解决中间人攻击的啊。
    有了 CA 证书,就有了 SSL,就有了 HTTPS 。SSL 还通过密钥交换确保前向安全性。
    基于 SSL 的话就只有发信方和收信方能解读加密密文了,中间人劫持封包就得面对大数分解或者离散对数的数学难题。
    我没看懂你觉得哪里还有问题,可能你没把 SSL/TLS 的原理学通透。
    clf
        58
    clf  
       126 天前
    有这样的软件了,而且还是国内的,使用者很少罢了,个人觉得存在运营风险。
    RainyH2O
        59
    RainyH2O  
       126 天前   ❤️ 1
    至于市面上的 IM 软件为何不用这套方案,一方面是出于多端信息同步的需求,一方面就是上面提及的非技术因素了。
    实际 IM 卖的是一个社交服务,真正的隐私 IM 应该只是卖一个通讯录,类似一个 DNS 让双方能互相找到彼此建立 SSL 会话即可。
    treblex
        60
    treblex  
       126 天前
    我最近在做一个手动加密的聊天工具,就是 app 本地维护一个公钥列表和消息列表,然后可以复制加密后的内容发送给朋友
    暂时没考虑做服务端
    Dogtler
        61
    Dogtler  
       126 天前 via iPhone
    在国内别想了
    treblex
        62
    treblex  
       126 天前
    @treblex 楼主的想法应该跟我这个差不多,就是客户端加密消息,服务端制作标准实现

    但是运营不了,国内似乎要求必须有审查的能力,存密文的话没啥用,除非你把用户私钥存了😂
    https://www.v2ex.com/t/745797

    现在手上这个 app 只打算做到这个程度了
    后端如果做的话,最好是能做一个标准或者开源实现给用户自己部署和开发,在 app 上设置服务器地址(实力不足
    delpo
        63
    delpo  
       126 天前   ❤️ 1
    @treblex 你这个已经有现成的了,win 上叫 gpg,安卓有一个叫 openkeychain 的实现
    treemonster
        64
    treemonster  
       126 天前 via Android
    nullcoder
        65
    nullcoder  
       126 天前 via Android
    啊,还以为会看到量子纠缠
    ck19920702
        66
    ck19920702  
       126 天前
    v2clay
        67
    v2clay  
       126 天前
    1. 你说的就是 rsa 公钥密码体系的雏形
    2. ca 是为了解决中间人攻击的。
    3.如果外层套一层 tls 。那么底层不需要 rsa,对称加密就行,效率还高。
    4.此贴终结
    v2clay
        68
    v2clay  
       126 天前
    建议多读书,把 rsa 吃透。
    sholmesian
        69
    sholmesian  
       126 天前
    推荐楼主看看 XMPP 的

    XEP-0384: OMEMO https://xmpp.org/extensions/xep-0384.html

    XEP-0364: OTR https://xmpp.org/extensions/xep-0364.html
    railgun
        70
    railgun  
       126 天前
    通信加密已经不是一个技术问题了……
    agee
        71
    agee  
       126 天前 via iPhone
    防中间人又不用根证书的话,只有上 ecdh 算法,可自行谷歌,真正实现不用见面的情况安全交换密钥,防中间人攻击腾讯就是用的 ecdh
    kirch
        72
    kirch  
       126 天前
    首先,不能有中心服务器
    Hardrain
        73
    Hardrain  
       126 天前
    "若无,则先请求 B 传输公钥过来,B 生成公私钥并缓存在本地。"

    这就像一个没有 CA 的 TLS, 或者一个不校验证书有效性的糟糕 TLS 实现, 对中间人攻击没有任何免疫力.

    跟你的想法类似的是 GPG, 但 GPG 的开发者认为, 交换密钥应该以"线下碰面"的形式完成.

    以上是技术问题, 至于政治 /法律问题我不做讨论. 你认为微信如果想实现类似的技术, 不会受到阻力吗?
    Hardrain
        74
    Hardrain  
       126 天前
    @agee ECDH 是椭圆曲线域上的 Diffie-Hellman, 照样需要签名.

    例如 TLS 的加密套件, ECDHE_RSA_* 和 ECDHE_ECDSA_* 中的 RSA 和 ECDSA 就是签名算法.
    iseki
        75
    iseki  
       126 天前
    恕我孤陋寡闻,中间人攻击基本上只能通过证书或者类似的其他“预共享的信息”来实现,你这里好像根本没提到对这个问题的解决方案。如果不想引入证书也可以参考下 Telegram 的 secret chat,两边用户可以通过对比一个颜色点阵来确保没有被中间人攻击。
    bs10081
        76
    bs10081  
       126 天前
    Rocket.Chat?
    parametrix
        77
    parametrix  
       125 天前
    1. 只用 RSA 效率低,也没必要,而且不是所有设备都有个人电脑的算力,就算有也不应该挥霍。
    2. 只用 RSA 缺乏一些关键的安全特征,比如完全向前安全性。TLS 标准算法里头一长串又不是为了炫技。
    3. 解决中间人问题要不然由第三方担保,要不然就是预共享密钥做 HMAC 。然而有预共享密钥的前提下,可以直接 HMAC 配合密钥交换算法进行端对端加密通信,RSA 反而不是必要的,徒增消耗。
    4. 市面上端对端加密解决方案不是有没有,而是太多了,商业的、社区的应有尽有。

    PS:好奇楼主认为 https 是怎么实现的?
    vagranth
        78
    vagranth  
       125 天前 via Android
    fan123199
        79
    fan123199  
       125 天前
    lz 写的方案太初级,就像有个人说,我发现了用 break 可以退出 for 循环一样。 不过想要隐私通讯的想法是很 ok 的,可以多了解下评论里提及的开源软件。不说了,我也学习去
    MarkLeeyun
        80
    MarkLeeyun  
       125 天前
    大陆应该不存在能商用的这玩意。
    love2020
        81
    love2020  
       125 天前
    没有绝对安全的网络
    yiqiao
        82
    yiqiao  
       125 天前
    @dingwen07 最近的吴亦凡和都美竹事件就是中间人攻击。两头骗
    wy315700
        83
    wy315700  
       125 天前
    iMessage 好像就是这么设计的
    lonnyzhang
        84
    lonnyzhang  
       125 天前
    去看 Telegram 的端对端加密算法:
    https://core.telegram.org/api/end-to-end

    是基于下面这个算法:
    https://en.wikipedia.org/wiki/Diffie%E2%80%93Hellman_key_exchange

    总结下就是:
    1.服务端给客户端提供两个数(x,y)
    2.客户端 A:
    生成随机数 r1,计算 m=pow(x, r1) % y
    3.客户端 B:
    生成随机数 r2,计算 n=pow(x, r2) % y
    4.A 、B 互相发送结果 m 、n
    A 计算 key=pow(n, r1) % y
    B 计算 key=pow(m, r2) % y
    这时,两个 key 是相同的,后面用这个 key 做对称加密即可

    注:y 要足够大,x 、y 、m 、n 都是公开的,但是只要 r1 、r2 不泄露,别人想要计算出 key 的值难度很大,包括服务端。
    Rcnaec
        85
    Rcnaec  
       125 天前
    歪个楼,目前对于端对端加密的聊天软件监控的通杀方式,是监控顶部通知栏
    lingxi27
        86
    lingxi27  
       125 天前
    密码学很有趣的,建议多学点
    newmlp
        87
    newmlp  
       125 天前
    这不就是 tls 的原理吗,直接拿 tls 来用不就行了
    pkoukk
        88
    pkoukk  
       125 天前
    建议了解一下 telegram 的实现,加密不仅要考虑前向安全,还得考虑后项安全。
    如果秘钥泄露,那么你的所有信息都会泄露。
    tg 用了双棘轮算法保证每条消息的秘钥都是不一样的
    ilaipi
        89
    ilaipi  
       125 天前
    曾经做过一个利用邮箱实现类似聊天方式的。完全不需要服务器,没做完流产了
    misaka19000
        90
    misaka19000  
       125 天前
    楼主多去读点书吧,别做民科
    Kareless
        91
    Kareless  
       125 天前
    这不就是 telegram 吗
    Joshua999
        92
    Joshua999  
       125 天前 via Android
    A 怎么知道收到的公钥是 B 发来的
    NilChan
        93
    NilChan  
       125 天前 via Android
    思而不学则殆。看一下 HTTPS 工作原理就知道了。另外 RSA 一般用来加密对称密钥,而不是消息本身。
    villivateur
        94
    villivateur  
       125 天前 via Android
    楼主可能刚刚了解非对称加密原理,然后就想了这一出。
    但是还是要多读书啊
    Rheinmetal
        95
    Rheinmetal  
       125 天前
    读这个之前没人教你 don't make your own crypto 么
    真密谈应该明文配 one time pad
    DBT
        96
    DBT  
       125 天前
    @earneet 说的很对,有个细节需要更正,RSA 算法由于 PKCS#1 补丁的关系,单次加密最大数据长度为 117 字节,嘿嘿。
    ye4tar
        97
    ye4tar  
       125 天前
    想要 End to End 的加密,首要解决的是两端交换的密钥确实是他们自己说的密钥,而不是由中间人篡改后的密钥。上面网友说的面对面交换密钥就能保证到。
    wlbyg888
        98
    wlbyg888  
       125 天前 via Android
    技术早就有了!落地应用,环境不现实
    doveyoung
        99
    doveyoung  
       125 天前
    怎么说呢,楼主能来 v2,竟然不知道 telegram 吗
    GeruzoniAnsasu
        100
    GeruzoniAnsasu  
       125 天前
    @lzxz1234

    好家伙,超时空网速
    1  2  
    关于   ·   帮助文档   ·   API   ·   FAQ   ·   我们的愿景   ·   广告投放   ·   感谢   ·   实用小工具   ·   1102 人在线   最高记录 5497   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 30ms · UTC 21:56 · PVG 05:56 · LAX 13:56 · JFK 16:56
    ♥ Do have faith in what you're doing.