[Cryptography] Security on TRIM for full-disk encrypted SSDs

[Valmiky Arquissandas]

> On Thu, Apr 21, 2016 at 3:19 PM, Peter Fairbrother <peter at m-o-o-t.org> 
> wrote:
>> You think that an attacker knowing how much data you send doesn't 
>> affect
>> confidentiality?
>> 
>> hmmm, how many files on t'internet are 2798954788 bytes long?
> 
> You're right - that matters, but only for specific threat models,
> particularly those involving transmission of illicit material.
> Returning to the problem at hand - that of allowing one's opponent to
> know one's net drive allocation by enabling TRIM under encryption -
> the answer remains "it may matter".  If you're storing a known
> quantity of illicit material in a way that could be separated from the
> rest of the noise on your system, then yes - enabling TRIM is probably
> dangerous.
> 
> For the rest of us that simply wish to prevent data loss or
> modification in the event of a lost or stolen system or drive and lack
> illicit material?  TRIM can be a great disk-longevity option that does
> not affect our threat model.
> 
> You have to know what you're defending and what you're defending it
> against.  Because they have customers with varying threat models, FDE
> developers have historically tended toward the conservative extreme
> and are just now offering exceptions to that.  For the average user,
> however, the performance and operational load of that extreme may
> outweigh actual concerns.

This sounds about right to me, and Linus' link is precisely the kind of 
information I was looking for. It confirms that an attacker may infer 
how much space is used, and what the underlying filesystem is. My only 
remaining question is whether this is as far as it gets, or if there is 
knowledge of something even deeper.

The threat model is responsible for deciding what inferences are 
acceptable or not; I'm trying to understand what those inferences are.

"how many files on t'internet are 2798954788 bytes long?" -- when a 
device is FDE'd, and it discards unused blocks, is it ever possible to 
find out that one of the files is exactly 2,798,954,788 bytes long?

Since files may be fragmented, and their blocks would be fully marked as 
used - even if they weren't filled - the best guess I would imagine an 
attacker could make - if there was no fragmentation, the data was 
completely contiguous, *and* the attacker already knew that - is that 
the file would be between 2,798,954,496 and 2,798,955,008 bytes long (if 
blocks are of 512 bytes). When fragmentation scatters a file's contents, 
I would guess all bets are off.

I use full disk encryption for two purposes - keep the contents of the 
information I store from being read if my laptop (or backup drive) is 
stolen, and protect the (Linux) partition that contains it from being 
readable from the Windows system (dual boot). Should my Windows 
installation become a target of the likes of ransomware (or plain old 
spyware), it may encrypt my irrelevant files, but it won't ever be able 
to read or overwrite those that matter (unless it nukes the LUKS 
metadata, or it is so advanced it poisons the boot process to recover 
the passphrase). Worst case, I have to reach my backups, but nothing 
should have been revealed.