Re: [cryptography] RDRAND not really random with Oracle Studio 12.3 + patches
On 6/10/2016 4:50 PM, Jeffrey Walton wrote: Ouch... just came across this... https://community.oracle.com/thread/2565486?start=0=0 I did not think it was possible to foul the hardware generated random numbers (sans an occasional underflow). Jeff ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography While the code doesn't follow the SDG guidelines (I.E. it doesn't check for the return status and it doesn't check for the instruction support) it should work because RdRand doesn't underflow in any of our chips. Is this running in a VM or on bare metal? A VM intercept could cause it to happen. Also if you did get an underflow the resulting value passed to the pointed to location would be 0. I tried compiling that code on an Ivy Bridge machine running Linux, but it failed to compile.. >gcc rdrand.c -o rdrand rdrand.c:1:29: fatal error: sys/immintrin.h: No such file or directory compilation terminated. So I pointed the header to the right place and spend an eternity finding I needed the -mrdrnd target to make the intrinsic happy. #include --> #include >gcc -mrdrnd rdrand.c -o rdrand and of course it worked.. (also check out this fine example of Benford's law resulting from the base change to decimal) >./rdrand 475481558559191 2755117154251474975 505373898659232 2936332874890231466 40031155219550810170037297392088344 5444198658298712501565610254954363 51634134984250917357073879924565963 590681088061637 3243797942283965136 25115120681109013419374814453446609 5749168502354613986067242084897708 36940183930318017932264519825487916 207411220949897 4022801322442653892 So it must be some sort of compiler bug or VM problem. We work with many vendors to make sure the RdRand and RdSeed support is done correctly and securely. So I'd like to make sure this is resolved. DJ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] How far are we from quantum cryptography?
On 1/25/15, 9:34 PM, Watson Ladd wrote: No, D-wave didn't make a quantum computer capable of running Shor's algorithm. It's unclear if D-wave's device even works, and there are certain theoretical reasons to suspect it didn't. See http://www.scottaaronson.com/blog/?p=1400 for actual people who know things saying things. I have this suspicion that since you have to make your qbits colder to get more of them to remain entangled, and cooling one part of space requires that you warm some other, under the laws of thermodynamics, then maybe it can be shown the the energy needed to spend to get those qbits cold enough to run Shor's algorithm over n bits is equal to or greater than the energy necessary to perform the equivalent operations in serial in a normal computer. This would be a useful finding in information theory and cryptography if it was true. Sadly I lack the mathematical skills to show or refute this. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Stealthy Dopant-Level Hardware Trojans
Thank you. I like this paper, because its tied into the world of real semiconductor processing and diagnostic machines. The understanding of defenses and attacks against silicon requires an understanding of the capability of these machines and their use. What makes passive voltage contrast imaging good for detecting Becker style trojans is also what makes it a tool for side channel analysis and so as with other areas of hardware crypto engineering, knowing the tools of the enemy is a prerequisite to knowing what defenses are effective and what defenses are not. DJ On 7/1/14, 5:31 PM, Tony Arcieri wrote: This went to the cypherpunks list, but not to the others: http://eprint.iacr.org/2014/508 Reversing stealthy dopant level trojans! ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] TrueCrypt
On 5/28/14, 11:16 PM, Lukasz Biegaj wrote: W dniu 28.05.2014 22:35, Sadiq Saif pisze: http://truecrypt.sourceforge.net/ https://gist.github.com/anonymous/e5791d5703325b9cf6d1 https://twitter.com/matthew_d_green So WTF happened? The same thing that happened with Lavabit. Someone needs to fork the code (the version prior to the most recent change), address the issues raised in the recent audit and host it outside the jurisdiction of the US government, using fresh signing keys. Letting the government crush all the effective security software and services with NSL letters would be a win for the forces of evil in the government. Enabling those things to continue would benefit everyone. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generation being influenced - rumors
On 9/9/2013 5:12 AM, James A. Donald wrote: On 2013-09-09 3:18 PM, Greg Rose wrote: I actually hate to point this out, but having access to something that looks like a raw entropy source proves nothing. A genuine hardware noise source will show colored noise, which is very hard to simulate in software, and especially hard to simulate at any reasonable speed. It's not 'very hard'. Just suppress long strings a bit. If the entropy source is real, it will show its analog characteristics leaking into the digital abstraction. The correlations and anti correlations between nearby bits will reflect the analog values of the circuit, thus no two chips will show quite the same correlations, and the correlations will vary with temperature and overclocking. These analog variations would be compelling evidence that the entropy source is the claimed circuit or something very like the claimed circuit. Just because the entropy source is real doesn't mean it's feeding the conditioner. Any Intel misconduct would show up in the color of the noise, it being very hard to create a digital pseudo noise source that displays subtly varying color at high speed, while hardware true random noise sources almost unavoidably display subtly varying noise color.) So this is both wrong and moot. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] urandom vs random
On 8/20/2013 2:33 PM, grarpamp wrote: The subject thread is covering a lot about OS implementations and RNG various sources. But what are the short list of open source tools we should be using to actually test and evaluate the resulting number streams? ___ I like the Markov-Renye test described in the current SP800-90B draft. It handles biased, correlated, non stationary data conservatively and gives you a min-entropy estimate. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] what has the NSA broken?
On 9/6/2013 6:58 AM, Ralph Holz wrote: Hi, On 09/06/2013 07:12 AM, James A. Donald wrote: Most private keys are issued by, not merely certified by, the CAs. Can you give numerical evidence for this claim? Device certificates (those that go into mass manufactured products) typically have the CA provide both keys and cert. The back and forth of keygen-CSR-Sign-Return per product does not fit in the mindset of a manufacturer. I suspect this is more certs than all the web site certs put together. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Random number generation influenced, HW RNG
On 9/6/2013 2:03 PM, grarpamp wrote: Does anyone put any stock into the rumors floating lately that the government may have influenced Intel and/or AMD into altering However, I claim that the fear is well founded and should be taken into account by all threat models. It interesting to consider the possibilities of corruption and deception that may exist in product design. It's a lot more alarming when it's your own design that is being accused of having been backdoored. Claiming the NSA colluded with intel to backdoor RdRand is also to accuse me personally of having colluded with the NSA in producing a subverted design. I did not. A quick googling revealed many such instances of statements to this effect, strewn across the internet, based on inferences from the Snowden leaks and resulting Guardian and NYT articles. I personally know it not to be true and from my perspective, the effort we went to improve computer security by making secure random numbers available and ubiquitous in a low attack-surface model is now being undermined by speculation that would lead people to use less available, less secure RNGs. This I expect would serve the needs of the NSA well. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
On 7/19/2013 5:44 AM, Peter Gutmann wrote: Eugen Leitl eu...@leitl.org quotes: Just came accross this article, apparently showing the bad quality of the hardware RNG in Raspberri Pi devices. http://scruss.com/blog/2013/06/07/well-that-was-unexpected-the-raspberry-pis-hardware-random-number-generator/ That shows the bad quality of RANDU. It shows that the Pi randomness source seems OK, at least as determined by rngtest. But I haven't seen anything from the manufacturer to state how OK the randomness source is. A conservative model for min-entropy based on the circuit structure would be a start. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
On 7/19/2013 10:13 AM, Mahrud S wrote: Isn't the thermal noise a good enough entropy source? I mean, it's a $25 computer, you can't expect much of it. Directly sampled thermal noise entropy sources have proven: 1) Difficult to model mathematically to determine safe value for min entropy. 2) Difficult to determine will work constantly across all environmental conditions and the lifetime of the device 3) Difficult to self test in circuit Three independent sources is a lot more convenient because you can then use a 3 input extractor such as the BIW 3 input extractor which is beautifully simple in HW and permits constant time implementations in SW. However it does require that you know the min entropy in order to know the min entropy of the resulting number. It's good for toy noise sources because you can assume a really low min-entropy, iterate a few times and have a good result. It's the difference between 'It looks random to me' and 'I know and understand the basis on which I believe this to be random'. Binary process noise samplers are much easier to model, test and build, which is why we went that way for Intel chips. The RNG only takes a tiny sliver of silicon. You might as well get it right. David ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] [liberationtech] Random number generator failure in Rasperri Pis?
On 7/19/2013 3:26 PM, Nico Williams wrote: The rpi's HW RNG is almost certainly better than many /dev/*random implementations running as VM guests. How much real business is getting transacted on VMs nowadays? Probably a lot. This probably sounds like a plug for my employer, which it isn't, but the RdRand instruction was done the way it was done to punch through the VM and deliver random numbers directly to the running application, bypassing all those layers of software. Unfortunately VMs came first, so there's an entropy gap on servers that should be addressed. You still trust the VM not to meddle with it, but if you don't trust the VM, you have bigger problems. I have no reason to doubt the rpi's RNG (I have a clue about its circuit structure) but I also know that if it matters, you should probably do some testing of the random numbers before you trust the source, because no one else is testing it for you. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG - RdSeed
If you thought RdRand caused a lot of chatter on this list, we've just announced a new sister instruction.. RdSeed. It's here.. http://software.intel.com/file/45207 RdSeed is SP800-90B C and X9.82 parts 2 4 compliant in the XOR construction. But they're all draft specs so things could change. RdSeed is to RdRand as /dev/random is to /dev/urandom. It returns 100% entropy (minus epsilon if you're picky). Since it is dependent on the supply of entropy and has quite a conservative conditioning ratio, its maximum throughput is less than that of RdRand. We haven't released anything other documentation on this yet, so until we do, this is as good a place to ask questions as any. DJ ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel RNG
On 6/19/2012 7:35 PM, coderman wrote: On Tue, Jun 19, 2012 at 1:54 PM, Marsh Ray ma...@extendedsubset.com wrote: ... Just a sanity check that the output is actually changing once in a while would go a long way towards eliminating the most common failure modes. On Tue, Jun 19, 2012 at 6:58 PM, d...@deadhat.com wrote: ... Actually having a perfect source is a problem. It's much easier to test for a source with known defects that meet a well defined statistical model. is there any literature on the typical failure modes of TRNG/entropy sources in deployed systems? my understanding is that they tend to fail catastrophically, in a way easily detected by FIPS sanity checks. E.g. clearly broken. is it exceedingly rare for subtle / increasing bias to occur due to hardware failure or misuse in most designs? are there designs which fail hard rather than fail silent when error is encountered? If an entropy source in a closed system is producing an apparently non repeating, unbiased sequence and its output is deterministic (or low entropy) then there must be internal memory in the entropy source that is enabling the non repeating behavior. The more memory, the longer you have to watch before you can identify repeating behavior. So make your entropy source have a very small amount of memory and be sufficiently simple that you can model it mathematically. Then you can show all the SPOF and DPOF failure modes and show that your health check circuitry catches them. You can also show your health check circuitry catches all repeating patterns up and beyond some size that is determined by the internal memory of the ES. So the answer is yes.. Minimal memory (E.G. fewer registers) = Fails hard. Lots of memory (E.G. lots of registers, like an LFSR) = opportunity to fail soft. I can't point to literature. I think it's obvious. Without memory, non repeating behavior has to come from non determinism. Perhaps I should write a paper :) Mistrust an ES with many flops. I don't approve of FIPS sanity checks. These are algorithms you can't specify independent of the generation process. Or in other words, you can't test for randomness, you can only test for functionality. You need to use other arguments to show that what you have is random. FIPS sanity checks are a chore to implement after you've implemented a real health test algorithm matched to the failure modes of the source. ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
Re: [cryptography] Intel Security Driver and AVX CPUs (rdrand)
On 9/1/2011 5:12 PM, Jeffrey Walton wrote:
Hi All,
For some time, Intel has offered a Security Driver for Windows [1]. It
basically allows us to use the 810 chipset and friends as a PRNG
source via a CSP:
if(CryptAcquireContext(hProvider, NULL, INTEL_DEF_PROV, PROV_INTEL_SEC, 0))
{
CryptGenRandom(hProvider, size, block);
}
Does anyone know if Intel is shipping an updated driver which
wraps/includes rdrand from AVX?
Jeff
RdRand is a normal instruction not an AVX instruction. This confusion
occurred because the first publication of the instruction was in the AVX
extension instruction reference. RdRand has nothing to do with AVX other
than proximity in the documentation.
The whole shebang (entropy source, conditioning, self testing, CSPRNGing
and instruction set support) is now called 'Intel Bull Mountain Technology'.
Since it is an instruction accessible to code at any privilege level and
it is atomic at the point of use, it doesn't need a driver as such. It
can be used directly, or through some simple library function or
indirectly through support in OSs or cryptographic libraries.
What has been provided to date is the Bull Mountain Software
Implementation guide and some related example code :
http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/
There's support for RdRand and the RdRand compiler intrinsics in up to
date versions of GCC and the example code uses that. For proprietary
development tools, you'll have to check with the vendor.
I don't know is there's any support for a Microsoft CSP, but given the
nature of RdRand, the functional end of the code would be very short indeed.
Keep in mind that the output of RdRand is the output of a (very
frequently reseeded) 128 bit PRNG. It is cryptographically inappropriate
to seed a wider PRNG from the output of a narrower PRNG. The SIG
document talks about this and what you can do about it if you really
feel the need to seed a PRNG from a PRNG.
___
cryptography mailing list
cryptography@randombit.net
http://lists.randombit.net/mailman/listinfo/cryptography
[cryptography] Intel RNG
Intel has published more details of the new rdrand instruction and the random number generator behind it. http://software.intel.com/en-us/articles/download-the-latest-bull-mountain-software-implementation-guide/ http://software.intel.com/file/36945 ___ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
