What the article actually says in the last paragraph is that there's currently a capacity shortage, that's expected to be resolved by 2015. The article also says manufacturers think they can go down another process node, and then do another 3 after that using 3D stacking. Then he says new technologies "with the speed of DRAM and the storage capacity of NAND" might make their way out of the lab next year.

Overall, the article's contents don't really seem to support the notion that it's game over for SSD capacity improvements.

I looked at the paper from CRI, they apparently did do testing on the raw (pre-whitening) entropy source on test chips that give direct access to it. Unfortunately the goal of that audit was to build confidence in the general design, the NSA wasn't an issue when that was done.

What I take away from this is - the good news is, the RDRAND circuitry has an open, well documented design which is apparently robust. Thus, if we can obtain confidence that it's not backdoored by the NSA, it's a great feature to have. Note to people talking about China, etc, Intel run all their own fabs. The chance of a technique as complicated as crypto backdoors using dopant trojans being inserted into the manufacturing process inside Intel-controlled fabs is close to zero. If it's done, it's done with the knowledge and co-operation of management.

The question is how can the world build such confidence? The standard way would be to decap some randomly chosen chips and analyze with an SEM, but I have no idea if that's feasible for something as complicated as a modern Intel core. Presumably Intel themselves can do it for debugging purposes, but whether it can be done in the absence of lots of proprietary information is unclear. Also, the output of RDRAND could presumably be patched using microcode updates, so just because the chips ship without a backdoor doesn't mean one couldn't be introduced later through a firmware/BIOS update.

Maybe. In the USA, first off, ambulances are not free, and, second, they may not be close. If someone out in the country lives an hour from the nearest ambulance, they might not want to wait and they would certainly dispute the "quicker" part.

Ambulances also have a substantially higher rate of accidents and fatalities than the average driver, so they might dispute the "safer" part as well.

Let's see. My wife goes into labor at 4:00 AM*, and sleepy and excited I get into the car to drive her to the hospital... only to have the car refuse to start, as my brain waves don't match its stored template. Oh, yeah, that will go over well.

* That was, in fact, when my wife went into labor.

What if I'm hugely stressed out because a tsunami or forest fire is coming or my critically injured child needs rushing to hospital or some such? If that changes my brain waves enough to prevent me driving, it would be unfortunate.

(To be fair, TFA says they're looking initially to use it on buses and armoured cars. I wonder if "masked man is pointing gun at my head and ordering me to drive" sufficiently alters the brain waves.)

I've been thinking about getting one of those, but a mere 8GB cache seems inadequate. Does anyone with experience of these care to comment?

As other people pointed out, disk seeks are most assuredly something to avoid on spinning media. But even when seeks are free, as they are on SSD, fragmentation still sucks and you should avoid it like you owe it money. For one, some filesystems use run-length encoding for the list of blocks in a file. Basically, instead of recording "1, 2, 3, 4, 5, 8, 14", they notice the pattern and record "1-5, 8, 14" like you just did in your post. (The ext[234] family doesn't do this, but IIRC some of the post-ext2 up-and-comers use it.) RLE lets you inline more metadata directly in the inode without resorting to indirect blocks, which basically means you get your data with fewer round trips to the disk. (It might save you from needing to read a meta-meta-block to find the meta-blocks that tell you where the blocks are. Instead you can fit all the blocks in one meta-block and skip a round trip.) For two, even filesystems on SSD that don't do RLE still suffer under fragmentation. Unfragmented files make it easy for the kernel I/O scheduler to coalesce those sequential block reads into big, happy multi-block SATA reads when you're streaming through the file. As before that means fragmentation = more round trips to the disk, but it also means fragmentation = spamming the SATA controller with more commands and spamming the CPU with more interrupt handlers for the command completions. (In other words, copying a big fragmented file slows down everything else on the computer, moreso than copying a big un-fragmented file.)

Disclaimer: I am not a filesystem designer, I just play one on Slashdot.

Unlike some defendants, I would be astounded if she did not have advice of counsel, and pretty good counsel at that.

No, I think not.

Note that I am not hiding as an AC to say so.

It is the only crime defined there :

Treason against the United States, shall consist only in levying War against them, or in adhering to their Enemies, giving them Aid and Comfort. No Person shall be convicted of Treason unless on the Testimony of two Witnesses to the same overt Act, or on Confession in open Court.

Don't see anything there about not cooperating with the authorities.

We had some issues with not adding enough randomness in embedded devices, but that problem was largely fixed a year ago. At this point, I think urandom should be fine for session keys. It's not the best choice for long-lived keys in those embedded devices, but those devices (a) don't have RDRAND, since they tend to mips or ARM CPU's, and (b) since they don't have any peripherals other than the flash drive and the networking cards, there isn't that much entropy they can draw upon. There are things you can do to improve things in userspace, such as holding off on generating the host keys and generating the RSA keys for the certificates as long as possible, instead of right after the boot. But that's much more of a specialized problem for a specific class of system.

I linked to that RFC for the text in the introduction section, from which I got the "chosen ad hoc" language. My point is not to cast suspicion on all ECC, which is a valid mathematical technique developed in the open by civilian academics. But rather, to provide more evidence for the fact that nobody seems to know how the seed values were generated (we know WHO generated them, but not HOW).

I just found this new blog post from the NYT which gives a very small amount of additional context. It also explicitly names the NSA RNG as what they were talking about.

http://bits.blogs.nytimes.com/2013/09/10/government-announces-steps-to-restore-confidence-on-encryption-standards/

But internal memos leaked by a former N.S.A. contractor, Edward Snowden, suggest that the N.S.A. generated one of the random number generators used in a 2006 N.I.S.T. standard — called the Dual EC DRBG standard — which contains a back door for the N.S.A. In publishing the standard, N.I.S.T. acknowledged “contributions” from N.S.A., but not primary authorship.

Internal N.S.A. memos describe how the agency subsequently worked behind the scenes to push the same standard on the International Organization for Standardization. “The road to developing this standard was smooth once the journey began,” one memo noted. “However, beginning the journey was a challenge in finesse.”

At the time, Canada’s Communications Security Establishment ran the standards process for the international organization, but classified documents describe how ultimately the N.S.A. seized control. “After some behind-the-scenes finessing with the head of the Canadian national delegation and with C.S.E., the stage was set for N.S.A. to submit a rewrite of the draft,” the memo notes. “Eventually, N.S.A. became the sole editor.”

The Guardian, ProPublica, the NYT and Schneier all appear confident enough in what they've read to state assertively that it's a hacked standard. Also, why else would the NSA care so much about pushing a crap and slow RNG that we know can have a backdoor into international standards?

That story is about Dual_EC_DRBG which was indeed strongly suspected of being an NSA back door back in 2007. Snowden confirmed the suspicion. However this story is not about that algorithm. It's about the SEC random curves that are used for signing and other crypto, not random number generation. There are two different algorithms under discussion here.

Bitcoin uses what the SEC calls a Koblitz curve (secp256k1) for which there is much less design freedom and it seems much less likely that there is any way to back-door those curves. Unfortunately many ECC implementations don't support all the curves, just a few of the plain vanilla random ones. Actually I'm not aware of anything except Bitcoin that uses secp256k1.