其实是最近一段时间因项目需求而看了各种资料的一堆大杂烩,没怎么排版
非对称加密算法:RSA
对称加密算法:DES,AES等
散列算法:MD5等
DES算法使用相关:
加密模式:
EBC模式:电子密码本模式
CBC模式:密文分组链接方式
具体可参考:加密模式
总结来说就是java只支持EBC模式,c#支持CBC模式
填充模式:
PKCS7Padding:填充 0
PKCS5Padding:填充 8-size%8
NoPadding:不填充
总结来说 java不支持PKCS7Padding,使用时候需要注意
非对称加密和对称加密区别:
对称加密:双方用协商好的密钥加密解密数据
非对称加密:一个公共密钥(任何人都可以获取),一个私有密钥,公共密钥加密的数据只有私有密钥能解密(别人就算截获了数据也无法解密),私有密钥加密的数据虽然任何人(拥有公钥)都可以解密,那有什么用呢?主要是配合散列算法来生成数字签名
MD5:将一段任意长的数据用一段很短的数据(32个字节,128bit)表示。什么意思呢?就是任何事物(数据)都可以用32字节表示,也就是用有限的东西表示无限的东西。听起来是不是不可能,是的,确实不可能,肯定会有冲突,那有什么用呢?这里要理解一种思想:虽然肯定有冲突,但是在一定范围内(时间,空间),2段不同数据冲突(产生的32位数据相同)的可能性几乎为0。
数字签名:
作用:用来确保内容没有被其他人篡改过
原理:利用MD5取得内容的散列值,然后用RSA私钥加密该散列值,一起发给客户,客户使用公钥解密散列,然后计算内容的MD5与解密内容比对,如果一致则证明内容没有被修改过。
前提:客户使用的公钥是真正的公钥(公钥是可信的),一般可通过特殊途径确保
攻击类型:
1.短消息攻击(加密随机数)
在加密过程中,如果我已知加解密双方的明文空间是四个字节的字符串,那我就可以通过观察明文对应的密文把所有的对应关系枚举出来,不需要密钥我就能知道这个密文对应的明文了。
那怎么办呢?只要同样的明文每次密文都不一样,就没法实现这种攻击了
如何实现呢?加密的时候,一般需要在明文上填充一部分随机数,这样每次产生的密文都不一样,这个过程称为padding,而且加密标准里有各种类型的padding标准,比如PCKS1。
原始明文 -> padding后明文 -> 密文 -> padding后明文 -> 原始明文
参考内容:http://nxlhero.blog.51cto.com/962631/1832127
2.时序攻击
参考内容: http://nxlhero.blog.51cto.com/962631/1832127
注意事项:
1.RSA算法是非常耗时的,一般只用来加密密钥或散列(比如数字签名原理).
2.MD5不是加密算法
3.rsa key长度变2倍(double),相应的解密时间会增加6-7倍
4.RSA和DES使用场景:一般都是先用RSA传递对称加密的密钥(因为RSA不适合加密解密大数据)然后用DES加密解密数据
应用畅想:
1.短信接口防攻击
一般注册短信接口都是不绑定用户信息的,且接口都是公开的,有时候容易被一些好事者攻击,导致短时间内发送了大量垃圾短信。
1.增加验证码,这个能从根本上解决问题,目前大量网站也是这么做的。
2.简单的双向对称加密:服务器和APP都存放一个对称密钥,将发送号码加密发给服务器,这种方法能减少菜鸟级攻击,只要密钥保存隐蔽点就可以了(iOS一般不用担心,Android可以使用jni,将密钥放到c文件中)
3.RSA防范手法:客户端发生短信前先请求一段随机数据,该数据服务器用私钥加密后发给客户端,客户端用公钥解密后和短信接口其他数据一起发给服务器。这种方法是利用RSA解密时间远大于加密时间,攻击者就算获取了公钥,每次解密随机数据都要花费很多时间,从而有效减少攻击频率且大量消耗攻击者资源(毒虾政策)。
除了这些之外,还可以限制IP,手机号码等,结合使用来缓解(无法根本解决)
2.核心交互加密
双向RSA,证书通过私下约定保存,这样保证了:接收方能确认发送方的身份,发送方也能确认接受方的身份。然后利用对称加密保证数据安全。
总的来说就是:
第一步:互相确认对方的身份,安全的交换对称密钥
第二步:利用对称密钥保证数据安全