On Mar 18, 2013, at 5:00 PM, Kyle <li...@lolwut.org> wrote: > > I'm doubtful that encryption would be as effective as what Chris Mason was > suggesting, which is to either find and use a disk with secure erase trim or > rotate out the drives and securely erase them so that the data is destroyed > entirely rather than encrypted.
Well, I'll argue it's more effective in that it's more likely to be used than it is to be cracked in the time frame of the data mattering if the proper setup is being used. > > Simply having the data exist on a disk, even if it's encrypted, still leaves > it open to various attacks. For instance, multiple side channel attacks exist > which could reveal the decryption key, permitting all data on the disk to be > read including deleted but not yet overwritten files. Not if you're using LUKS with either a high entropy passphrase, or increasing PBKDF2 iterations, or both. LUKS and at least Opal SEDs don't store keys or passphrases in plaintext. If you're using plain dmcrypt (without LUKS) then you be concerned. > Physical access to the machine may not even be required: A remote attacker > able to exploit the machine and read the disk blocks would be able to recover > the data as well. If it's an HDD, or the SSD's garbage collection after trim is issue is slow, yes anyone who has either file system or block level access can obtain unencrypted data from a mapped encrypted block device. But if the fall back position to a remote take over is counting on deleted files being irrecoverable, well, you still have a remote attacker stealing visible files. Chances are if the deleted files are that sensitive, the non-deleted files are too. So I don't see the gain of going to extraordinary lengths to zero the data in released blocks for active use drives. > > Granted these types of attacks are rare, however ultimately the only way to > secure unneeded sensitive data against a determined attacker is to destroy it > outright. This is probably specious. It's sorta like saying the only way to secure a computer containing sensitive data is to disconnect it from the internet. Or from the wall outlet. > Hugo made the point that a multitude of other data-leakage paths exist, and > while this is true, at a minimum one should be able to destroy individual > files beyond recovery so that should data leakage occur in the future, > previously securely erased data is not recoverable. At least, in an ideal > world. Well at the moment we are SOL on that front with either SSDs or COW file systems. You'd need to use HDDs and a file system that'll support overwriting files with random data and then marking them as deleted. I think the overwhelming concern is someone gaining physical access to the drive: theft of a laptop, or disposal of a dead drive (for which ATA security erase unit commands aren't going to work). And for that encryption is quite useful and important. Chris Murphy-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
