On Sat, Apr 14, 2012 at 11:22:15PM +0100, alban bernard wrote: > --- On Sat, 4/14/12, Arno Wagner <arno@xxxxxxxxxxx> wrote: > > The Design "error" is of course that the raw device is told > > about > > some things that should only be visible after decryption. > > > > In a way, TRIMing leads to the same situation as not writing garbage > before device encryption. > > > The information leakage is very small. If it is a concern, > > then TRIM must never be used. If not, TRIM can be used in > > unlimited > > fashion. It is a standard security trade-off. Your options > > can > > in some circumstances decrease the information lekage, but > > they > > will not so so reliably (comments below), and hence do not > > reduce > > the worst-case. But the risk-analysis that form the basis of > > the > > decision to allow TRIM or not has to use the worst-case as > > there > > is no basis for forming an average-case and an attacker may > > be able > > to provoke the worst-case scenario. > > In case the user chooses the performance trade-off, an option to maximize > security is still interesting to him. I agree with you, a layer that > cryptographically randomize TRIMed blocks while limiting information > leakage is not a key point to decide to allow TRIM or not (the worst case > is still possible), but it is still important to have the option from the > user perspective. I do not agree. Most users will not understand what they are doing and an option that increses performance while seemingly still having high-security (as there is this "additional measure") will just mislead them. And there is no way to "maximize security" when TRIM is active. The way to maximize security is to not use TRIM. > > > - randomize device usage pattern when choosing blocks > > to TRIM (hide > > > filesystem) > > > > I don't quite understand how that could work, do you mean to > > have > > a random mapping between encrypted and hysical secors? That > > would > > kill performance a lot worse than not using TRIM in the > > first place. > > > I meant to randomly distribute TRIMed blocks across the device by choosing > to not TRIM contiguous blocks of some files. E.g. when a big file is > deleted, allow TRIM only on a randomly chosen set of its blocks limited to > about 1 percent of its size. The 99 percent of it would stay unTRIMed on > the device. That would have very little benefit, while still having the same worst-case information leakage. > > So, these ideas could only limit the information leakage that could be > used by an attacker. No. They would not limit anything. They would decrease the probability of accidental leaks of a higher amount of data, but the worst-case stays the same. > To complete my understanding, if the device is > completely used (no more free space), an attacker could not benefit of any > leakage from TRIMed space. So, there is a relation between information > leakage rate and amount of TRIMed space. A question rises to me: does an > amount of TRIMed space exist to keep performance and still harden > crypto-analysis in a controllable manner? No. You can only decrease probabilities, but not amount leaked in the worst case. Crypto is very hard. Using worst-case scenarios is necessary to be sure of an analysis. To put it in another way, if performance is important enough to you to compromise security, then there is a high probability that you will break security. It happens all the time by developers that do not know what they are doing. Arno -- Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: arno@xxxxxxxxxxx GnuPG: ID: 1E25338F FP: 0C30 5782 9D93 F785 E79C 0296 797F 6B50 1E25 338F ---- One of the painful things about our time is that those who feel certainty are stupid, and those with any imagination and understanding are filled with doubt and indecision. -- Bertrand Russell _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
