AES和ECC的混合加密
2016-10-17 00:00
627 查看
在上面对AES加密的初步认知中,我们知道AES加密需要一个key,加减密双方都需要知道,那这个key怎么设定好?看一下下面的一种场景:
在社交的APP中,一般对聊天内容都会是加密的,A和B聊天,A和C聊天。如果这个Key都是固定的,那么是不是意味着:如果B通过蛮力等方法破解某段聊天信息,拿到了和A之间的AES_Key,再抓包劫持了A和C的传输内容,就可以轻易的破解A和C之间的内容,显然这种做法是不安全的。
所以安全的模式是A和B,A和C,B和C, 他们聊天内容加密的key都是不同的(再安全点加密方式也可以有区别)。那样即使A和B的加密被破解了,A和C,B和C等其他的聊天记录都不会被轻易破解。
那怎么传送这个key,肯定不是明文传送,那用哪一种加密方式更好点,一般都是非对称加密,如RSA、ECC等。
非对称加密:加减密的密钥不同,分私钥和公钥。
主流的非对称加密方式如:RSA和ECC
这边为什么选用ECC,客观因素有很多:
密钥位数短,一般认为160位密钥的ecc安全性相当于1024位密钥的rsa,256位相当于3072位。
ECC虽然算法复杂但位数短很多,所以ECC性能高于RSA,安全性也相对高很多,ECC逐渐成为主流了。
...... 还有很多
AES的Key经过接收方公钥加密和AES加密的内容 一起发送给接收方,接收方通过自己私钥先将加密后的AES_KEY解密,再通过解密得到的原始AES_KEY,并用该key解密发送方发送的内容,得到明文。
如下图所示:
![](http://upload-images.jianshu.io/upload_images/2906485-0d85d7dbfdf47646.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
上面这种加密方式性能上绝对是杠杠的,虽然自己没有用具体的数据测试过,但也找过很多资料看了,加密算法速度高于
扩展:AES和ECC的混合加密还有一种特殊的场景,先来看一下ECC 数学函数 Q=dG; (Q是公钥 d是私钥 G是他们之间的关系);Q1 = d1G1; Q2=d2G2;那么能推出 key=Q1d2G2 = Q2d1G1;
有没有亮点 1的公钥和2的私钥 2的公钥和1的私钥 他们能得到一个相同的值 key。那么我们能不能把这个相同的key 作为他们之间AES加减密的key呢?
那我们是不是可以在这个发送过程少传一个AES密钥key‘的参数,那在传输的过程透露的信息是不是有可以少,安全性是不是会高一点呢?
32位的ECC加密 和32位AES解密,经实践可以使用上述方法。
在社交的APP中,一般对聊天内容都会是加密的,A和B聊天,A和C聊天。如果这个Key都是固定的,那么是不是意味着:如果B通过蛮力等方法破解某段聊天信息,拿到了和A之间的AES_Key,再抓包劫持了A和C的传输内容,就可以轻易的破解A和C之间的内容,显然这种做法是不安全的。
所以安全的模式是A和B,A和C,B和C, 他们聊天内容加密的key都是不同的(再安全点加密方式也可以有区别)。那样即使A和B的加密被破解了,A和C,B和C等其他的聊天记录都不会被轻易破解。
那怎么传送这个key,肯定不是明文传送,那用哪一种加密方式更好点,一般都是非对称加密,如RSA、ECC等。
非对称加密:加减密的密钥不同,分私钥和公钥。
主流的非对称加密方式如:RSA和ECC
这边为什么选用ECC,客观因素有很多:
密钥位数短,一般认为160位密钥的ecc安全性相当于1024位密钥的rsa,256位相当于3072位。
ECC虽然算法复杂但位数短很多,所以ECC性能高于RSA,安全性也相对高很多,ECC逐渐成为主流了。
...... 还有很多
AES的Key经过接收方公钥加密和AES加密的内容 一起发送给接收方,接收方通过自己私钥先将加密后的AES_KEY解密,再通过解密得到的原始AES_KEY,并用该key解密发送方发送的内容,得到明文。
如下图所示:
![](http://upload-images.jianshu.io/upload_images/2906485-0d85d7dbfdf47646.png?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
上面这种加密方式性能上绝对是杠杠的,虽然自己没有用具体的数据测试过,但也找过很多资料看了,加密算法速度高于
扩展:AES和ECC的混合加密还有一种特殊的场景,先来看一下ECC 数学函数 Q=dG; (Q是公钥 d是私钥 G是他们之间的关系);Q1 = d1G1; Q2=d2G2;那么能推出 key=Q1d2G2 = Q2d1G1;
有没有亮点 1的公钥和2的私钥 2的公钥和1的私钥 他们能得到一个相同的值 key。那么我们能不能把这个相同的key 作为他们之间AES加减密的key呢?
那我们是不是可以在这个发送过程少传一个AES密钥key‘的参数,那在传输的过程透露的信息是不是有可以少,安全性是不是会高一点呢?
32位的ECC加密 和32位AES解密,经实践可以使用上述方法。
相关文章推荐
- 典型的网络接口安全机制,AES和RSA混合加密
- AES加密中列混合的具体算法
- Android接口安全 - RSA+AES混合加密方案
- java实现双向ECC + AES加密
- Android AES和RSA混合加密工具类实现
- Android接口安全 - RSA+AES混合加密方案
- Android接口安全 - RSA+AES混合加密方案
- AES五种加密模式(CBC、ECB、CTR、OCF、CFB)【转】
- JAVA 实现AES加密的两种方法
- Symantec 研发的 ECC加密 SSL能否成功
- JAVA的对称加密算法AES——加密和解密
- JAVA AES加密 对应的 C# 方法
- AES 加密
- java实现AES加密(解决中文解密后乱码问题,解决传输字符串后解密报错的问题)
- iOS移动端使用AES加密注意事项
- AES加密解密——AES在JavaWeb项目中前台JS加密,后台Java解密的使用
- python3.6 实现AES加密、解密(改版)
- 7、Android AES加密
- C#对接JAVA系统遇到的AES加密坑
- Python AES加密实例解析