SSL 加密通讯与手动调用 AES 库对数据加密通讯有什么区别?

2017-02-14 12:59:41 +08:00
 fyyz
有加密传输数据的需求,看了下很多都是使用 SSL 库来实现的,如果我不用 SSL ,而是通过调用诸如 Crypto 这些库加密通讯,有什么区别啊?
PS :我这里是 TCP 通讯,有自己设计数据包格式,而不是 HTTP 通讯。
3546 次点击
所在节点    程序员
24 条回复
mnzlichunyu
2017-02-14 13:15:34 +08:00
如果手动调用 AES 库加密通讯的话, 那你应该还要实现秘钥交换协议,数字签名等等。 实现秘钥交换协议的时候,比如 DH 秘钥交换协议,你还需要实现一些算法,比如生成大素数(64bit 以上)的算法,快速求幂算法等等。我对密码学也不是特别了解,不过感觉自己写的话工作量不小, 安全性也不一定好。
fyyz
2017-02-14 13:20:18 +08:00
@mnzlichunyu 如果我直接把密钥给另一个人,使用客户端前需要提前设置才能通信呢?比如说像 s h a d o w s o c k s 这样的。
noli
2017-02-14 13:26:19 +08:00
SSL 通讯加密,可以在发起链接时通讯双方协商密钥,且保证未获许可的第三方试图攻破密钥是计算上不可能的。

你说的 AES 自行对通讯保文加密通讯,如果没有理解错的话,应该是指通讯双方事先已经知道共享的通讯密钥。在多次通讯中,这个密钥除非同时改变,否则双方无法通讯。
一般来说,这样的通讯方式会有以下问题:
1. 无法知道中间是否有第三者已经攻破密钥并截获通讯双方的内容,发起中间人攻击。
2. 更换密钥代价大,必须借助其他安全的信道更新密钥(例如通讯双方同时更新软件)
3. 多次使用同一密钥会使该密钥被攻破的可能性大大增加,尤其是通讯协议是有模式的,可以通过字典攻击倒推出密钥原文。
firefox12
2017-02-14 13:36:01 +08:00
@noli 错了 使用 aes 传输同样的数据多次 也不会增加被破解的风险,这是又有初始向量决定的。
jimzhong
2017-02-14 13:43:34 +08:00
AES 是一种对称块加密算法。 TLS 是一个协议。 TLS 的上层协议不需要是 HTTP ,只要 TCP 能承载的 TLS 一般都可以。 shadows 不使用 TLS 的原因是 TLS 握手时证书是明文传输的,容易被识别且开销较大。
ipoh
2017-02-14 13:50:52 +08:00
手动调用的方法一般是
先用 RSA 交换 AES 密钥,之后用 AES 加密通信。
Ahri
2017-02-14 13:56:38 +08:00
总结一下就是从 cipher 到 cryptographic protocol 中间还有很多很多步。
enenaaa
2017-02-14 13:58:23 +08:00
没问题, 就像 @ipoh 说的那样先用 RSA 传输对称密钥。 至于防范中间人攻击, 参考 ssl 的校验方法。
事实上私有协议好多也是自行加密的。
CRVV
2017-02-14 14:17:48 +08:00
1. 楼主没说数据包格式要设计成什么样的,如果你把所有东西都设计得和 TLS 一样,那就没有区别
2. SSL 加上 TLS 有 6 个版本,修了不少漏洞,自己设计一个又有很多漏洞要修
3. 事先共享密钥的方法不能提供前向安全性, 用 RSA 交换密钥也不行
4. 这些东西看看维基百科就都知道了

简单来说,如果对安全性要求高,肯定不会自己手写加密的过程,这玩意太复杂了
noli
2017-02-14 14:18:40 +08:00
@firefox12 如果你说的是 AES 针对选择文本攻击的抵抗能力,这个我是理解的。

现在我们假设 LZ 的软件只采用一种特定模式的 AES 加密,并且已经分发到了足够多的网络节点上,然后我们在通讯旁路截取数据。

我们分析这些截取数据可以找到什么规律?
如果 LZ 仅仅做了 AES 加密的话,基本上我们可以分析出节点通讯的模式。
譬如是否有类似 Hello 报文,如何响应,
然后我们可以用重放这些报文,试图更改其中一些内容来验证一下对报文内容的猜测。

你还觉得这种方式不会泄密么?
damean
2017-02-14 14:22:03 +08:00
@firefox12 不仅有初始向量,切片填充的时候还会填充随机串,使得每次加密的结果都不一样。字典倒推是不大现实了。
damean
2017-02-14 14:22:56 +08:00
@noli 不行的,你相同的文本用 AES 加密每次都出不一样的密文。
noli
2017-02-14 14:37:33 +08:00
@damean

给定密钥, IV ,和同一种模式, AES 怎么可能加密出不一样的密文?
你让解密方怎么解?
firefox12
2017-02-14 14:45:09 +08:00
@noli iv 不是固定的,你实践一下就懂了。
noli
2017-02-14 14:47:25 +08:00
@damean 来个实例验证吧。

AES256 CFB

明文:
Veni, vidi, vici
密钥:
ThePhantomOfTheOperaIsThere
IV :
8c 8a 88 6c 24 e7 18 a1 91 7c 20 c4 f8 3e d2 5c
结果:
07 22 ff c3 .....

其他不变,明文换成:
Very good
结果
07 22 e3 cb ....

注意到重复的 07 22 了吗?

开头的这一部分,是绝对可以分析的。
如果恰巧知道报文的前面几字节是例如报文长度这样的信息,是有可能逐步攻破的。
noli
2017-02-14 14:50:01 +08:00
@firefox12

IV 在实践中的确是不固定的,但通讯双方也需要明文交换 IV 。
所以你总是有办法让 IV 变成固定的。
xvx
2017-02-14 14:51:51 +08:00
@damean 我记得 AES 有三种加密模式,有一种貌似相同的文本每次加密都得出同样的报文,不知是否记错了。
majinjing3
2017-02-14 15:05:42 +08:00
直接用 ssl 来通讯,是没有问题的啊,并不一定是 http 协议, ssl 只是承载数据而已,
firefox12
2017-02-14 15:05:44 +08:00
@noli 你每个消息都可以带不同的 iv , 你直接把 iv 发给对方就可以了,让监听的人根据 iv 去破解啊
noli
2017-02-14 15:12:56 +08:00
@firefox12 但实际情况是,中间人不仅仅是监听人,它也可以主动发起通讯啊。
所以这种情况下,除非设计协议的时候有考虑 IV 部分,不然中间人可以一直用 同一个 IV 来玩啊

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

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

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX