这是一个创建于 3350 天前的主题，其中的信息可能已经有所发展或是发生改变。
使用 AES 加密传输数据，加解密可以实现，但是有个疑问：
使用 aes 加密的原因就是密文传输，被拦截抓包也没法解密，但是 key ， iv 都是被一起传输过去的，也会被同时拦截下来，这样同样可以破解和明文并没有差距呀。
就算是我 key 是随机的，且单独传输，但是为了保持前后端 key 一致，也是要传输 key 的呀。难道前后端使用一个相同的算法生成 key ，但这样生成 key 算法前端是可见的。
 |
1
Septembers 2015-09-23 08:21:29 +08:00 via Android
1. 请使用 HTTPS
2. 请看《应用密码学》 |
 |
2
c742435 2015-09-23 08:29:13 +08:00
楼主的目的是什么？
|
 |
3
WalkingEraser 2015-09-23 08:32:29 +08:00
具体 JS 还没机会弄过，但密码学中有密钥交换保证 key 的可靠传输
|
 |
5
polandeme OP |
|
6
c742435 2015-09-23 08:37:48 +08:00
@polandeme 你是怕信息被当前用户抓包，还是被中间人抓包？
防中间人直接用 https 可破，防用户的话找个非对称加密算法的库吧。 |
 |
7
gaohongyuan 2015-09-23 08:39:46 +08:00
密钥交换不会直接明文传，有专门算法的，比如 Diffie-Hellman 。想破解就中间人攻击
|
 |
9
ehs2013 2015-09-23 08:44:29 +08:00
无论怎么样，都必须要有个 100% 可信任的东西，就看你信任什么了。
|
 |
10
wy315700 2015-09-23 08:47:11 +08:00 via Android
ECDHE
|
|
11
c742435 2015-09-23 08:48:03 +08:00
@polandeme 对。不过 https 的公钥是从服务器下发的。所以 [用户] 可以通过中间人程序修改公钥 /查看传输的内容（前提是信任中间人的证书）。
|
|
14
polandeme OP @c742435 “不过 https 的公钥是从服务器下发的” ，那这句假如我用现在的这种 aes 方式，每次发送数据之后服务器下发一个新的 key ，这两种方式的区别在于什么。非对称？
|
 |
15
FrankFang128 2015-09-23 08:52:11 +08:00 via Android
看下 HTTPS 的原理呀
|
|
16
polandeme OP @FrankFang128 恩恩，正在看
|
 |
17
yuriko 2015-09-23 09:04:31 +08:00
AES 是对称加密，密钥同时用来加密和解密，一般使用在双方都拥有密钥的前提下。
还有种加密叫非对称加密，比如 RSA 这种，加密和解密用不同的密钥（公钥、私钥），发送方用公钥加密，接收方用对应的私钥解密。 由于非对称加密普遍计算量较大，一般都是先用非对称加密交换对称密钥，然后用对称加密进行通信 |
 |
18
feather12315 2015-09-23 09:12:48 +08:00 via Android
https 验证过程与证书颁发机构通信，确认密钥。
|
 |
19
Ghoul2005 2015-09-23 09:24:53 +08:00 via iPhone
Https 是完整的解决方案，不然的话你得自己实现身份验证，密匙交换，传输加密等多个过程，等于自己把 https 的整套方案实现了一次。
|
 |
20
Marfal 2015-09-23 09:32:25 +08:00
《图解密码学》
没什么数学要求 |
 |
21
mengzhuo 2015-09-23 09:46:09 +08:00
楼上的都说 HTTPS 是解决方案
可楼主并没有说是什么传输方式，所以不应该是 TLS 么 不管什么方式交换密钥，都需要“无条件”信任某个第三方，在 X509 里，就是所谓的 CA 了 |
 |
22
konakona 2015-09-23 10:03:09 +08:00
KEY 和 IV 不应该一起传输，为什么要一起传输我真心没搞明白……哎！
|
|
23
polandeme OP @konakona 不对，应该是传输的知识加密后的数据，但是对于前端层面来说，用户或者中间人还是可以找到 key ，和 iv 的。
|
 |
24
oott123 2015-09-23 10:12:34 +08:00 via Android
AES 对称，再怎么加密也并无卵用…
就算你用 rsa ，你的 http 是明文的，中间人可以拦截你下发的 key ，改成自己的。 Web 安全靠 js 做是不可信的，上 https 吧。 |
 |
25
glasslion 2015-09-23 11:49:01 +08:00
不要重复造轮子，更不要造密码学相关的轮子， LZ 自己去实现一类类似 TLS 的东西， 100%是有漏洞的
https://blog.helong.info/blog/2015/09/06/tls-protocol-analysis-and-crypto-protocol-design/ |
|
26
polandeme OP @glasslion 自己目前只是涉及到应用层的东西，应该不会去早密码学相关的轮子，但是会去了解现有轮子的本质。 thx
|
|
27
glasslion 2015-09-23 13:44:17 +08:00
@polandeme 应用层恰恰是仅次于加密算法实现，第二容易出错的。至于了解现有轮子的本质， 即使是对口专业的，没个十几年经验，也做不到
|
|
29
polandeme OP @yuriko
会有个问题吧，最后一步都是使用 aes 加密传输，所以这个过程中会传输， data, iv ,key 加密之后的数据， key,iv 会在第一次加密过，但是中间人还是可以得到我的 js 文件，也会破解出我的 key,iv 明文，最后会在对称加密过程中破解出信息明文。 感觉这种可能还没有 rsa 直接加密安全或者效率高吧。 或者你的意思是： key ， iv 不在 js 中，是根据用户填写得到的？ 但是无论哪个，还没有直接使用 rsa 效率高的吧。我只是用户名和密码。 |
 |
30
loggerhead 2015-09-24 07:12:08 +08:00 via iPhone
1 由客户端发起通信
2 客户端用非对称加密的公钥加密对称加密的密钥传给服务器，对称加密的密钥每次随机产生 3 用对称加密加密需要传输的数据 |
Select Language