Among other things, making a successful attack would require sufficient privilege level to bypass all layers of read caches (and probably also all write caches), a target SSD that doesn't use modern 3D NAND, and intimate knowledge of the internals of the SSD controller and firmware, potentially up to the internal state of the LFSR or AES used to scramble data before it is written to the flash.

There's interesting stuff in this research; it highlights aspects of the unreliability of flash memory that I haven't previously seen emphasized so clearly. But since everything about SSD design already assumes that the flash memory is thoroughly unreliable and untrustworthy, these corner cases don't rise to the level of a real-world vulnerability.

No, they claim only to be able to use hdparm to extract the logical block address at which a file is stored. Whether that gives you any useful information is entirely dependent on the internals of the SSD.

I understand not everyone will have the same reaction. I don't pretend to speak for everyone, but I suspect I speak for the majority.

>Author here, I would like to set the record straight.

>We do not claim to have an attack on SSDs.

but in the paper:

>>"We assume that the victim system runs a filesystem on top of MLC NAND flash-based SSD."

Also, those sentences aren't contradictory. "Note that this result does not depend on whether you are using an SSD, a disk, or any other storage for your filesystem." Meaning the attack might apply to someone using an SSD, but the SSD has nothing to do with the vulnerability. It is useful to precisely define a model case in the paper so your results can be easily reproduced, even if some details are not required to demonstrate the vulnerability.

The post on question also didn't call the author an idiot, just said that the paper was idiocy. That's not ad hominem at all.

Differential cryptanalysis is not about defending against bit-flips. Instead, it is about comparing two cipher texts to learn something about the relation between corresponding plain-text.

This is only possible on AES-CTR if you have to ciphertexts with the same key and nonce/IV. This is why a nonce is supposed to be used only once. Same goes for other xor based stream ciphers.

I recommend you read this article: https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation

Same way Rowhammer works. Exploiting a physical vulnerability gives zero damns about encryption. Now whether you get VALID or USABLE data from the attack is an entirely different story.

00000000

If it's anything else the user would have to enter the key. So in practice, it's not /really/ encrypted.

https://github.com/Drive-Trust-Alliance/sedutil/wiki