Re: [dm-crypt] 'discard' as default

Well, I can understand that the maintainers want to give their
users the best experience and for security software that is 
always difficult to determine.

However, defaults _must_ be secure or you can simply do without
encryption in the first place. Encryption always decreases 
usability, there is no way around that. Those that prefer 
usability (speed, simplicity, etc.) will simply do without 
encryption and hope nobody attacks them.

Hence here is my recommendation: No TRIM in the defaults. 
Putting that in there would be really bad mindset-wise.

You can certainly add a statement prominently in the
documentation on how to add TRIM and that it will decrease
security. You can also add commented-out alternate configuration
lines with TRIM and a warning comment.

While you are it, you may also add a reference to FAQ 
Item 5.19 which discusses the security problems putting 
LUKS on an SSD or other solid-state drive.

Regards,
Arno




On Wed, Jan 02, 2019 at 21:57:41 CET, Michael Kjörling wrote:
> On 2 Jan 2019 21:41 +0100, from [email protected] (Christoph Anton Mitterer):
> >> To our knowledge, that's only a problem if you need plausible
> >> deniability, wich LUKS doesn't provide anyway.
> > 
> > AFAIK, this hasn't to do anything with plausible deniability (at least
> > not in the classic sense of "hidden encryption"), but rather that an
> > attacker might gain valuable information that can be used for further
> > attacks... and as always it's likely just our imagination which limits
> > these.
> > 
> > One could think of deletion patterns that (depending on their size)
> > give hint what is being deleted (what you might have meant by plausible
> > deniability?)... or perhaps it could eventually somehow help in
> > statistical attacks (maybe a regularly deleted file with more or less
> > known content)?
> 
> Pattern analysis (which is made far easier by TRIM pass-through) can
> certainly tell an attacker which file system is likely in use on the
> device, and give them an idea of how much data is likely there. I
> don't remember where I saw it, but I did see a write-up by someone who
> had created various major Linux file systems on otherwise blank
> devices. The differences in data layout were _clearly_ visible.
> 
> With payload data added, the differences might be less obvious, but
> they are still going to be there. A partition with a XFS file system
> is going to look different from one with ext4, or ZFS, or something
> else, even if the attacker can't tell _what's_ stored there.
> 
> The point of filling the partition with random data is to make this
> kind of attack much harder to pull off.
> 
> Sure; which file system is in use might be basically public knowledge
> anyway, and it _shouldn't_ give an attacker an advantage. But it's
> information that the attacker doesn't _necessarily_ need to have, and
> certainly information they don't need be fed on a silver platter (or
> chip, as the case may be).
> 
> Good cryptography design aims to give an attacker as little
> information as possible about the underlying plaintext. Deviating from
> that goal as a default should require an _awfully_ good reason.
> 
> -- 
> Michael Kjörling • https://michael.kjorling.se • [email protected]
>   “The most dangerous thought that you can have as a creative person
>               is to think you know what you’re doing.” (Bret Victor)
> _______________________________________________
> dm-crypt mailing list
> [email protected]
> https://www.saout.de/mailman/listinfo/dm-crypt

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: [email protected]
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier