>The 16 is just a lower limit. Almost every cryptographic RNG has a block size much, much larger so it's no big deal.
But it asks for the test to be made at the output. The block size might be 128 or 256 bits, but the output is often less. E.G. RdRand has a block size of 16, 32 or 64 bits. So if you built a FIPS140-2 compliant software stack and didn't want to fight with the certification house and so implemented 4.9.2, it would fail easily at 16 bits and fairly easily at 32 bits.
>But making a practical attack based on that seems unlikely to me.
Q: If you have a 128 bit 'full entropy' key K[127:0] , how much is the entropy reduce if K[(n*16)+15:(n*16)] K[((n+1)*16)+15:((n+1)*16)] for n in {0..7} ? A: A lot.
I.E. It reduces the brute force search space by a lot.
I think people are being blinded a bit by the dual_EC_DRBG issue. It makes people think the other 3 DRBG algorithms in SP800-90A are OK.
However if your system implements FIPS140-2 compliance, there's another hole which affects all RNGs within the FIPS boundary. Please read section 4.9.2 of FIPS140-2. You will see this. I call it the FIPS entropy destroyer...
"1. If each call to a RNG produces blocks of n bits (where n > 15), the first n-bit block generated after power-up, initialization, or reset shall not be used, but shall be saved for comparison with the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be compared with the previously generated block. The test shall fail if any two compared n-bit blocks are equal. "
This will eliminate all adjacent pairs, which would otherwise appear with a frequency dictated by the binomial distribution derived from the bit width of the output and for a 16 bit source, is trivially distinguishable from random with less that 1MByte of output data.
For the record, RdRand doesn't do this because I refused to put it in because it's a back door in the spec.
The Intel Broadwell CPU has got a machine code pseudo random number generator in it's extended instruction set! Immense! Gimme Gimme Gimme...
And what's more the pseudo random number generator is NSA approved.
No. In designing it, I plotted a path around the obvious back doors in SP800-90 and FIPS140-2. I don't think the part of the NSA that likes weak RNGs likes that one. The obvious back doors being the Dual-EC-DRBG and FIPS140-2 section 4.9.2, which I call the FIPS entropy destroyer.
The reseeding 2 million times a second thing is an effective defense against a class of hypothetical attacks which wouldn't work anyway.
It is FIPS compliant, but we won't be claiming FIPS certification until it is actually FIPS certified.
>The Intel Broadwell CPU has got a machine code pseudo random number generator in it's extended instruction set! Immense! Gimme Gimme Gimme...
Actually, it's a hardware RNG feeding the instruction, and in Broadwell there are two instructions, RdRand and RdSeed. RdRand for an often (2 million times a second) reseeded SP800-90A compliant AES-CTR-DRBG. RdSeed for an XOR construction ENRNG built about the DRBG using the AES-CBC-MAC conditioner output for the full entropy seed.
>Does a solid state drive really need a cache? Flash is slower than RAM.
However, from a computer architecture 101 point of view, putting silicon memory behind a disk interface is completely stupid. Putting the cache behind the disk interface is even stupider. So the cache is more there to patch up the ludicrous storage architecture than to address any particular shortcomings of flash memory.
Each transaction includes a 2.5 - 5% transaction cost that the retailer pays.
Two things.. 1) That's a huge percentage for a transaction cost that takes a couple of milliseconds on computer time, mostly by companies that don't receive the transaction fee. A saving account might give you 2% for holding the money for a whole year.
2) It's a percentage, not a fee. The transaction doesn't cost more when the price of the goods is greater.
>The problem is that there is solid research showing that you are 4x as likely to have a crash when you are using a cell phone (McEvoy et al (2005); Redelmeier & Tibshirani (1997)). This has been measured with actual data from emergency department visits and property damage only accident reports.
That is not solid research. That is bad sampling. Sampling only the journeys that ended up in an accident is the most heavily biased sampling you can perform.
Just because it sounds official doesn't mean they understood the first thing about statistical inference.
>Even if there's been no rise in accident rate after cellphones became ubiquitous, that doesn't mean phoning or texting while driving isn't dangerous. Or is.
Most of the time it's correct to admit you don't know either way.
This is the same bad statistics that gets repeated every 3 or 4 months on Slashdot, from some stupid newspaper article.
Looking at the number of accidents involving phones tells you nothing. It could be that a greater proportion of non-accident journeys involved phones. It could be that the accident rate would be higher without the phones because people are taking more care driving to compensate for operating a phone.
How about taking a random sampling of car journeys and seeing the relative prevalence of phone use between accident and non-accident car journeys? It would have to be a very large study because the accident rate relative to the car-journey rate is very low. It would have to be a random sampling from a larger sample population to suppress confounding effects.
Good statistics over human behaviors with small effects is very hard to do because it requires big studies. But we know exactly how to do it.
What is not clear is if there was an actual arms deal being done or the feds were leading him down a path. It wouldn't be a reasonable thing to ask except that this is in keeping with a pattern the FBI is known for. For example a local (to me) case was Mohamed Osman Mohamud, who engaged in a spot of attempted mass murder, but it transpired that he was led down that path by the FBI and only the FBI. They providing the schooling, the materials and the motivation. Left alone he probably would not have done anything. Instead of waiting to see if he did anything, they helped him right along so they could prosecute him and claim a victory.
>Most academy award winners? Not present. >Most Oscar winners? Not present. >Most Sundance Film Festival Winners? Not present....
And not a fuck was given. There's more than enough to watch. If a movie maker doesn't want me to see their previous movie, that's their own business. I'm not going out of my way to help them distribute their product to me.
Slashdot Mirror
>The 16 is just a lower limit. Almost every cryptographic RNG has a block size much, much larger so it's no big deal.
But it asks for the test to be made at the output. The block size might be 128 or 256 bits, but the output is often less. E.G. RdRand has a block size of 16, 32 or 64 bits. So if you built a FIPS140-2 compliant software stack and didn't want to fight with the certification house and so implemented 4.9.2, it would fail easily at 16 bits and fairly easily at 32 bits.
>But making a practical attack based on that seems unlikely to me.
Q: If you have a 128 bit 'full entropy' key K[127:0] , how much is the entropy reduce if K[(n*16)+15:(n*16)] K[((n+1)*16)+15:((n+1)*16)] for n in {0..7} ?
A: A lot.
I.E. It reduces the brute force search space by a lot.
I think people are being blinded a bit by the dual_EC_DRBG issue. It makes people think the other 3 DRBG algorithms in SP800-90A are OK.
However if your system implements FIPS140-2 compliance, there's another hole which affects all RNGs within the FIPS boundary. Please read section 4.9.2 of FIPS140-2. You will see this. I call it the FIPS entropy destroyer...
"1. If each call to a RNG produces blocks of n bits (where n > 15), the first n-bit block generated
after power-up, initialization, or reset shall not be used, but shall be saved for comparison with
the next n-bit block to be generated. Each subsequent generation of an n-bit block shall be
compared with the previously generated block. The test shall fail if any two compared n-bit
blocks are equal. "
This will eliminate all adjacent pairs, which would otherwise appear with a frequency dictated by the binomial distribution derived from the bit width of the output and for a 16 bit source, is trivially distinguishable from random with less that 1MByte of output data.
For the record, RdRand doesn't do this because I refused to put it in because it's a back door in the spec.
Apparently TechyImmigrant below may not be human....
After my dental work, I presume I'm a cyborg, but still built on a base human platform.
The Intel Broadwell CPU has got a machine code pseudo random number generator in it's extended instruction set! Immense! Gimme Gimme Gimme ...
And what's more the pseudo random number generator is NSA approved.
No. In designing it, I plotted a path around the obvious back doors in SP800-90 and FIPS140-2. I don't think the part of the NSA that likes weak RNGs likes that one. The obvious back doors being the Dual-EC-DRBG and FIPS140-2 section 4.9.2, which I call the FIPS entropy destroyer.
The reseeding 2 million times a second thing is an effective defense against a class of hypothetical attacks which wouldn't work anyway.
It is FIPS compliant, but we won't be claiming FIPS certification until it is actually FIPS certified.
>The Intel Broadwell CPU has got a machine code pseudo random number generator in it's extended instruction set! Immense! Gimme Gimme Gimme ...
Actually, it's a hardware RNG feeding the instruction, and in Broadwell there are two instructions, RdRand and RdSeed. RdRand for an often (2 million times a second) reseeded SP800-90A compliant AES-CTR-DRBG. RdSeed for an XOR construction ENRNG built about the DRBG using the AES-CBC-MAC conditioner output for the full entropy seed.
I thought everyone knew that.
>Does a solid state drive really need a cache?
Flash is slower than RAM.
However, from a computer architecture 101 point of view, putting silicon memory behind a disk interface is completely stupid. Putting the cache behind the disk interface is even stupider. So the cache is more there to patch up the ludicrous storage architecture than to address any particular shortcomings of flash memory.
Each transaction includes a 2.5 - 5% transaction cost that the retailer pays.
Two things..
1) That's a huge percentage for a transaction cost that takes a couple of milliseconds on computer time, mostly by companies that don't receive the transaction fee. A saving account might give you 2% for holding the money for a whole year.
2) It's a percentage, not a fee. The transaction doesn't cost more when the price of the goods is greater.
Not a problem. I've yet to see a study suggesting programming while driving contributes to crashes.
>And bring back manual spark advance while you're at it.
As long as I can write and android app to automatically tweak it in time with the music.
>The problem is that there is solid research showing that you are 4x as likely to have a crash when you are using a cell phone (McEvoy et al (2005); Redelmeier & Tibshirani (1997)). This has been measured with actual data from emergency department visits and property damage only accident reports.
That is not solid research. That is bad sampling.
Sampling only the journeys that ended up in an accident is the most heavily biased sampling you can perform.
Just because it sounds official doesn't mean they understood the first thing about statistical inference.
>Even if there's been no rise in accident rate after cellphones became ubiquitous, that doesn't mean phoning or texting while driving isn't dangerous.
Or is.
Most of the time it's correct to admit you don't know either way.
My android phone does this.
This is the same bad statistics that gets repeated every 3 or 4 months on Slashdot, from some stupid newspaper article.
Looking at the number of accidents involving phones tells you nothing.
It could be that a greater proportion of non-accident journeys involved phones.
It could be that the accident rate would be higher without the phones because people are taking more care driving to compensate for operating a phone.
How about taking a random sampling of car journeys and seeing the relative prevalence of phone use between accident and non-accident car journeys? It would have to be a very large study because the accident rate relative to the car-journey rate is very low. It would have to be a random sampling from a larger sample population to suppress confounding effects.
Good statistics over human behaviors with small effects is very hard to do because it requires big studies. But we know exactly how to do it.
If we all just used Galois fields of order 2^p, we could divide anything into anything and get a result in the field.
Well he was certainly into gun control - He was trying to control the gun supply.
I'm real.
What is not clear is if there was an actual arms deal being done or the feds were leading him down a path. It wouldn't be a reasonable thing to ask except that this is in keeping with a pattern the FBI is known for. For example a local (to me) case was Mohamed Osman Mohamud, who engaged in a spot of attempted mass murder, but it transpired that he was led down that path by the FBI and only the FBI. They providing the schooling, the materials and the motivation. Left alone he probably would not have done anything. Instead of waiting to see if he did anything, they helped him right along so they could prosecute him and claim a victory.
But was there an arms shipment? Were there ever any arms or a trafficker? Or was that all a fiction created by the FBI?
Not just for keeping doors closed then.
>Most academy award winners? Not present. ...
>Most Oscar winners? Not present.
>Most Sundance Film Festival Winners? Not present.
And not a fuck was given. There's more than enough to watch. If a movie maker doesn't want me to see their previous movie, that's their own business. I'm not going out of my way to help them distribute their product to me.
How does that work? It's the first I've heard of such a thing.
Trademarks certainly need to be defended. But not patents as far as I know. Of course the law is full of ah-but bullshit hidden in the corners.
If the statement in TFA was true, I would have heard of the program. But I didn't.
Another case of the NSA lying.
My predicate calculus trumps your lambda calculus.
WTF does the church have to do with this?
That's the kind of feature I want to see in a phone. I want one of those cheap but functional Chinese (where they make all the phones) phones.