> For systems with high resolution timers, even if an attacker has totalAround the same time I was working on getting the performance figures for the RNG in the Infineon TPM in the system I had, I tried, however briefly, to concoct a test using netperf and pulling the ITC on an Itanium processor to generate some randomness. I'm not at all sure I was doing things correctly - I was pulling the bottom one to 4 bits of the ITC after each call to recv() of a TCP_RR test - but when I tried to feed the resulting trickle of data through diehard (which I may have been running poorly) it was giving nothing but a p value of 0.000000 which while I don't grok the p-value itself, I understand that consistent value of 0.000000 is bad :( So, I may have had a bad test case. If someone has some suggestions for a better test of the low-order-bits-of-the-interval-timer hypothesis I'd love to hear about them. rick jones -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Greg Kroah-Hartman | [PATCH 002/196] Chinese: rephrase English introduction in HOWTO |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Andrew Morton | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | Re: [AppArmor 39/45] AppArmor: Profile loading and manipulation, pathname matching |
git: | |
| Gerrit Renker | [PATCH 03/37] dccp: List management for new feature negotiation |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jarek Poplawski | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Jarek Poplawski | Re: [BUG] New Kernel Bugs |
