RSA 算法一种常见的非对称加密算法, 经常使用来对一些在网络上传输的敏感信息进行加密, 本文将概述RSA算法的流程以及一种意想不到的"旁门左道"的攻击方式. html
RSA 算法流程以下, java
p
和 q
, 计算 N = p*q
e
, 使得 e
与 (p-1)(q-1)
互质, 此时公钥为 (N, e)
, 告诉给对方d
, 使得 e*d-1
可以被(p-1)(q-1)
整除M
, 加密密文C
为: $C = M^e \mod N$C
, 解密消息 M
: $M= C^d \mod N$RSA算法依赖于欧拉定理, 一个简化版本为大体为 a
和 p
互质, 那么有, linux
$ a^{p-1} \equiv 1 \mod p$, a
的 p-1
次方 对 p
取余为1
, (a
的 p-1
次方减去1
能够整除 p
).算法
欧拉定理的证实比较复杂,原本有一个绝妙的证实方式的, 但因为微信公众号字数有限, 这里就省略了(什么? 这跟费马有什么关系? 实在要看的能够看文末参考资料)编程
举个例子安全
N = pq
, 取俩素数 p=11, q = 3, N = p * q = 33
, 取 e
与 (p-1)(q-1) = 20
互质的数 e = 3
, 而后经过 $ed \equiv 1 \mod (p-1)(q-1)$ 肯定私钥,
即取一个 d
使得 3*d -1
能 20 被整除, 假设取 d=7
或者d=67
. (3*7-1=20
固然能被20整除, 3*67-1=200
也能被20整除)微信
所以 public key 为 (N=33, e=3)
, private key 为 d=7
或者d=67
,
假设加密消息M=8
,
经过加密算法 $C = M^e \mod N$
获得密文 C=8^3 % 33 = 17
cookie
再来看解密, 由$M= C^d \mod N$, 获得明文 M = 17^7 % 33 = 8
或者 M=17^67 % 33=8
, 是否是很神奇? (这里^
表示多少次方, 后文中的有的表示异或)网络
(来, 安利一个计算器的工具, bc
命令, 支持任意精度的计算, 其实 Mac简单的计算就能够经过前面介绍的 Alfred 能够方便得完成)
若是须要破解 RSA 的话, 就是须要找到 p
和 q
, 使得 pq=33
, 若是知道了 p
和 q
就能经过公钥 N
和 e
反推出私钥 d
了. 然而大数分解在历史以来就一直是数学上的难题.
固然上面所述的案例较简单, 当 N 很大时, 就特别困难了. 曾经有人花了五个月时间分解了这个数39505874583265144526419767800614481996020776460304936454139376051579355626529450683609727842468219535093544305870490251995655335710209799226484977949442955603
(159位数), RSA-155 (512 bits) [from wikipedia].
这条路走不通, 就有人走了"旁门左道"了, Stanford 的几个研究者用了两个小时破解了 OpenSSL 0.9.7 的 1024-bit 的 RSA 私钥 (感兴趣的同窗能够看他们的论文Remote Timing Attacks are Practical),
用到的方法就是后面提到的时序攻击(或译为"计时攻击"), 主要思想是由于在进行加密时所进行的模指数运算是一个bit一个bit进行的, 而bit为1所花的运算比bit为0的运算要多不少(耗时久),
所以能够经过获得大量消息与其加密时间, 而后基于统计的方法就能够大体反推出私钥的内容.
计时攻击是边信道攻击(或称"侧信道攻击", Side Channel Attack, 简称SCA) 的一种, 主要是一种利用不一样的输入会有不一样的执行时间这个特色.
举个具体的例子, 这个来自playframewok 里用来验证cookie(session)中的数据是否合法(包含签名的验证), 也是我写这篇文章的由来.
def safeEquals(a: String, b: String) = {
if (a.length != b.length) {
false
} else {
var equal = 0
for (i <- Array.range(0, a.length)) {
equal |= a(i) ^ b(i)
}
equal == 0
}
}复制代码
刚开始看到这段源码感受挺奇怪的, 这个函数的功能是比较两个字符串是否相等, 首先长度不等确定不等, 当即返回这个是能够理解的,
但是后面的代码得发挥下想象力了, 固然这个逻辑仍是好懂: 经过异或操做1^1=0, 1^0=1, 0^0=0
, 若是每一 bit 都相等的话, 两个字符串确定相等, 最后的equal
确定为0, 不然为1.
但从效率角度上讲, 不是应该只要中途发现某一位的结果为1了就能够当即返回 false 了吗? (以下所示)
for (i <- Array.range(0, a.length)) {
if (a(i) ^ b(i) != 0) // or a(i) != b[i]
return false
}复制代码
结合方法名称 safeEquals
可能知道些眉目, 与安全有关, 延迟计算等提升效率的手段见过很多, 但这种延迟返回的仍是不多见.
这种手段可让调用 safeEquals("abcdefghijklmn", "xbcdefghijklmn")
和调用 safeEquals("abcdefghijklmn", "abcdefghijklmn")
的所耗费的时间同样,
防止经过大量的改变输入并经过统计运行时间来暴力破解出要比较的字符串, 这里其实都忽略了对比较字符串长度的attack问题.
举个例子, 假设某个用户设置了密码为 password
, 经过从a到z(实际范围可能更广)不断枚举第一位, 最终统计发现 p0000000
的运行时间比其余从任意a~z
的都短,
这样就能猜想出用户密码的第一位极可能是p
, 而后再不断一位一位迭代下去最终破解出用户的密码. 若是密码经过hash加密后也能经过这种攻击方式获得hash后的密文.
固然, 从理论角度上讲这个确实容易理解, 如上文所提到的学术界已经有论文发表指出用这种计时攻击的方法破解了 OpenSSL 0.9.7 的RSA加密算法了.
然而在实际中是否存在这样的攻击问题呢?
由于好像经过统计运行时间总感受不太靠谱, 这个运行时间对环境太敏感了, 好比网络, 内存, CPU负载等等都会影响.
尽管如此, 各个软件的实现也都采用了这种 safeEquals
的方法.
JDK 1.6.0_17
中的Release Notes中就提到了MessageDigest.isEqual
中的bug的修复
BugId | Category | Subcategory | Description |
---|---|---|---|
6863503 | java | classes_security | SECURITY: MessageDigest.isEqual introduces timing attack vulnerabilities |
此次变动的diff详细信息来源为:
为了防止(特别是与签名/密码验证等相关的操做)被 timing attack, 目前各大语言都提供了响应的安全比较函数, 例如 "世界上最好的编程语言" -- php中的:
// Compares two strings using the same time whether they're equal or not.
// This function should be used to mitigate timing attacks; for instance, when testing crypt() password hashes.
bool hash_equals ( string $known_string , string $user_string )
//This function is safe against timing attacks.
boolean password_verify ( string $password , string $hash )复制代码
各类语言版本的实现方式都与上面的版本差很少, 将两个字符串每一位取出来异或(^
)并用或(|
)保存, 最后经过判断结果是否为0来肯定两个字符串是否相等.
参考资料:
p.s 若是你以为这文章对你有那么一点点收获, 请不要犹豫扫描下面二维码关注个人公众号, 若是你再能帮忙转发一下就更好了. 么么哒.