There are games for Linux, maybe not as many as Windows. Personally I don't care. BTW the first time I read a review of a game which required Windows, the conclusion in that article was, that games and Windows just doesn't match. That was around the time when Windows 95 was released, I don't recall if that particular game was for Windows 3.x or 95.
Package management in Windows sucks. Every software package come with its own program for the task, I would hardly call that management. Have you ever tried uninstalling a package on Windows? I have had the need twice during the five months I was working at a company using Windows for the desktop machines. So I uninstall one version of this package and then try to install a different version only to find it failing because parts of the previously installed version were still on the system. On my own machines I use Fedora Core, which have a quite good package management. First of all I can use the same program to manage all installed software. Actually I can choose between rpm and yum, what is very important though is, that the end result is going to be the same, it is not such that using yum would prevent me from using rpm at some later point or vice versa. Verifying if updates are required can only be done when logged in as administrator. That is a regression compared to Red Hat Linux and early Fedora Core versions, but still the same is the case for Windows. I have learned to live with it, and if I care enough about it, I can implement software to solve this problem on my own. What is great about Fedora Core is the release packages, which list repositories. That makes it possible to use third party software like if it was part of the distribution itself. Just install the release package for a third party repository, and available packages from that repository will show up, and they will even get updated along with everything else.
My computers have no problem detecting and configuring hardware automatically as it is plugged in. I don't know what distribution you are using, and how you configured it, to get such problems. And as for driver support, there are vendors, who do a hard job ensuring their hardware will not work flawlessly with Linux. I can only recommend avoiding such vendors.
mp3 have always been patented, at some point every distribution had mp3 players. But the patent holders changed the licensing, which essentially made it incompatible with free software. That is why you see many distributions without. Luckily you can usually get it from third parties. Would be nice with a distribution based in a country where such patents are void.
This is where salt comes in and makes hash tables worthless.
And what exactly would you use for salt? If you don't use the same salt every time you see a particular IP, it will no longer be possible to compare it for equality. And if you can't even do that, then the logged informations are worthless. You might as well say, they shouldn't log it at all. The subject is correct, you cannot hash an IP address in any meaningful way.
GBDE can be watermarked by traffic analysis as easy as any other disk encryption software.
You can tell the access patterns. But unless you break either AES or the PRNG there is no way to distinguish the data. (Besides that access patterns in GBDE are hidden slightly better than many other storage encryptions. But the difference is not large enough to really rely on it). Cluster sizes are not important because GBDE does probabilistic encryption. (And is AFAIK the only storage encryption to do that). TrueCrypt is deterministic and you can create data which are easilly watermarked. Older versions could be watermarked after a single write by simply having two neighbour sectors where data differs in the same bit positions as the IV. Newer versions requires multiple writes to be watermarked. Write twice to the same sector changing only a subset of the 32 cipher blocks. Those attacks will not work against GBDE, neither will anything similar.
If it's not 1-to-1 mapped, it's not really transparent.
It is transparent to the file system and any application running on top of that.
GBDE does NOT prevent traffic analysis. You can prevent water-mark attacks based on traffic analysis only by massive relocation of sectors during write operations. In software, this can be hardly real-time.
There is a difference between leaking the sequence of locations accessed and the actual data. Avoiding leak of the data is clearly feasible. If you also want to hide the locations it does get tricky. Some relocation would be necesarry, and I don't think you can avoid a significant number of extra seeks. On a harddisk there might be no feasible solution (unless you have RAM enough to cache most of the data). But on flash storage where there is no seek cost, I believe it is feasible. I could give you a solution that would require 2-3 times extra disk space and 2-3 times extra I/O. But then it also does wear leveling for you. Probably the best solution would be achieved by intgegrating the encryption with the existing wear leveling. But I'm no expert on weak leveling (only know the basics).
If you rewrite a block somewhere on a disk, you MUST rewrite the entire sector.
Yes exactly, and if all other blocks in the sector remains unmodified, that would be visible in recent versions of TrueCrypt.
Moreover, clusters are the smallest accessible unit on normal file systems. A cluster is usually 4K or more.
Typical sizes on the file systems I know about are in the range from 512 bytes to 4KB. FAT 16 is the only file system I know about which would use larger units unless explicitly told to. So it is correct, that a 1-1 mapping of 512 byte sectors still could leak 8 bits of information (which is significantly less than the 128 bits with TrueCrypt). In this is one of the reasons why I suggest something stronger. Of course you might also reconsider the size of the units handled by the storage encryption.
You keep writing in multiple posts that there are easy solutions to this. I haven't seen anything concrete so far.
Just use a probabilistic encryption. CBC mode is one possibility. (And when I say CBC I don't mean the flawed implementation used by many storage encryption products, including older versions of TrueCrypt). It does mean that a 512 byte sector grows to 528 bytes, GBDE shows how the additional data can be placed on the disk. Another possibility is to use tweakable block ciphers, but extend the tweak with a counter. Each sector needs a small counter, the overhead can be less than the 16 bytes for a CBC mode.
I could as well start claiming that all crypto including AES-256 can be cracked in 1 second.
Yes you could as well start claiming that. You wouldn't be the first AC to make that claim.
If the spooks grabbed my HDD they would be unable to perform this attack without the password.
Of course it can be performed without a password, otherwise it wouldn't be an attack. Whether it can be done after just getting hold of the HD depends on a few factors. If the HD have remapped some sectors it may be easy to find two sectors to use for the attack (if the physical storage was flash rather than HD, the wear leveling would help performing the attack). It also depends on whether you use a partition or a file as your backing storage. If you use a file, the file system could have moved it to a different location. It might be that you had defragmented the file system.
But since you bring passwords into the discussion, I might as well say a few words about the password protection. I have not yet seen a product which offers a secure way to change password. Of course you can create a new encrypted container using the new password and copy all the files, this would be secure but inefficient. Everything I have seen with a more efficient way to change password will reuse the old key and just reencrypt it under a different password. In other words, the old password can be used to decrypt new data if you can somehow find the old encryption. There are solutions for this, but they are a bit complicated. Until somebody actually implements this, my recommendation is to newer change password on a container and instead create a new container with a different password.
These wide-block modes are as vulnerable as narrow-block modes.
You fail to distinguish between using additional disk space and using additional CPU time. It appears 1% of extra disk space usage can give you more security than 100% of extra CPU time usage.
As long as you are only willing to pay a price in CPU time, it is true that you will only get better granularity. But a factor of 32 on the granularity may very well be worth the effort, in particular if you could get the granularity above the units allocated by the file system at which point attacks will start to get more complicated. Rewriting a sector which is completely identical does not happen nearly as often as rewriting a sector where some 16 byte blocks are identical.
However if you are willing to pay a price in disk space, you get a security improvement which is better than just a change in the granularity of the units on which the attack could work. Even if exactly the same data were written, the encryption would differ.
It is possible to do even better than this. You can even hide the sector numbers by having a dynamical mapping between logical and physical locations. But such an encryption would require a larger overhead and might not be feasible on media where seek times have a significant cost.
If there are feasible solutions to this
There are.
then why does no disk encryption software use them?
Don't ask me, I didn't write that software. (You could read the article, it actually suggest one possible reason. The users cannot tell the difference between good crypto and bad crypto anyway).
The two attributes "transparent" and "real-time" rule out any solution that is not 1-to-1 mapped.
GBDE have proven you wrong a long time ago, it is transparent and does not use such a 1 to 1 mapping. Besides why do you think the 1 to 1 mapping is necesarry on the encryption layer when both the layer beneath it (firmware in the storage device) and the layer above it (file system) can use something more complicated than a 1 to 1 mapping?
If there was a solution, then PGP Whole Disk or PGPDisk would have used it.
You seem to belive the authors of that product know everything. I don't know how you got that idea.
But no, they are as vulnerable to the attack as TrueCrypt.
Vulnerable to some kind of watermarking? Probably yes. As vulnerable as TrueCrypt? Not necesarilly, methods a little more secure than what TrueCrypt does have been known for years, but they usually require twice as much CPU time.
Because there is no feasible solution to this (other than re-encrypting the whole disk every time a bit changes).
You are wrong. All it takes is a litle extra disk space. Take a look on the disk layout used by GBDE to see one way to handle this.
In recent versions of TrueCrypt, the encryption is performed using tweakable block ciphers in way that reuse tweaks. When a sector is written, a sequence of 32 tweaks is used for each 16 byte cipher block. If this sequence was used only once, the encryption would have been as secure as the underlying cipher. However the same sequence is used every time a write is performed to the same sector. Thus by looking on two encryptions of the same sector, you can tell exactly which of the 32 cipher blocks have been changed. In other works carefully designed watermarks might leak close to 32 bits for each such pair.
There are modes which use twice as much CPU time and only allow detecting if the complete sector is identical to an earlier write. Even more secure solutions using a few percent extra disk space could avoid this weakness entirely.
Any efficient 1-to-1-mapped disk encryption software (not just TrueCrypt) is subject to "water mark" attacks based on comparison of re-encrypted blocks.
That is absolutely correct. In fact you didn't even have to use the word efficient here. Any 1-to-1-mapped encryption is subject to such attacks. The point is that if you are willing to sacrifice a few percent of disk space, you can improve security.
One encryption sacrificing about 3% of disk space is GBDE. Unfortunately GBDE suffers from a few other problems. The author designed his own weak pseudo random number generator. And GBDE does mean you have a risk of loosing data as the consequence of an incomplete write.
Those problems can be solved, and the overhead could be reduced from 3% to 1%. And I believe this can be done at only a few percent of cost in performance, though I don't yet have the complete solution, I'm pretty close.
I agree TrueCrypt is well documented, and in addition to that the source is available. I have the necesarry knowledge to actually review such a design, and in the case of TrueCrypt I must say it is not the worst I have seen, but it is certainly not perfect either. There are some subtle watermarking attacks if you can get access to different encryptions of the same sector. Still in spite of that I'd much rather rely on TrueCrypt than some closed source products. So far all storage encryption products I have seen have had some weakness, I'd much rather use one where I know what it is and to what extend it could be a problem to me.
That has been explained a few times already in this thread. You obviously cannot see it for the current image, but hold the mouse over any of the previous images and you will see it.
I guess a porn only version might become so popular that there was no users left for the standard version. After playing a number of times I saw only one image which might be classified as porn. It was a picture of Christina Aguilera naked. My partners guesses were: bitch, fuck, blow aguilera. I guess he doesn't like Christina Aguilera.
It is not a major problem. First of all to exploit it, you'd have to generate a collision and have one of the two versions accepted in mainstream. Second you'd have to get the wrong version onto some user's machine before the correct version. Linus explained this in a posting somewhere after the original SHA-1 weakness was published. And though Linus AFAIK does not have any education in cryptography, he has demonstrated, that he clearly knows how to apply cryptographic primitives in a sound way. I have a PhD in cryptography, and I have read about the design of git, and I did not spot any weakness.
For now though from a theoretical viewpoint this is a major weakness, it still requires way too much processing power to be realistic. And the way git is designed, I don't think it is going to be any major problem switching to a new hash once cryptographers starts to agree which one should be considered secure in the future. Once they start using a new hash, you can actually still safely use old repositories based on SHA-1. Because once there is no longer being added new data based on SHA-1, a collision is no longer enough to perform an attack, rather you need a second preimage, something which there has not yet been demonstrated an efficient way to produce.
If it fills ALL the free space on the drive, then pigeonhole principle says the cells you wanted to overwrite were overwritten.
The point is, that the size of the media depends on what level you are looking at. The wear leveling requires some extra physical space (I don't know how much), so the logical size which the USB unit reports to the system is smaller than the physical flash size. This means if you overwrite all sectors on the logical layer seen by the computer, you have not overwritten all of the physical storage.
Does someone here know how large is the physical flash on a 512MB usb stick? Are we talking about 640MB, 1GB, 2GB?
TrueCrypt no longer uses CBC in the latest versions, LRW mode has been the default mode since some time in the 4.1 version and beyond.
I compared the encryption used by TrueCrypt to CBC, that is very different from saying TrueCrypt uses CBC. In fact what TrueCrypt used to use is the not quite CBC mode you get by replacing the random IV with the sector number. The new mode did eliminate the very easy fingerprinting, but introduced a different kind of fingerprinting possible as long as you could get multiple versions of the same sector. A real CBC mode would be more secure than both of them, but a bit unpractical.
And if you carefully read my description from before, you should recognize, that it is the mode known as LRW. I don't like the name of that mode, because to me it looks like this mode was invented by someone who read the article by Liskov, Rivest, and Wagner but did not fully understand it.
For example CBC with fixed IV leaks more, possibly even a file fingerprint.
Indeed, it is easy to construct a file which is easilly recognized after being encrypted with such a scheme. In fact I constructed one a long time ago, it is here. (OK this file only applies to some of the weakest IVs, but you get the point). However LRW also allows fingerprinting, but only if you can get two versions of the encrypted sectors, one version with the file, and another version with zeros.
Personally I would be content with only having leak out when a sector holds identical data as before.
Might be acceptable for most users, but as I pointed out earlier, the algorithms I know for this have a significant CPU overhead. If you know a solution for this without the performance penalty, I'd very much like to hear about it.
Either you sacrifice atomicity. Or you do a 2-phase commit or the like and risk a major performaance impact. Or you sacrifice sector size (and store the extra data in there)
Or you come up with a clever combination of the different algorithms. Actually I don't know exactly what a 2-phase commit is, but a possible approach goes as follows. You consider the disk as a number of regions where each region consist of 200 data sectors and a metadata sector at each end. The metadata contains a 16 byte tweak common to all sectors in the region and a 16 bit counter per sector. The two are concatenated with the sector number to construct a unique tweak.
Now you can update the first metadata sector, then update any subset of the data sectors, and finally update the second metadata sector. You get two extra writes no matter how many of the sectors you updated, and you essentially don't get any extra seeks. And for each sector at least one of the two metadata sectors will be usable. You will have to duplicate the least significant bit of the counter into the data sector so you will know which meta data sector to use. That lost bit will easilly fit in the meta data sector. And there is enough space left over in the meta data sector to do a probablistic encryption of the meta data sector.
There are a few drawbacks, for example you need to reencrypt the entire region each time a counter wraps, but the ammortized time required for that is insignificant. You can do the structure kind of recursively to avoid most of the full region reeencryption. The only problem left which I don't have a complete solution for yet is, that each write operation would have to start by comparing the two metadata sectors to know if a recovery is required.
There, now also shown independently by Gweihir.I never said the proof was complicated.;-) Yet some people claim algorithms not using the extra space to be more secure than a probabilistic encryption. So apparently some people are unable to prove it.
You see the letters appear the instant they are typed
Start emacs under X11 execute the make-frame-on-display command, there you go. Though I must admit emacs does leave a few things to be desired in this area. It doesn't work in text mode only in X. And keep your hands off the mouse while collaborating. And if one window is closed in a not so nice way, it will quit which means all windows close.
If those three things were fixed you could keep an emacs running in text mode under screen and fire off make-frame-on-display commands as needed.
I assume this is actually aa problem of tweakable block ciphers?
Not really. If you just used an ordinary cipher instead of a tweakable cipher, the problem would be much worse. However using an ordinary cipher in CBC mode does not have this problem. CBC is a probabilistic encryption, which means same data encrypted more than once will produce different data. But this also means data grows, which is inconvenient for a transparent storage encryption.
Tweakable block ciphers is an elegant solution for this problem. But it is no magic bullet. If you reuse a tweak, it is no more secure than an ordinary cipher. And even if you don't reuse a tweak you still cannot use it more times than the birthday limit imposed by the block size. (AFAIR the number of times you can safely reuse a tweakable block cipher is two or three times less that of an ordinary cipher).
You could actually replace the cipher in a CBC encryption with a tweakable cipher and get something slightly safer. But the quite common practice in storage encryptions of replacing the random IV in a CBC encryption with a deterministic value is always going to be insecure. The extra space is provably necesarry (shown independently by Kristian Gjøsteen and myself).
It is possible to come up with ways to generate the tweak in a way that requires less disk space than the random IV for CBC encryption. So for that reason tweakable ciphers is clearly an interesting way to do storage encryption. But as soon as you have a space overhead, however little it may be, you have a problem with atomicity of updates. That means you are going to need extra copies of some of the data to avoid data loss in case the system for whatever reason doesn't complete an update. But you could still have significantly less overhead than the random IV for CBC encryption. CBC would usually be 3-6% overhead, a clever system designed using tweakable block ciphers could use less than 1% overhead. Now if I could just come up with an efficient way to detect the need for recovering an incomplete write....
Otherwise the simple attack on any sector-based encryption would be to read the raw data at different times....
Unfortunately most sector-based encryption schemes does have such a weakness. The impact of the weakness may differ from the worst encryption leaking everything to the best encryption leaking only the sector number of writes and when a write is identical to something that earlier existed in the same sector. TrueCrypt is somewhere between these two extremes. The best deterministic encryptions I know of requires approximately twice as much CPU time than the more secure probabilistic encryptions.
Choose erease free space after installing. This will fill the remaining space on the drive with files, then overwrite them to the security level you choose.
I agree this will add a little bit of security. But as this happens on a higher layer than the wear leveling, there is no guarantee that it will actually overwrite the physical locations you are interested in overwriting. Of course if you do multiple passes, I'd expect the wear leveling to spread them evenly over all locations including the ones you needed wiped. And BTW you don't need any unfree software to do it, you can just create a file filling all free space and then use the wipe command.
Is there any spec's on what encryption type/standard U3 is using?
That is indeed a very relevant question. If you come across an encryption were such a specification is not available for anybody to read, assume it is because the encryption is no good. If the specification is too vague and only states the name of a block cipher being used such as AES and doesn't tell you in detail what mode it is using, I'd also avoid it. And if it ever states anything like military strength encryption, I'd avoid it. TrueCrypt is one of the best documented storage encryptions I know about.
TrueCrypt makes use of tweakable block ciphers. The idea with tweakable block ciphers is good, but it is no magic bullet. And unfortunately TrueCrypt reuse the tweaks every time the same sector is overwritten, which means the proofs for security of tweakable block ciphers does not apply to TrueCrypt. Depending on the attack scenario this may a threat. Using a USB stick is going to make this problem worse.
It is not the USB protocol which is a problem, but rather the fact that a USB stick store the data in flash using a wear leveling algorithm. That means that even though from TrueCrypt's point of view it is writing to the same sector number, it is physically writing to different flash cells. This again means, that for some time both the old and the new version may physically exist in the storage. This means anybody who are able to read the physical flash cells without going through the wear leveling code will have access to the necesary data to exploit this weakness.
I don't know anything about U3, so I cannot tell you for sure if it is better or worse than TrueCrypt. But with the number of weaknesses which have been seen in storage encryptions, I'd expect anything new to have a few of its own. In spite of the minor weakness in TrueCrypt, I'd still perefer that over something with weaknesses I don't know about.
My advice for encryption on USB sticks is to not rely on transparent encryption and rather use something like GPG. Of course combining TrueCrypt and GPG is not going to harm security. GPG encrypted files on a TrueCrypt encrypted storage should be pretty safe.
My parents had a PC where the printer would report "input jam" whenever trying to print anything. Interestingly it printed just fine when connected to my Amiga. To make matters even more strange, it was unable to even print a testpage, if it was connected to the PC.
My thought after seeing those symptoms was, that maybee the PC was infected with some kind of virus. However even when the PC was turned off, the printer couldn't print a test page, only when the printer cable was disconnected could it print.
The printer was still covered by waranty and was sent for a repair, and the paper tray was switched, which solved the problem. How a defective paper tray would only be a problem while the printer was hooked up to the PC is beyond me.
Slashdot Mirror
Since Linus' wife is a six-time Finnish national karate champion, I'd be a little careful about making such jokes.
There is a difference between leaking the sequence of locations accessed and the actual data. Avoiding leak of the data is clearly feasible. If you also want to hide the locations it does get tricky. Some relocation would be necesarry, and I don't think you can avoid a significant number of extra seeks. On a harddisk there might be no feasible solution (unless you have RAM enough to cache most of the data). But on flash storage where there is no seek cost, I believe it is feasible. I could give you a solution that would require 2-3 times extra disk space and 2-3 times extra I/O. But then it also does wear leveling for you. Probably the best solution would be achieved by intgegrating the encryption with the existing wear leveling. But I'm no expert on weak leveling (only know the basics).
Typical sizes on the file systems I know about are in the range from 512 bytes to 4KB. FAT 16 is the only file system I know about which would use larger units unless explicitly told to. So it is correct, that a 1-1 mapping of 512 byte sectors still could leak 8 bits of information (which is significantly less than the 128 bits with TrueCrypt). In this is one of the reasons why I suggest something stronger. Of course you might also reconsider the size of the units handled by the storage encryption.
Just use a probabilistic encryption. CBC mode is one possibility. (And when I say CBC I don't mean the flawed implementation used by many storage encryption products, including older versions of TrueCrypt). It does mean that a 512 byte sector grows to 528 bytes, GBDE shows how the additional data can be placed on the disk. Another possibility is to use tweakable block ciphers, but extend the tweak with a counter. Each sector needs a small counter, the overhead can be less than the 16 bytes for a CBC mode.
Yes you could as well start claiming that. You wouldn't be the first AC to make that claim.
But since you bring passwords into the discussion, I might as well say a few words about the password protection. I have not yet seen a product which offers a secure way to change password. Of course you can create a new encrypted container using the new password and copy all the files, this would be secure but inefficient. Everything I have seen with a more efficient way to change password will reuse the old key and just reencrypt it under a different password. In other words, the old password can be used to decrypt new data if you can somehow find the old encryption. There are solutions for this, but they are a bit complicated. Until somebody actually implements this, my recommendation is to newer change password on a container and instead create a new container with a different password.
As long as you are only willing to pay a price in CPU time, it is true that you will only get better granularity. But a factor of 32 on the granularity may very well be worth the effort, in particular if you could get the granularity above the units allocated by the file system at which point attacks will start to get more complicated. Rewriting a sector which is completely identical does not happen nearly as often as rewriting a sector where some 16 byte blocks are identical.
However if you are willing to pay a price in disk space, you get a security improvement which is better than just a change in the granularity of the units on which the attack could work. Even if exactly the same data were written, the encryption would differ.
It is possible to do even better than this. You can even hide the sector numbers by having a dynamical mapping between logical and physical locations. But such an encryption would require a larger overhead and might not be feasible on media where seek times have a significant cost.
There are.
Don't ask me, I didn't write that software. (You could read the article, it actually suggest one possible reason. The users cannot tell the difference between good crypto and bad crypto anyway).
Vulnerable to some kind of watermarking? Probably yes. As vulnerable as TrueCrypt? Not necesarilly, methods a little more secure than what TrueCrypt does have been known for years, but they usually require twice as much CPU time.
You are wrong. All it takes is a litle extra disk space. Take a look on the disk layout used by GBDE to see one way to handle this.
There are modes which use twice as much CPU time and only allow detecting if the complete sector is identical to an earlier write. Even more secure solutions using a few percent extra disk space could avoid this weakness entirely.
One encryption sacrificing about 3% of disk space is GBDE. Unfortunately GBDE suffers from a few other problems. The author designed his own weak pseudo random number generator. And GBDE does mean you have a risk of loosing data as the consequence of an incomplete write.
Those problems can be solved, and the overhead could be reduced from 3% to 1%. And I believe this can be done at only a few percent of cost in performance, though I don't yet have the complete solution, I'm pretty close.
I agree TrueCrypt is well documented, and in addition to that the source is available. I have the necesarry knowledge to actually review such a design, and in the case of TrueCrypt I must say it is not the worst I have seen, but it is certainly not perfect either. There are some subtle watermarking attacks if you can get access to different encryptions of the same sector. Still in spite of that I'd much rather rely on TrueCrypt than some closed source products. So far all storage encryption products I have seen have had some weakness, I'd much rather use one where I know what it is and to what extend it could be a problem to me.
I guess a porn only version might become so popular that there was no users left for the standard version. After playing a number of times I saw only one image which might be classified as porn. It was a picture of Christina Aguilera naked. My partners guesses were: bitch, fuck, blow aguilera. I guess he doesn't like Christina Aguilera.
For now though from a theoretical viewpoint this is a major weakness, it still requires way too much processing power to be realistic. And the way git is designed, I don't think it is going to be any major problem switching to a new hash once cryptographers starts to agree which one should be considered secure in the future. Once they start using a new hash, you can actually still safely use old repositories based on SHA-1. Because once there is no longer being added new data based on SHA-1, a collision is no longer enough to perform an attack, rather you need a second preimage, something which there has not yet been demonstrated an efficient way to produce.
Does someone here know how large is the physical flash on a 512MB usb stick? Are we talking about 640MB, 1GB, 2GB?
And if you carefully read my description from before, you should recognize, that it is the mode known as LRW. I don't like the name of that mode, because to me it looks like this mode was invented by someone who read the article by Liskov, Rivest, and Wagner but did not fully understand it.
Might be acceptable for most users, but as I pointed out earlier, the algorithms I know for this have a significant CPU overhead. If you know a solution for this without the performance penalty, I'd very much like to hear about it.
Or you come up with a clever combination of the different algorithms. Actually I don't know exactly what a 2-phase commit is, but a possible approach goes as follows. You consider the disk as a number of regions where each region consist of 200 data sectors and a metadata sector at each end. The metadata contains a 16 byte tweak common to all sectors in the region and a 16 bit counter per sector. The two are concatenated with the sector number to construct a unique tweak.
Now you can update the first metadata sector, then update any subset of the data sectors, and finally update the second metadata sector. You get two extra writes no matter how many of the sectors you updated, and you essentially don't get any extra seeks. And for each sector at least one of the two metadata sectors will be usable. You will have to duplicate the least significant bit of the counter into the data sector so you will know which meta data sector to use. That lost bit will easilly fit in the meta data sector. And there is enough space left over in the meta data sector to do a probablistic encryption of the meta data sector.
There are a few drawbacks, for example you need to reencrypt the entire region each time a counter wraps, but the ammortized time required for that is insignificant. You can do the structure kind of recursively to avoid most of the full region reeencryption. The only problem left which I don't have a complete solution for yet is, that each write operation would have to start by comparing the two metadata sectors to know if a recovery is required.
There, now also shown independently by Gweihir.I never said the proof was complicated.
If those three things were fixed you could keep an emacs running in text mode under screen and fire off make-frame-on-display commands as needed.
Tweakable block ciphers is an elegant solution for this problem. But it is no magic bullet. If you reuse a tweak, it is no more secure than an ordinary cipher. And even if you don't reuse a tweak you still cannot use it more times than the birthday limit imposed by the block size. (AFAIR the number of times you can safely reuse a tweakable block cipher is two or three times less that of an ordinary cipher).
You could actually replace the cipher in a CBC encryption with a tweakable cipher and get something slightly safer. But the quite common practice in storage encryptions of replacing the random IV in a CBC encryption with a deterministic value is always going to be insecure. The extra space is provably necesarry (shown independently by Kristian Gjøsteen and myself).
It is possible to come up with ways to generate the tweak in a way that requires less disk space than the random IV for CBC encryption. So for that reason tweakable ciphers is clearly an interesting way to do storage encryption. But as soon as you have a space overhead, however little it may be, you have a problem with atomicity of updates. That means you are going to need extra copies of some of the data to avoid data loss in case the system for whatever reason doesn't complete an update. But you could still have significantly less overhead than the random IV for CBC encryption. CBC would usually be 3-6% overhead, a clever system designed using tweakable block ciphers could use less than 1% overhead. Now if I could just come up with an efficient way to detect the need for recovering an incomplete write....
Unfortunately most sector-based encryption schemes does have such a weakness. The impact of the weakness may differ from the worst encryption leaking everything to the best encryption leaking only the sector number of writes and when a write is identical to something that earlier existed in the same sector. TrueCrypt is somewhere between these two extremes. The best deterministic encryptions I know of requires approximately twice as much CPU time than the more secure probabilistic encryptions.
That is indeed a very relevant question. If you come across an encryption were such a specification is not available for anybody to read, assume it is because the encryption is no good. If the specification is too vague and only states the name of a block cipher being used such as AES and doesn't tell you in detail what mode it is using, I'd also avoid it. And if it ever states anything like military strength encryption, I'd avoid it. TrueCrypt is one of the best documented storage encryptions I know about.
TrueCrypt makes use of tweakable block ciphers. The idea with tweakable block ciphers is good, but it is no magic bullet. And unfortunately TrueCrypt reuse the tweaks every time the same sector is overwritten, which means the proofs for security of tweakable block ciphers does not apply to TrueCrypt. Depending on the attack scenario this may a threat. Using a USB stick is going to make this problem worse.
It is not the USB protocol which is a problem, but rather the fact that a USB stick store the data in flash using a wear leveling algorithm. That means that even though from TrueCrypt's point of view it is writing to the same sector number, it is physically writing to different flash cells. This again means, that for some time both the old and the new version may physically exist in the storage. This means anybody who are able to read the physical flash cells without going through the wear leveling code will have access to the necesary data to exploit this weakness.
I don't know anything about U3, so I cannot tell you for sure if it is better or worse than TrueCrypt. But with the number of weaknesses which have been seen in storage encryptions, I'd expect anything new to have a few of its own. In spite of the minor weakness in TrueCrypt, I'd still perefer that over something with weaknesses I don't know about.
My advice for encryption on USB sticks is to not rely on transparent encryption and rather use something like GPG. Of course combining TrueCrypt and GPG is not going to harm security. GPG encrypted files on a TrueCrypt encrypted storage should be pretty safe.
My parents had a PC where the printer would report "input jam" whenever trying to print anything. Interestingly it printed just fine when connected to my Amiga. To make matters even more strange, it was unable to even print a testpage, if it was connected to the PC.
My thought after seeing those symptoms was, that maybee the PC was infected with some kind of virus. However even when the PC was turned off, the printer couldn't print a test page, only when the printer cable was disconnected could it print.
The printer was still covered by waranty and was sent for a repair, and the paper tray was switched, which solved the problem. How a defective paper tray would only be a problem while the printer was hooked up to the PC is beyond me.