Tag Archives: 随机数

Inter CPU 中 RDRAND and RDSEED的区别

在考虑制作测试真正随机数生成卦的时候,发现有文件指出,RDSEED 和 RDRAND 的区别是 RDRAND 采用的是 128-bit AES 密钥的 CTR-DRBG,而 RDSEED 则是直接从真随机数发生器中获得输出(两者并不是直接使用真随机发生器的输出,这些输出是做过 AES-CBC-MAC 处理的,防止外界通过观测输出了解内部运行的细节) 在Inter的《The Difference Between RDRAND and RDSEED》中指出,两者使用间的区别: “The decision process for which instruction to use is mercifully simple, and based on what the output will be used for. If you wish to seed another pseudorandom number generator (PRNG), use RDSEED For all … 阅读全文 Inter CPU 中 RDRAND and RDSEED的区别

Inter cpu 获取真随机数

Intel在IVB架构的第三代CPU酷睿处理器内置了一个利用电阻热噪声取得硬件真随机数的功能,这里的代码原理就是直接用汇编指令读取16位随机数到aex寄存器。2013年的时候,英国的Kyle Condon在Change.org发起请愿,请求维护者Linus Torvalds为改进内核安全从/dev/random中移除RdRand。因为RdRand是用于生成随机数的一个指令,包含在Intel 64和IA-32指令集架构中,它依赖的一个加密标准是NSA制定的NIST SP800-90,被怀疑存在后门。Linus Torvalds对请愿迅速做出了回应,痛骂了请愿者一顿,称对方太无知。因为在Linux系统中的随机器发生器上/dev/random,会在RdRand的随机数基础上再次进行随机处理,不但能避免出现有后门的情况,同时也可以改进随机数生成的质量。   int rdrand16_step(uint16_t *rand) { unsigned char ok; /* rdrand dx */ __asm { volatile(“.byte 0x0f,0xc7,0xf0; setc %1” : “=a” (*rand), “=qm” (ok) : : “dx” ); } return ok; }   网络上也有包装好的JAVA库,https://github.com/cambecc/drnglib  

由推论出错谈谈梅花易数起卦中的有趣现象

  上篇文章 本以为解决了计算机上以九取模的平均分布问题,但是经过实践,发现这样不但得不到平均分布,得到的反而是正态分布,原因是让两个随机数进行了相加。所以如何让九宫的概率严格平均分布暂时还没有解决。   连续的不同的单概率事件累加,总体上它就会出现正态分布,这个满足中心极限定理。   更通俗一点说,0~8中随机取一个数,这个是平均分布的,但是先在0~4个中取1个,再取0~4中取1个,它们累计的和,却是正态分布的,与直接在0~8中任意取一个数的概率分布并不一样。   这是因为0~8中一共是9个数字,而两次的0~4虽然看起来和还是0~8,实际上却是在两次是在10个数字中取了,于是概率就发生了叠加,这就导致了正态分布的出现。        比如按上述方式先取0~4中一个,然后再取,相加起来看是什么卦,进行1000次,结果会形成这样的分布:        乾 63        兑 112        离 178        震 235        巽 192        坎 124        艮 60        坤 36   那么在起卦中,比如梅花卦中,是否有这样的现象?具体来统计一下。   以报数起卦为例,报两个数字,比如1,2,得到乾与兑卦,然后1+2=3,表示三爻动,这样又产生一个变卦。   通过报数起卦出现的梅花卦,它是符合正态分布的,进行一万次随机报数模拟,因为每次出两个卦,进行随机统计会发现,对主卦来说,有如下的情况: 上卦:乾 1283 兑 1259 离 1216 震 1261 巽 1266 坎 1296 艮 1216 坤 1203 下卦:乾:1245 兑:1244 离:1268 震:1327 巽:1222 坎:1260 … 阅读全文 由推论出错谈谈梅花易数起卦中的有趣现象

解决起卦的九宫的同余的概率分布问题

  无论是采用九宫模拟还是八卦模拟,产生随机数都会遇到一个问题,即在9或8上不能平均分布,比如产生的随机数范围是0~65535,一共65536个数,而6+5+5+3+6 = 25,2+5=7,余下为7,这会导致生成的随机数分布概率并不均等,所以它们无法满足在9的空间上能够平均分布,这是不符合自然现状的。如果是对于8来说,已知65536为2的16次方,而2的15次方是可以被8整除的,所以分布下来就多了2个,同样会导致在8的空间分布上不平均。   有一种思路是取一个足够大的数,把误差降到最低,比如取值范围为2的64次方,那么多出来的2个不平均分布,只占1/264    的比重影响,可以说是微乎极微。   不过这样始终让人感觉不完美,所以为了追求完美,完全可以改进一下。   因为通常用八卦时不一定要用九宫,用九宫时一定要用到八卦,所以这个问题并不难解决。   需要构造出一个方法,让它都能整除,即存在一个数S        S%8=0  S%9=0   并且 S =2N (n=0,1,2,3,4….)   但这个是没有解的,所以是不现实的,那么就把问题改一下:   如果是2某个次方加上一个数满足这个条件的话,那就会大大减低计算量。     于是搜了一下解集,发现如下可以满足条件:        式  次方值   2^6+8  64   2^12+8 4096   2^18+8 262144   2^24+8 16777216   2^30+8 1073741824   2^36+8 68719476736   2^42+8 4398046511104   2^48+8 281474976710656   2^54+8 18014398509481984   2^60+8 1152921504606846976        最小的取值可以是2的6次方,而加上一个8后,64+8=72,它就可以除以9了。   那么这个应该如何进行?计算机是二进制的,这个是非常美妙的事情,因为这意味着它的随机数发生器,无论要表示什么数字,是由低位到高位来表达的。   比如1~8的表达,是000,111这样的数字,而更进一步简化来说,如果只需要取八卦起卦,直接用随机数,取最低三位即可表达(实际表达为0~7)。   如果取1~9来表达,必须要用64+8+72的表达方式,之所以能够这样,是因为计算机是二进制,无论它产生什么样的随机数,表达总是从低位到高位来的,已知72的二进制是1001000,然而按位操作是很难取出来的,所以最好的办法是通过位来取组合值,这样运算不但快,而且能分布均匀,先取出来0~7然后再取出来0~63,然后加起来除以9取余,这样分布就完全一样了。   可以先取最低6位值,然后右移6位,再取三位,把它们相加,这样就能在一个随机数上得到0~72的值。   ------------------   更新一下,以上移位操作取数相加不可行,因为会变成正态分布….         

解决了起卦使用真随机数的问题

  对于灵机起卦的术数来说,要做到术数上的准确预测,先要找到目前不可预测的数据,然后从这个数据才可推出可预测的结果,这是个颇为矛盾的逻辑。   而不可预测的数据,自然是真随机数了,至于真正的随机数到底是存在还是不存在,这个很难说,是个哲学问题,万物虽然都是概率的呈现,但是概率又是什么决定的?   回正题,一开始从淘宝上查有没有硬件的真随机数发生器,可惜万能的淘宝令人失望了,然后检查电脑的CPU是Inter的,Inter的CPU正好提供有真随机数的发生器,于是动念头想直接访问Inter的CPU,查了一下,需要下载Inter的数学库,于是就去慢慢下载。   下完后竟然发现不能运行,因为版本太老不支持XCode6,所以竟然连安装都不让安装,只好放弃。   于是又查有没有其它办法可以通过这种方式获取随机数,花了许久,运气不错发现篇文章表示Inter提供直接使用汇编指令来访问CPU。   然后麻烦就来了,这个是MAC的系统,编译出来是dylib库,然后尝试通过mono去调用,无论如何也提示调用不了,找不到文件。然后又继续翻网站,终于发现,原来编译时,只能编译成32位的,这样Mono才能调用,来回折腾了几次后,成功实现真随机数的调用了。   不得不说,国内的资料实在不好查,还是英文网站上的资料比较全一些,虽然折腾了一个晚上,但还是值得的,能够实现真随机数的调用,能够解决很多问题。   产生的真随机数图如下:      而相同绘图算法C#生成随机数如下:      比较奇怪的是,差异并不是很明显,是MAC底层的随机数算法做得极好的缘故?所以近似于真实随机数的效果了?   不过想来伪随机数与真随机数还是会有差别,这个需要用大量的卦例进一步检验了。      其它还有一些真随机数的生成办法,不过没有实现,这里也提一下:   在IPAD或是IPhone或是Android机上,是没有CPU能够支持随机数的,要做到能在这些上面更准确的起卦,尤其是梅花卦,应该考虑如下方案来生成熵池起卦:   1、通过访问重力感应,求测者随意摇晃手机,从中搜集精确的数据用来起卦,类似于真实的摇签或摇卦,据在下所知,现在还没有真正如此来实现的,大多的摇晃起卦,实际上是早就用伪随机数起好了,然后摇晃只是发个声而已。   2、求测者随意在屏幕上乱点乱划,然后搜集数据来综合起卦,这样得到的卦测算起来就更加方便,不过这种效果直觉上有略有折扣。   3、打开麦克风,通过麦克风搜集实际的噪音,动态调整振幅后,随机采集数据。这个还可以更加改进,让求测者念一句话,因为发音总有变化,通过提取变化,可以得到真实随机的采样。     4、对使用者用摄像头拍照,根据照片的色彩矩阵做一个运算,从而得到卦,这种起卦方式应该是比较灵验的,顺便还能让卦师结合面相也一起看了,不过有影响隐私的嫌疑。     以上四种起卦方式,可以在移动设备上进行。

计算机伪随机数会对起卦准确率造成影响

  计算机上的随机数是伪随机,它要么是固定的序列,要么是利用当前的时间来生成的一个随机器。测试了一下MONO在MAC上调用的随机器发生器:让它随机产生坐标,然后标记成白点,产生的结果如下:    如果是在Windows上,使用C#进行生成的300×300的随机图像值是这样:   然而,如果是根据真实的自然环境,由大气的运动(空气中的雷暴产生的噪声)而自然产生随机数应该是这样:   明显可以看出,在MAC上的mono的C#中代码所产生的随机数所形成的密度远远低于真实的随机数,不过唯一值得庆幸的是,如果见到php的随机数生成的样子是多么糟糕,就会更有感触了:    随机数的正确与否,直接关系到起卦的关联性,因为计算机上使用的虽然普遍是伪随机数,但是来的人时间却是不一定的,这样就在一定程度上模拟了随机,但是在出现生成随机比较紧密的时候,它对自然的模拟所体现出来的随机真实度就会大大降低。   术数最讲究的就是对自然的模拟,如果不能进行一个真实的模拟,也就谈不上预测。   典型的一种表现就是,在网上起卦,比如六爻卦,或随机梅花卦,其准确率都会降低,如果是手起摇的卦,大多看事一目了然,看是什么就是什么,但是换成网络起卦后,会出现信息不同程度偏移(注意是不同程度的,有时小有时大)。   信息偏移,比如看是收获当为一万块,网络用卦结果发现只有五千或八千,本来手卦经验很准的数,在网上起卦也就产生了模糊偏差。这就是因为同样的随机数发生器被频繁使用,而导致了整体上的真实度降低。   虽然大多数时候还是可以看事,也多能断得准,但其中难免会有不同程度的信息失真,准的时候就如同上面的点与自然随机点的分布密集恰好重合,不准的时候就是不符合真实随机的时候。   自然的随机性,正如清澈的海边,尽管水一直在波动,但并不会影响人通过清晰地看到水下的鱼。现在网上起卦的,从上面的自然分布来看,很容易明白,信息失真最大的便是php的网站,因为它用的随机数的分布可以说最不自然,所以在起卦上相对也就更加不准。   其次是asp,asp.net等网站,它们的随机数发生器,调用的是相同的低层,生成的随机数模拟度显然比真实的要淡得多,信息也有一定程度的失真。   要成功使用真正有效的随机器,有不少的办法,一种是动态监测系统运行状况或者其它方面搜集信息,然后汇总信息构成随机数生成器,这样产生的随机数值会更加准确,或者直接使用硬件通过USB接口之类的来传送信息,或者如果是使用的Inter的CPU的话,可以直接调用CPU的接口来生成随机数。   如此使用了真随机数,起卦才能有所保证。