Can't they just make a button during the install that you can press to get 'illegal' software. The button could read:
'I want to play mp3 files and I don't care if it's illegal. I take full responsibility for my actions.'
Like if that wouldn't get them into trouble. Better warn people that the software is only legal in some countries, and provide them a question similar to this: Have you verified that using this additional software is legal in your country of residence? Yes/No.
Yes, this is one of the great things about yum. There is a simple and clean way to have installation and upgrading of base software and third party software managed with a single interface. Livna is not the only such repository, personally I'm quite happy with freshrpms. Probably there are more.
I don't know if Ubuntu have something similar, but I guess they have.
I have seen how this is handled on Windows, I have seen how this is handled on Red Hat Linux, and I have seen how this is handled on Fedora Core. And except from the problem with rhn-applet being totally broken in FC4, I like the way it works in Fedora. I hope that has been fixed in FC5 (or FC6) or at least replaced with some alternative.
Would have to prove that while in flight, there was no way the key could get lost, or changed, or...
Proving that isn't going to be any harder than proving whatever other destruct mecanism you could come up with wouldn't get triggered unintentionally. Besides even if the key is kept safe, there are so many other things that could go wrong. Who cares if the key is safe in case the system accessing the data breaks down in unpredicted ways, which is much more likely to happen than a problem with the encryption itself. Finally in case of a scheme involving encryption and destruction of the key, it is possible to store a backup of the key in a safe location (that is not on the plane). In that way even if the key was destructed, you still have some chance of recovering the media and decrypt contents.
The only problem with the encryption solution is, that storage encryption is significantly more complicated than most people think. Sure if you can accept some minor leaks, you can do something fairly simple and efficient. But if very high security is a requirement, I would worry about weaknesses in the encryption modes.
If Linux succeeds in displacing Windows, you will start to see non-free versions of it appear. Versions with enough modification that the "free" part is no longer the significant portion of its value. And the free versions will be obsoleted by their remnant bugs.
It would be possible, but an unofficial tld just won't get as much attention. I don't think many companies would want to buy a domain which the majority of the users don't know how to access, and they couldn't even be sure to get the official domain if xxx ever becomes an official tld.
If one company actually manages to make money from an unofficial xxx tld, I guess others will follow. Now we could have a handfull of companies selling the same domain, and anybody who wanted to be sure, would have to buy it from all of them. And even that wouldn't guarantee, that they would be able to get it under the official xxx tld, if that is ever going to happen.
Probably some of the alternative DNS roots are going to pick it up. Maybe some of them already have their own xxx tld. This is just going to add even more to the confusion.
What would happen if Debian, Mozilla, or Samba (for example) said "our license doesn't require us to fix any bugs, and we just don't feel like it".
Most likely someone would fork the project. The projects you mention are so large, that most likely a lot of the current developers would move to the fork, if the current project didn't progress. (Didn't something like that more or less happen to XFree86?)
Of course if a fork already exist, developers may just choose to contribute to that fork rather than starting a new one. If it was a small project, that stopped development, it might die. But that only happens if nobody care about it anyway, as long as somebody care enough about it, they can continue development. That is the whole point about open source.
Programmers who think their little pearls of code are what makes a project successful need to get over themselves.
If you find it so useful, that you had in fact already decided to use it for something important, you really ought to give the credit for what they have already done. I'm pretty sure you already got more support than you have been promised. If you decide to rely on getting support for free, you are really to blame. In short it is not the developer who overrated the project, it is the user who for whatever reason had far too high expectations.
I may tell people about some of my own projects, if they have a problem for which it may be usefull. But I sure as hell never promise that I will support it. Sure to some extent I have done so anyway, but I always make it clear that I don't make any promises.
I promote other peoples open source projects much more often than I promote my own projects. And I do so because I have found them useful, or because I know they have been useful to others.
That was when I discovered Internet Explorer shrunk images to fit the browser window.
If the image is a photography, people do want it fit to the size of the window most of the time. OTOH with a screenshot it is plain annoying. So the best the browser could do is to offer an easy way to switch between the two ways of handling images.
Sometimes on webpages I do see screenshots, which have already been downscaled. Such screenshots are mostly useless. If anybody want to put some smaller screenshots in a review, the correct approach is to configure the system to use a smaller resolution, and then take the screenshots. Or just do the whole thing using Xnest or anything similar.
Microsoft blames the lack of sales on Open Source Operating Systems.
Would be interesting, but I doubt that is going to happen. It could be interpreted as admitting open source software is better than Windows. Microsoft don't want to do that. I think they'd rather put the blame on unauthorized copies.
Fedora makes security transparent to the user, you're running SELinux but would never know it unless you needed to, you're running exec-shield but you'd never know it unless you needed to
But occationally it gets the file labels fucked up causing things to stop working. The Fedora people refuse to acknowledge there is a bug, after all you can just touch/.autorelabel and reboot.
all the major services are compiled to randomize memory mappings, but the user is none-the-wiser.
If you had actually been using Fedora since FC1, and you happened to be using it on a 586 architecture, you would have found out. Because for some reason they decided that on that architecture they would compile glibc with some options making it pretty picky about the location of the stack. This caused programs to crash at random, and the bug was never fixed. They simply wouldn't accept, that there could be a bug in glibc.
I can install Fedora and be fairly certain that even if somehow my system stopped updating
Actually that is not so unlikely to happen. Because on FC4 rhn-applet will always tell you, that there are no updates available. And occationally yum will also say that even when there are updates available. And the Fedora people does not consider this to be a bug.
And while we are at it, do you know what happens to the umask on a Fedora system? If I decide to set my umask to 077 such that other users cannot read by default, then/etc/bashrc is going to change it to 002. That means anything started from a script using bash as interpreter is going to create files with other permissions than intended.
I'm not saying Fedora is a bad distribution, after all I do use it on all my systems. You just shouldn't claim it to be so much more secure than other distributions. Yes, this bug in Ubuntu is very bad, but unfortunately they are not the first to introduce a bug that bad.
If you look on this just as an IT story, it is just yet another distributed computing project. But if you are interested in history, it may be different. The messages themselves may be of historical interest, we can't know for sure before they have been decrypted.
There are at least five types of severe attacks on correctly implemented CBC (one of which allows full recovery of secret plaintext without any knowledge of any part of the key).
I don't know why I should believe you. I have seen and verified the proof for security of CBC under the assumption that the cipher is indistinguishable from a random permutation. If that assumption does not hold, then tweakable ciphers does not work either. And even the incorrect implementations of CBC does not allow full recovery of an unknown plaintext.
Of course this is all assuming passive attacks. Neither CBC nor LRW is secure against active attacks. If you want security against an active attack, you need stuff like hash trees and message authentication codes.
You do your homework.
If you had done your homework you would have come across two articles on the subject which give different proofs why LRW cannot satisfy the strongest security definitions. They are both available on eprint.iacr.org one is written by Kristian Gjøsteen, and I'm coauthor on the other.
The proof of security applies to LRW-AES as well (because it is a tweakable cipher).
The proof applies to the cipher, not the mode. The way the cipher is used in TrueCrypt does not correspond to any of the modes in the paper you linked to. The paper also states that TAES is expected to be 50-80% slower than AES. Why not use AES in CBC mode? (Here I mean a correct implementation of CBC, not the one with a deterministic IV).
Now, while a lot of people have all kinds of spyware festooning all over, these are not the people who would know what Truecrypt is, anyway.
If you are unable to protect your computer from spyware, then disk encryption is not going to help much anyway.
A Truecrypt user is also likely to have the media in question reasonably sealed off from network access.
Some disk encryptions actually state that you can keep the container on a different computer and access it using some networking file system. I have not yet seen a disk encryption which was secure enough to be used in that way. I don't think TrueCrypt claims to be usable in that scenario. But even making a backup of the container could be dangerous.
Now, suppose that an attacker gets a copy of a volume and walks off with it, how strong an attack can be made?
How much information does he need to get from the disk? Getting everything from the disk may be difficult. But if he just wants to know if one particular file exists on the disk, it may be simpler.
As far as I know, opening the volume should be as hard as breaking the used encryption, unless..
I haven't seen a formal proof of that. And unless somebody tried to give a formal proof, then it is likely there is some subtle weakness which has not yet been spotted.
Wouldn't that mean that the encryption used was weak in the first place?
Yes, but until a month ago TrueCrypt was really that weak. Can somebody provide a proof that it is no longer weak?
In any case, to me it seems that the main concern with all disk encryption is precisely theft of a disk
Yes, but there are a few additional concerns. What are the characteristics of the physical media. Could it for some reason leak a few informations about what was in some of the sectors at an earlier point in time. What about a disk that was stolen an soon recovered again?
Won't there always exist attacks against any practical scheme?
It depends on your definition of attacks and practical. Serious research in the area operate with different kinds of access to the encrypted media. The weakest attack is the one where the adversary is just given read access to the media once. The strongest attack is one where the adversary controls the media and sees all writes, and decides what the media replies to all reads. They correspond to different scenarios namely the case of theft of an encrypted disk, and encrypted storage on an untrusted server.
With the recent improvements of TrueCrypt, it may already be secure enough for the weakest case. It clearly is not secure enough for storing the container on an untrusted server.
I say it may be strong enough because I haven't seen any attempt at formally proving this. Of course a formal proof would be nice. If I see one and is able to verify it, I will immediately start recommending LRW mode.
What is practical is not an easy question. Most existing implementations use a mode that does some kind of 1:1 mapping between logical and physical sectors. This does not give any significant cost in storage or I/O performance, and the CPU requirements is acceptable for many situations. I'd say this is practical.
Anything more complicated than such a 1:1 mapping have an additional cost in I/O performance. The additional CPU requirements does not appear to be much of a problem. GBDE has something slightly more complicated than a 1:1 mapping, and still it seems some people find it practical. I would have done a few things different from GBDE, but one of the modes I could come up with have same I/O patterns as GBDE and use a similar amount of CPU power.
But GBDE may have a problem with atomicity. And it still only focus on the theft scenario, it has no protection against a general passive attack or an active attack.
Most of the problems can be solved using journaling and various tree structures. Those are things that already exist in file systems, and as such I'd say they are practical from an I/O perspective. And the CPU requirement wouldn't have to be more than a factor of two compared to just encrypting each sector.
But that doesn't mean it is trivial to do. Because what I have mentioned here is a lot of layers which would each contribute to the performance overhead. Together it may turn out to give a too poor performance to be practical.
The layers could be integrated in a way that means you only need journaling in one place, and the trees used by the disk encryption closely match those used by the file system to avoid additional seeks. The problems with such an approach are that first of all it is no longer a general purpose disk encryption. Being tied to a particular file system means it should rather be considered an encrypted file system. But what I think is even worse is the fact, that it is a nightmare to provide a formal analysis.
Maybe somebody can come up with a good abstraction to built on top of a block device which is simple enough to encrypt and analyze, but OTOH sophisticated enough to provide all the journaling and tree structures needed by a file system.
Another problem with all of these models is, that no attempt is made to hide access patterns from an adversary monitoring the media. If the adversary knows which physical sector numbers you read and write, he can deduce which logical sector numbers you access. Currently the most efficient solution I know for this problem involves caching all of the data in RAM.
I'd say TrueCrypt is secure enough for many tasks, such as storing illegal downloads
Maybe it is now. But with the possibility of watermarking it wouldn't have been secure enough. How long before producers of for example software started watermarking it such that it could be recognized on an encrypted media?
but if you are going to do that then you have the responsibility of maintaining a proper transaction log.
That is just one possible solution. There are simpler ways to solve the problem, for example you could just mirror the shared sector. You'd need to add a bit of redundancy to find which one is correct. So you might end up with only 31 logical sectors rather than 32 for each 33 physical sectors. But at least you preserve locality.
If you do not do this, then at the end of the day your pseudo-disk isn't actually ``a disk'' since it breaks the atomicity requirements the higher level fs code, DBs, etc. assume that disks present.
What are the exact gurantees that disks give you? What requirements does the higher levels have? Atomicity is a pretty strong property. Does disks really give you this? Having random garbage in the sector being written the very moment power was turned off sounds more likely. Maybe that is not acceptable, but then a harddisk can do some "magic" internally to give better guarantees than what you get from the physical media.
Of course a disk encryption not paying attention to this will give something worse to the higher layer than what it was given by the lower layer. But OTOH with some redundancy and integrity checking, you can go from a single corrupted sector to an atomicity guarantee. A disk encryption doing this could provide better guarantees to the higher layers.
The big question is, how do we do this in a way that is I/O efficient and using as little space as possible?
It would be great if someone translated it for those of us who speak only English and French.
You didn't trust me before, so would you trust that I gave a correct translation? Only English and French? You do read C don't you? In one of the comments you will find a small C program generating some of the watermarks. You doubted that I had found the problem back then. The fact that I did post a program demonstrating the weakness should be enough to prove that I knew about it.
In case anybody wonder about the text in that posting, it says that this is pretty simple, but it doesn't seem to work yet. But when I have more time I will try to modify TrueCrypt enough to make it compile with gcc, so I can see what happens. Further investigation showed, that the watermarks did in fact work. I had just been XORing the wrong encrypted sectors thus not noticing the patterns.
you told about the weakness only to "a few users" (instead of the developers)?
I told it to those who were asking the question.
If you say you found it five months earlier, then I wonder why you did not contact the developers to tell them to fix it?
Because I had more important things to do (like finishing my PhD dissertation on disk encryption). And I didn't really care much as I couldn't use the software myself, since at the time it would only work on Windows. I did tell about it to a few users of the software. Apparently they didn't care enough about the problem to contact the developers.
I know by experience how hard it can be to get people admit that there is a security problem in some software they wrote. At that time I just didn't feel like spending much time on it.
Finally I must say, that although the situation has been improved, it is still deterministic. It has been proven that there will always exist attacks against such a scheme. And I found it much more valuable to continue my research on how to do something more secure.
You should prove what you say
Just read this thread on google groups.
IMO, you are probably just another liar.
That statement says more about you than about me.
I guess you will also somehow "accidentally" forget to mention on your site that the watermark attack does not work anymore
Nowhere on my site is it said, that TrueCrypt is still vulnerable (or even that it ever was). Do you think TrueCrypt is the only encryption which has been vulnerable to this attack? The first time I looked on cryptoloop for Linux (in February 2002), it was vulnerable to the exact same attack. I have mentioned two implementations that apparently independent of each other had the same vulnerability. That means there is a significant risk that some of the many other disk encryptions are also vulnerable.
The file I provided contains not just one watermark but a lot of them. There are a few minor variations with byte ordering, padding, and cipherblock sizes. It is convenient to be able to test an implementation without knowing these details beforehand. The file can still be used to perform such tests. (Of course passing this test doesn't prove an implementation is secure, but failing does prove it is weak).
You are right. I just noticed that. I found the problem back in June when somebody asked me about the security of TrueCrypt. I haven't paid that much attention to TrueCrypt development in the meantime, because back then it could only be used with Windows. The fact that TrueCrypt appears to be bit more secure than it was back then and that it can now be used on both Windows and Linux means that maybe we should start paying more attention to it. At least I'll take a closer look on the mode being used. It is still deterministic and provides no integrity, but maybe it is strong enough for some scenarios.
He seems to have a relevant worry about the lack of atomicity when writing to a GBDE encrypted device. However he fails to notice that this happens only because GBDE has addressed a problem which every other disk encryption seems to have ignored. You get certain security advantages from probabilistic encryption. But probabilistic encryption implies the encrypted version must be slightly larger than the clear text.
More than once has the use of deterministic encryptions lead to weaknesses in disk encryptions. And often the workarounds require additional CPU power. And even the most careful deterministic encryption can never be as secure as a probabilistic encryption.
GBDE does have probabilistic encryption. This also means that obviously an update requires more than one physical write. Though this could be done securely, the way it is done in GBDE seems to give a risk of data loss/corruption. Some kind of journaling could have solved the problem. Having journaling both in the encryption and in the file system seems to be overkill (and clearly hurts performance), but integrating the two without compromising security is nontrivial. I'd like to see some more research in this area.
From my description it may sound like from a cryptographic viewpoint GBDE is the best designed disk encryption in existence. Unfortunately it isn't so. It did get some things right, but it seems to be mostly by luck. GBDE uses different pseudo random keys for each sector, however rather than using a standard PRNG, PHK decided to invent his own known as the Cherry Picker. Unfortunately there is a weakness in this generator as the output is not uniformly random.
To the best of my knowledge GBDE is currently the only disk encryption making use of probabilistic encryption, and none of the disk encryptions in existence make a serious effort at guaranteeing integrity (also known as security against an active adversary).
I took a look through the list of new features in TrueCrypt 4.1, and apparently it has been improved to avoid watermarking attacks. So my previous comment only applies to volumes created with TrueCrypt 4.0 and earlier. I have not looked through the documentation and source to verify how secure the new mode is.
I have not examined Truecrypt further, but I can imagine that there could be more cryptographical mistakes.
There are other mistakes. TrueCrypt use the sectornumber for IV, which makes it vulnerable to watermarking. I mentioned this in another comment. This problem violates the plausible deniability mentioned by Futurepower.
Slashdot Mirror
you could come up with a list of N bad passwords check them against all the passwords you have in O(N+M) time
No, you cannot do that. Each password is hashed with a different salt for exactly this reason.
Can't they just make a button during the install that you can press to get 'illegal' software. The button could read: 'I want to play mp3 files and I don't care if it's illegal. I take full responsibility for my actions.'
Like if that wouldn't get them into trouble. Better warn people that the software is only legal in some countries, and provide them a question similar to this: Have you verified that using this additional software is legal in your country of residence? Yes/No.
Yes, this is one of the great things about yum. There is a simple and clean way to have installation and upgrading of base software and third party software managed with a single interface. Livna is not the only such repository, personally I'm quite happy with freshrpms. Probably there are more.
I don't know if Ubuntu have something similar, but I guess they have.
I have seen how this is handled on Windows, I have seen how this is handled on Red Hat Linux, and I have seen how this is handled on Fedora Core. And except from the problem with rhn-applet being totally broken in FC4, I like the way it works in Fedora. I hope that has been fixed in FC5 (or FC6) or at least replaced with some alternative.
Would have to prove that while in flight, there was no way the key could get lost, or changed, or ...
Proving that isn't going to be any harder than proving whatever other destruct mecanism you could come up with wouldn't get triggered unintentionally. Besides even if the key is kept safe, there are so many other things that could go wrong. Who cares if the key is safe in case the system accessing the data breaks down in unpredicted ways, which is much more likely to happen than a problem with the encryption itself. Finally in case of a scheme involving encryption and destruction of the key, it is possible to store a backup of the key in a safe location (that is not on the plane). In that way even if the key was destructed, you still have some chance of recovering the media and decrypt contents.
The only problem with the encryption solution is, that storage encryption is significantly more complicated than most people think. Sure if you can accept some minor leaks, you can do something fairly simple and efficient. But if very high security is a requirement, I would worry about weaknesses in the encryption modes.
If Linux succeeds in displacing Windows, you will start to see non-free versions of it appear. Versions with enough modification that the "free" part is no longer the significant portion of its value. And the free versions will be obsoleted by their remnant bugs.
GPL is not BSD.
It would be possible, but an unofficial tld just won't get as much attention. I don't think many companies would want to buy a domain which the majority of the users don't know how to access, and they couldn't even be sure to get the official domain if xxx ever becomes an official tld.
If one company actually manages to make money from an unofficial xxx tld, I guess others will follow. Now we could have a handfull of companies selling the same domain, and anybody who wanted to be sure, would have to buy it from all of them. And even that wouldn't guarantee, that they would be able to get it under the official xxx tld, if that is ever going to happen.
Probably some of the alternative DNS roots are going to pick it up. Maybe some of them already have their own xxx tld. This is just going to add even more to the confusion.
What would happen if Debian, Mozilla, or Samba (for example) said "our license doesn't require us to fix any bugs, and we just don't feel like it".
Most likely someone would fork the project. The projects you mention are so large, that most likely a lot of the current developers would move to the fork, if the current project didn't progress. (Didn't something like that more or less happen to XFree86?)
Of course if a fork already exist, developers may just choose to contribute to that fork rather than starting a new one. If it was a small project, that stopped development, it might die. But that only happens if nobody care about it anyway, as long as somebody care enough about it, they can continue development. That is the whole point about open source.
Programmers who think their little pearls of code are what makes a project successful need to get over themselves.
If you find it so useful, that you had in fact already decided to use it for something important, you really ought to give the credit for what they have already done. I'm pretty sure you already got more support than you have been promised. If you decide to rely on getting support for free, you are really to blame. In short it is not the developer who overrated the project, it is the user who for whatever reason had far too high expectations.
I may tell people about some of my own projects, if they have a problem for which it may be usefull. But I sure as hell never promise that I will support it. Sure to some extent I have done so anyway, but I always make it clear that I don't make any promises.
I promote other peoples open source projects much more often than I promote my own projects. And I do so because I have found them useful, or because I know they have been useful to others.
That was when I discovered Internet Explorer shrunk images to fit the browser window.
If the image is a photography, people do want it fit to the size of the window most of the time. OTOH with a screenshot it is plain annoying. So the best the browser could do is to offer an easy way to switch between the two ways of handling images.
Sometimes on webpages I do see screenshots, which have already been downscaled. Such screenshots are mostly useless. If anybody want to put some smaller screenshots in a review, the correct approach is to configure the system to use a smaller resolution, and then take the screenshots. Or just do the whole thing using Xnest or anything similar.
Microsoft blames the lack of sales on Open Source Operating Systems.
Would be interesting, but I doubt that is going to happen. It could be interpreted as admitting open source software is better than Windows. Microsoft don't want to do that. I think they'd rather put the blame on unauthorized copies.
Fedora makes security transparent to the user, you're running SELinux but would never know it unless you needed to, you're running exec-shield but you'd never know it unless you needed to /.autorelabel and reboot.
/etc/bashrc is going to change it to 002. That means anything started from a script using bash as interpreter is going to create files with other permissions than intended.
But occationally it gets the file labels fucked up causing things to stop working. The Fedora people refuse to acknowledge there is a bug, after all you can just touch
all the major services are compiled to randomize memory mappings, but the user is none-the-wiser.
If you had actually been using Fedora since FC1, and you happened to be using it on a 586 architecture, you would have found out. Because for some reason they decided that on that architecture they would compile glibc with some options making it pretty picky about the location of the stack. This caused programs to crash at random, and the bug was never fixed. They simply wouldn't accept, that there could be a bug in glibc.
I can install Fedora and be fairly certain that even if somehow my system stopped updating
Actually that is not so unlikely to happen. Because on FC4 rhn-applet will always tell you, that there are no updates available. And occationally yum will also say that even when there are updates available. And the Fedora people does not consider this to be a bug.
And while we are at it, do you know what happens to the umask on a Fedora system? If I decide to set my umask to 077 such that other users cannot read by default, then
I'm not saying Fedora is a bad distribution, after all I do use it on all my systems. You just shouldn't claim it to be so much more secure than other distributions. Yes, this bug in Ubuntu is very bad, but unfortunately they are not the first to introduce a bug that bad.
If you look on this just as an IT story, it is just yet another distributed computing project. But if you are interested in history, it may be different. The messages themselves may be of historical interest, we can't know for sure before they have been decrypted.
There are at least five types of severe attacks on correctly implemented CBC (one of which allows full recovery of secret plaintext without any knowledge of any part of the key).
I don't know why I should believe you. I have seen and verified the proof for security of CBC under the assumption that the cipher is indistinguishable from a random permutation. If that assumption does not hold, then tweakable ciphers does not work either. And even the incorrect implementations of CBC does not allow full recovery of an unknown plaintext.
Of course this is all assuming passive attacks. Neither CBC nor LRW is secure against active attacks. If you want security against an active attack, you need stuff like hash trees and message authentication codes.
You do your homework.
If you had done your homework you would have come across two articles on the subject which give different proofs why LRW cannot satisfy the strongest security definitions. They are both available on eprint.iacr.org one is written by Kristian Gjøsteen, and I'm coauthor on the other.
The proof of security applies to LRW-AES as well (because it is a tweakable cipher).
The proof applies to the cipher, not the mode. The way the cipher is used in TrueCrypt does not correspond to any of the modes in the paper you linked to. The paper also states that TAES is expected to be 50-80% slower than AES. Why not use AES in CBC mode? (Here I mean a correct implementation of CBC, not the one with a deterministic IV).
The paper you link to is an interesting read on Tweakable Block Ciphers. But it mentions neither LRW mode nor disk encryption.
Now, while a lot of people have all kinds of spyware festooning all over, these are not the people who would know what Truecrypt is, anyway.
..
If you are unable to protect your computer from spyware, then disk encryption is not going to help much anyway.
A Truecrypt user is also likely to have the media in question reasonably sealed off from network access.
Some disk encryptions actually state that you can keep the container on a different computer and access it using some networking file system. I have not yet seen a disk encryption which was secure enough to be used in that way. I don't think TrueCrypt claims to be usable in that scenario. But even making a backup of the container could be dangerous.
Now, suppose that an attacker gets a copy of a volume and walks off with it, how strong an attack can be made?
How much information does he need to get from the disk? Getting everything from the disk may be difficult. But if he just wants to know if one particular file exists on the disk, it may be simpler.
As far as I know, opening the volume should be as hard as breaking the used encryption, unless
I haven't seen a formal proof of that. And unless somebody tried to give a formal proof, then it is likely there is some subtle weakness which has not yet been spotted.
Wouldn't that mean that the encryption used was weak in the first place?
Yes, but until a month ago TrueCrypt was really that weak. Can somebody provide a proof that it is no longer weak?
In any case, to me it seems that the main concern with all disk encryption is precisely theft of a disk
Yes, but there are a few additional concerns. What are the characteristics of the physical media. Could it for some reason leak a few informations about what was in some of the sectors at an earlier point in time. What about a disk that was stolen an soon recovered again?
Won't there always exist attacks against any practical scheme?
It depends on your definition of attacks and practical. Serious research in the area operate with different kinds of access to the encrypted media. The weakest attack is the one where the adversary is just given read access to the media once. The strongest attack is one where the adversary controls the media and sees all writes, and decides what the media replies to all reads. They correspond to different scenarios namely the case of theft of an encrypted disk, and encrypted storage on an untrusted server.
With the recent improvements of TrueCrypt, it may already be secure enough for the weakest case. It clearly is not secure enough for storing the container on an untrusted server.
I say it may be strong enough because I haven't seen any attempt at formally proving this. Of course a formal proof would be nice. If I see one and is able to verify it, I will immediately start recommending LRW mode.
What is practical is not an easy question. Most existing implementations use a mode that does some kind of 1:1 mapping between logical and physical sectors. This does not give any significant cost in storage or I/O performance, and the CPU requirements is acceptable for many situations. I'd say this is practical.
Anything more complicated than such a 1:1 mapping have an additional cost in I/O performance. The additional CPU requirements does not appear to be much of a problem. GBDE has something slightly more complicated than a 1:1 mapping, and still it seems some people find it practical. I would have done a few things different from GBDE, but one of the modes I could come up with have same I/O patterns as GBDE and use a similar amount of CPU power.
But GBDE may have a problem with atomicity. And it still only focus on the theft scenario, it has no protection against a general passive attack or an active attack.
Most of the problems can be solved using journaling and various tree structures. Those are things that already exist in file systems, and as such I'd say they are practical from an I/O perspective. And the CPU requirement wouldn't have to be more than a factor of two compared to just encrypting each sector.
But that doesn't mean it is trivial to do. Because what I have mentioned here is a lot of layers which would each contribute to the performance overhead. Together it may turn out to give a too poor performance to be practical.
The layers could be integrated in a way that means you only need journaling in one place, and the trees used by the disk encryption closely match those used by the file system to avoid additional seeks. The problems with such an approach are that first of all it is no longer a general purpose disk encryption. Being tied to a particular file system means it should rather be considered an encrypted file system. But what I think is even worse is the fact, that it is a nightmare to provide a formal analysis.
Maybe somebody can come up with a good abstraction to built on top of a block device which is simple enough to encrypt and analyze, but OTOH sophisticated enough to provide all the journaling and tree structures needed by a file system.
Another problem with all of these models is, that no attempt is made to hide access patterns from an adversary monitoring the media. If the adversary knows which physical sector numbers you read and write, he can deduce which logical sector numbers you access. Currently the most efficient solution I know for this problem involves caching all of the data in RAM.
I'd say TrueCrypt is secure enough for many tasks, such as storing illegal downloads
Maybe it is now. But with the possibility of watermarking it wouldn't have been secure enough. How long before producers of for example software started watermarking it such that it could be recognized on an encrypted media?
but if you are going to do that then you have the responsibility of maintaining a proper transaction log.
That is just one possible solution. There are simpler ways to solve the problem, for example you could just mirror the shared sector. You'd need to add a bit of redundancy to find which one is correct. So you might end up with only 31 logical sectors rather than 32 for each 33 physical sectors. But at least you preserve locality.
If you do not do this, then at the end of the day your pseudo-disk isn't actually ``a disk'' since it breaks the atomicity requirements the higher level fs code, DBs, etc. assume that disks present.
What are the exact gurantees that disks give you? What requirements does the higher levels have? Atomicity is a pretty strong property. Does disks really give you this? Having random garbage in the sector being written the very moment power was turned off sounds more likely. Maybe that is not acceptable, but then a harddisk can do some "magic" internally to give better guarantees than what you get from the physical media.
Of course a disk encryption not paying attention to this will give something worse to the higher layer than what it was given by the lower layer. But OTOH with some redundancy and integrity checking, you can go from a single corrupted sector to an atomicity guarantee. A disk encryption doing this could provide better guarantees to the higher layers.
The big question is, how do we do this in a way that is I/O efficient and using as little space as possible?
It would be great if someone translated it for those of us who speak only English and French.
You didn't trust me before, so would you trust that I gave a correct translation? Only English and French? You do read C don't you? In one of the comments you will find a small C program generating some of the watermarks. You doubted that I had found the problem back then. The fact that I did post a program demonstrating the weakness should be enough to prove that I knew about it.
In case anybody wonder about the text in that posting, it says that this is pretty simple, but it doesn't seem to work yet. But when I have more time I will try to modify TrueCrypt enough to make it compile with gcc, so I can see what happens. Further investigation showed, that the watermarks did in fact work. I had just been XORing the wrong encrypted sectors thus not noticing the patterns.
you told about the weakness only to "a few users" (instead of the developers)?
I told it to those who were asking the question.
If you say you found it five months earlier, then I wonder why you did not contact the developers to tell them to fix it?
Because I had more important things to do (like finishing my PhD dissertation on disk encryption). And I didn't really care much as I couldn't use the software myself, since at the time it would only work on Windows. I did tell about it to a few users of the software. Apparently they didn't care enough about the problem to contact the developers.
I know by experience how hard it can be to get people admit that there is a security problem in some software they wrote. At that time I just didn't feel like spending much time on it.
Finally I must say, that although the situation has been improved, it is still deterministic. It has been proven that there will always exist attacks against such a scheme. And I found it much more valuable to continue my research on how to do something more secure.
You should prove what you say
Just read this thread on google groups.
IMO, you are probably just another liar.
That statement says more about you than about me.
I guess you will also somehow "accidentally" forget to mention on your site that the watermark attack does not work anymore
Nowhere on my site is it said, that TrueCrypt is still vulnerable (or even that it ever was). Do you think TrueCrypt is the only encryption which has been vulnerable to this attack? The first time I looked on cryptoloop for Linux (in February 2002), it was vulnerable to the exact same attack. I have mentioned two implementations that apparently independent of each other had the same vulnerability. That means there is a significant risk that some of the many other disk encryptions are also vulnerable.
The file I provided contains not just one watermark but a lot of them. There are a few minor variations with byte ordering, padding, and cipherblock sizes. It is convenient to be able to test an implementation without knowing these details beforehand. The file can still be used to perform such tests. (Of course passing this test doesn't prove an implementation is secure, but failing does prove it is weak).
That problem was fixed one month ago.
You are right. I just noticed that. I found the problem back in June when somebody asked me about the security of TrueCrypt. I haven't paid that much attention to TrueCrypt development in the meantime, because back then it could only be used with Windows. The fact that TrueCrypt appears to be bit more secure than it was back then and that it can now be used on both Windows and Linux means that maybe we should start paying more attention to it. At least I'll take a closer look on the mode being used. It is still deterministic and provides no integrity, but maybe it is strong enough for some scenarios.
He seems to have a relevant worry about the lack of atomicity when writing to a GBDE encrypted device. However he fails to notice that this happens only because GBDE has addressed a problem which every other disk encryption seems to have ignored. You get certain security advantages from probabilistic encryption. But probabilistic encryption implies the encrypted version must be slightly larger than the clear text.
More than once has the use of deterministic encryptions lead to weaknesses in disk encryptions. And often the workarounds require additional CPU power. And even the most careful deterministic encryption can never be as secure as a probabilistic encryption.
GBDE does have probabilistic encryption. This also means that obviously an update requires more than one physical write. Though this could be done securely, the way it is done in GBDE seems to give a risk of data loss/corruption. Some kind of journaling could have solved the problem. Having journaling both in the encryption and in the file system seems to be overkill (and clearly hurts performance), but integrating the two without compromising security is nontrivial. I'd like to see some more research in this area.
From my description it may sound like from a cryptographic viewpoint GBDE is the best designed disk encryption in existence. Unfortunately it isn't so. It did get some things right, but it seems to be mostly by luck. GBDE uses different pseudo random keys for each sector, however rather than using a standard PRNG, PHK decided to invent his own known as the Cherry Picker. Unfortunately there is a weakness in this generator as the output is not uniformly random.
To the best of my knowledge GBDE is currently the only disk encryption making use of probabilistic encryption, and none of the disk encryptions in existence make a serious effort at guaranteeing integrity (also known as security against an active adversary).
TrueCrypt is vulnerable to watermarking attacks.
I took a look through the list of new features in TrueCrypt 4.1, and apparently it has been improved to avoid watermarking attacks. So my previous comment only applies to volumes created with TrueCrypt 4.0 and earlier. I have not looked through the documentation and source to verify how secure the new mode is.
I have not examined Truecrypt further, but I can imagine that there could be more cryptographical mistakes.
There are other mistakes. TrueCrypt use the sectornumber for IV, which makes it vulnerable to watermarking. I mentioned this in another comment. This problem violates the plausible deniability mentioned by Futurepower.