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 calestyo@xxxxxxxxxxxx (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 • michael@xxxxxxxxxxx > “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 > dm-crypt@xxxxxxxx > https://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx https://www.saout.de/mailman/listinfo/dm-crypt
