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

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

  •  
  •   brader · 2021-07-28 14:51:06 +08:00 · 13154 次点击
    这是一个创建于 974 天前的主题,其中的信息可能已经有所发展或是发生改变。

    实现想法:

    A 发送消息给 B

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

    B 发送消息给 A
    同理

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    PS:好奇楼主认为 https 是怎么实现的?
    vagranth
        78
    vagranth  
       2021-07-29 06:30:50 +08:00 via Android
    fan123199
        79
    fan123199  
       2021-07-29 07:50:40 +08:00
    lz 写的方案太初级,就像有个人说,我发现了用 break 可以退出 for 循环一样。 不过想要隐私通讯的想法是很 ok 的,可以多了解下评论里提及的开源软件。不说了,我也学习去
    MarkLeeyun
        80
    MarkLeeyun  
       2021-07-29 08:45:02 +08:00
    大陆应该不存在能商用的这玩意。
    love2020
        81
    love2020  
       2021-07-29 08:59:52 +08:00
    没有绝对安全的网络
    yiqiao
        82
    yiqiao  
       2021-07-29 09:14:34 +08:00
    @dingwen07 最近的吴亦凡和都美竹事件就是中间人攻击。两头骗
    wy315700
        83
    wy315700  
       2021-07-29 09:23:57 +08:00
    iMessage 好像就是这么设计的
    lonnyzhang
        84
    lonnyzhang  
       2021-07-29 09:30:33 +08:00
    去看 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  
       2021-07-29 09:33:38 +08:00
    歪个楼,目前对于端对端加密的聊天软件监控的通杀方式,是监控顶部通知栏
    lingxi27
        86
    lingxi27  
       2021-07-29 09:48:42 +08:00
    密码学很有趣的,建议多学点
    newmlp
        87
    newmlp  
       2021-07-29 09:53:06 +08:00
    这不就是 tls 的原理吗,直接拿 tls 来用不就行了
    pkoukk
        88
    pkoukk  
       2021-07-29 10:01:13 +08:00
    建议了解一下 telegram 的实现,加密不仅要考虑前向安全,还得考虑后项安全。
    如果秘钥泄露,那么你的所有信息都会泄露。
    tg 用了双棘轮算法保证每条消息的秘钥都是不一样的
    ilaipi
        89
    ilaipi  
       2021-07-29 10:33:13 +08:00
    曾经做过一个利用邮箱实现类似聊天方式的。完全不需要服务器,没做完流产了
    misaka19000
        90
    misaka19000  
       2021-07-29 10:39:05 +08:00
    楼主多去读点书吧,别做民科
    Kareless
        91
    Kareless  
       2021-07-29 10:43:28 +08:00
    这不就是 telegram 吗
    Joshua999
        92
    Joshua999  
       2021-07-29 11:41:34 +08:00 via Android
    A 怎么知道收到的公钥是 B 发来的
    NilChan
        93
    NilChan  
       2021-07-29 11:46:12 +08:00 via Android
    思而不学则殆。看一下 HTTPS 工作原理就知道了。另外 RSA 一般用来加密对称密钥,而不是消息本身。
    villivateur
        94
    villivateur  
       2021-07-29 11:56:23 +08:00 via Android
    楼主可能刚刚了解非对称加密原理,然后就想了这一出。
    但是还是要多读书啊
    Rheinmetal
        95
    Rheinmetal  
       2021-07-29 11:58:57 +08:00
    读这个之前没人教你 don't make your own crypto 么
    真密谈应该明文配 one time pad
    DBT
        96
    DBT  
       2021-07-29 11:59:14 +08:00
    @earneet 说的很对,有个细节需要更正,RSA 算法由于 PKCS#1 补丁的关系,单次加密最大数据长度为 117 字节,嘿嘿。
    LLaMA2
        97
    LLaMA2  
       2021-07-29 12:13:55 +08:00
    想要 End to End 的加密,首要解决的是两端交换的密钥确实是他们自己说的密钥,而不是由中间人篡改后的密钥。上面网友说的面对面交换密钥就能保证到。
    wlbyg888
        98
    wlbyg888  
       2021-07-29 13:00:40 +08:00 via Android
    技术早就有了!落地应用,环境不现实
    doveyoung
        99
    doveyoung  
       2021-07-29 13:44:50 +08:00
    怎么说呢,楼主能来 v2,竟然不知道 telegram 吗
    GeruzoniAnsasu
        100
    GeruzoniAnsasu  
       2021-07-29 13:48:21 +08:00
    @lzxz1234

    好家伙,超时空网速
    1  2  
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   1223 人在线   最高记录 6543   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 40ms · UTC 18:05 · PVG 02:05 · LAX 11:05 · JFK 14:05
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.