{"success":true,"code":0,"msg":"","data":{"themeEx":{"tid":542,"replies":0,"views":4212,"searchs":0,"topGmtUpdate":null,"top":false},"theme":{"id":542,"title":"JVM上的随机数与熵池策略","content":"
在apache-tomcat官方文档:如何让tomcat启动更快 里面提到了一些启动时的优化项,其中一项是关于随机数生成时,采用的“熵源”(entropy source)的策略。
他提到tomcat7的session id的生成主要通过java.security.SecureRandom生成随机数来实现,随机数算法使用的是”SHA1PRNG”
private String secureRandomAlgorithm = "SHA1PRNG";
在sun/oracle的jdk里,这个算法的提供者在底层依赖到操作系统提供的随机数据,在linux上,与之相关的是/dev/random和/dev/urandom,对于这两个设备块的描述以前也见过讨论随机数的文章,wiki中有比较详细的描述,摘抄过来,先看/dev/random :
在读取时,/dev/random设备会返回小于熵池噪声总数的随机字节。/dev/random可生成高随机性的公钥或一次性密码本。若熵池空了,对/dev/random的读操作将会被阻塞,直到收集到了足够的环境噪声为止
而 /dev/urandom 则是一个非阻塞的发生器:
dev/random的一个副本是/dev/urandom (”unlocked”,非阻塞的随机数发生器),它会重复使用熵池中的数据以产生伪随机数据。这表示对/dev/urandom的读取操作不会产生阻塞,但其输出的熵可能小于/dev/random的。它可以作为生成较低强度密码的伪随机数生成器,不建议用于生成高强度长期密码。
另外wiki里也提到了为什么linux内核里的随机数生成器采用SHA1散列算法而非加密算法,是为了避开法律风险(密码出口限制)。
回到tomcat文档里的建议,采用非阻塞的熵源(entropy source),通过java系统属性来设置:
-Djava.security.egd=file:/dev/./urandom
这个系统属性egd表示熵收集守护进程(entropy gathering daemon),但这里值为何要在dev和random之间加一个点呢?是因为一个jdk的bug,在这个bug的连接里有人反馈及时对 securerandom.source 设置为 /dev/urandom 它也仍然使用的 /dev/random,有人提供了变通的解决方法,其中一个变通的做法是对securerandom.source设置为 /dev/./urandom 才行。也有人评论说这个不是bug,是有意为之。
我看了一下我当前所用的jdk7的java.security文件里,配置里仍使用的是/dev/urandom:
#\n# Select the source of seed data for SecureRandom. By default an\n# attempt is made to use the entropy gathering device specified by\n# the securerandom.source property. If an exception occurs when\n# accessing the URL then the traditional system/thread activity\n# algorithm is used.\n#\n# On Solaris and Linux systems, if file:/dev/urandom is specified and it\n# exists, a special SecureRandom implementation is activated by default.\n# This "NativePRNG" reads random bytes directly from /dev/urandom.\n#\n# On Windows systems, the URLs file:/dev/random and file:/dev/urandom\n# enables use of the Microsoft CryptoAPI seed functionality.\n#\nsecurerandom.source=file:/dev/urandom
我不确定jdk7里,这个 /dev/urandom 也同那个bug报告里所说的等同于 /dev/random;要使用非阻塞的熵池,这里还是要修改为/dev/./urandom 呢,还是jdk7已经修复了这个问题,就是同注释里的意思,只好验证一下。
使用bug报告里给出的代码:
import java.security.SecureRandom;\nclass JRand {\n public static void main(String args[]) throws Exception {\n System.out.println("Ok: " +\n SecureRandom.getInstance("SHA1PRNG").nextLong());\n }\n}
然后设置不同的系统属性来验证,先是在我的mac上:
% time java -Djava.security.egd=file:/dev/urandom JRand\nOk: 8609191756834777000\njava -Djava.security.egd=file:/dev/urandom JRand \n0.11s user 0.03s system 115% cpu 0.117 total\n\n% time java -Djava.security.egd=file:/dev/./urandom JRand\nOk: -3573266464480299009\njava -Djava.security.egd=file:/dev/./urandom JRand \n0.11s user 0.03s system 116% cpu 0.116 total
可以看到/dev/urandom和 /dev/./urandom 的执行时间差不多,有点纳闷,再仔细看一下wiki里说的:
FreeBSD操作系统实现了256位的Yarrow算法变体,以提供伪随机数流。与Linux的/dev/random不同,FreeBSD的/dev/random不会产生阻塞,与Linux的/dev/urandom相似,提供了密码学安全的伪随机数发生器,而不是基于熵池。而FreeBSD的/dev/urandom则只是简单的链接到了/dev/random。
尽管在我的mac上/dev/urandom并不是/dev/random的链接,但mac与bsd内核应该是相近的,/dev/random也是非阻塞的,/dev/urandom是用来兼容linux系统的,这两个随机数生成器的行为是一致的。参考这里。
然后再到一台ubuntu系统上测试:
% time java -Djava.security.egd=file:/dev/urandom JRand\nOk: 6677107889555365492\njava -Djava.security.egd=file:/dev/urandom JRand \n0.14s user 0.02s system 9% cpu 1.661 total\n\n% time java -Djava.security.egd=file:/dev/./urandom JRand\nOk: 5008413661952823775\njava -Djava.security.egd=file:/dev/./urandom JRand \n0.12s user 0.02s system 99% cpu 0.145 total
这回差异就完全体现出来了,阻塞模式的熵池耗时用了1.6秒,而非阻塞模式则只用了0.14秒,差了一个数量级,当然代价是转换为对cpu的开销了。
#补充,连续在ubuntu上测试几次/dev/random方式之后,导致熵池被用空,被阻塞了60秒左右。应用服务器端要避免这种方式。
转载自并发编程网 – ifeve.com本文链接地址: JVM上的随机数与熵池策略
------------------------------转载补充-----------------------------------
不知道为什么Tomcat8中仍然使用的是/dev/random的方式来获取随机数,导致有时候启动会卡上几分钟(参考:解决Tomcat8以后的版本,Tomcat启动缓慢的问题)。
","contentView":"在apache-tomcat官方文档:如何让tomcat启动更快里面提到了一些启动时的优化项,其中一项是关于随机数生成时,采用的“熵源”(entropy source)的策略。他提到tomcat7的session id的生成主要通过java.security.SecureRandom生成随机数来实现,随机数算法使用的是”SHA1PRNG”privateStringsecureRandomAlgor","author":"幻幻Fate","authorId":1,"fid":16,"forumName":"Linux运维","reprint":true,"status":2,"statusName":"已发布","tags":"熵池,entropy pool","tagList":["熵池","entropy pool"],"imgList":"","topImg":null,"url":"https://www.reinforce.cn/t/542.html","imgs":[],"css":"","js":"","publishTime":1487845907000,"timeForRead":"2017年02月","gmtCreate":null,"gmtModified":1545200860000,"replies":0,"views":4207,"searchs":0,"top":false}}}