Talk:TrueCrypt

From Wikipedia, the free encyclopedia

You have new messages (last change).

Contents

[edit] How secure is it

This needs to be added to the article

You mean whether it is "little", "moderately", "very", or "ultra" secure? Or, wait for it, "military-grade"? How exactly would you treat such a topic?
When you create an encrypted volume, it displays random pool data and the generated keys ON THE FRIGGING SCREEN. If this is acceptable to their security philosophy, I'd say TrueCrypt is at most aunt-secure (as in "My aunt wouldn't be able to view those files"). Aragorn2 14:45, 1 August 2006 (UTC)
You can prevent the numbers from being displayed by unchecking the checkbox next to the numbers. But being able to see the numbers is actually a good way to verify that the data really look random and that the random number generator is not "out of order". Besides, only parts (not the whole) of the pool and keys are visible.

[edit] identification

"No TrueCrypt volume can be identified (TrueCrypt volumes cannot be distinguished from random data)."

I believe this is an incorrect assertion. A TrueCrypt volume is typically a huge file, filled with structured data in a mathematical pattern. If I were looking at siezed media or my hard drive and found an enourmous file in which I could not read any data from, I would suspect it to be encrypted. Pattern analysis would confirm my suspicions.

I agree that TrueCrypt volumes are hard to identify, but I do not agree that "No TrueCrypt volume can be identified".

"No TrueCrypt volume can be identified" means "it can't be distinguished from random data", i.e. it can't be determined whether this is really encryted data or some glibberish.--84.63.1.177 20:55, 21 November 2005 (UTC)
"No TrueCrypt volume can be identified (TrueCrypt volumes cannot be distinguished from random data)."

The file header, which identifies the type of file, is encryped along with the data. Couldn't this be what was meant?

Let me know how that pattern analysis goes. :)

> would suspect it to be encrypted.

To suspect is not the same as to identify.

Still, even with strong suspicion of encrypted data, there is no idea with what tool was used to encrypt - it could be truecrypt, or it could be any other tool with same "no identification from random data" feature. And if there are more large files on disk, chances are that at least one of them can be actually some random data to fool the enemy ... plus there are some (rather experimental) compressors which leave similar "footprint" of completely random data and no header of any kind
--Territory 19:04, 30 December 2006 (UTC)

> Pattern analysis would confirm my suspicions.

There are no patterns. If you were able to identify a TrueCrypt volume you would actually break the cipher.

no pattern, but analysis would reveal that the entropy matching very close to those of random data with no structure at all. Basically leaving three options:
  1. something encrypted (without any header)
  2. something compressed (without any header)
  3. some truly random data
1 being the most common case usually ... in 2. most reasonable compressors, like gzip/bzip2 leave some small header in compresses data. In 3. holding large amount of random data is unusual (prehaps as keyfile for some other data?). This leaves 1. as most probable option
--Territory 19:04, 30 December 2006 (UTC)
How many file types are there where the data has no pattern at all? Very suspicious.
But it isn't a "file type", it's an encrypted volume. Header, file table, file names, file contents, all encrypted. There is no pattern. --Tim1988 talk 18:43, 16 August 2006 (UTC)
Keyfiles, experimental data compressors (you usually don't bother with header for these)
--Territory 19:04, 30 December 2006 (UTC)

[edit] Other encryption programs

Shouldn't the CrossCrypt link be moved from here to Disk encryption software? And is the rest of this section much use? All the programs mentioned should be in "Category: Cryptographic software" anyway. Kasperd 22:51, 4 March 2006 (UTC)

I agree. The section "Other encryption programs" appears to be redundant here. Moreover, now it has to be maintained at multiple places at once (here, in CrossCrypt, etc., and over in "Disk encryption software"). I'd remove the section "Other encryption programs" from here completely. Just go ahead and remove it (I recommend a brief substantiation to prevent accusations of vandalism). Maxt 14:48, 6 March 2006 (UTC)

[edit] Security of modes of opperation

Currently the article says: "It added LRW mode, which is provably more secure than CBC mode." But this is not entirely true. TrueCrypt never used CBC in the way CBC was intended to be used. The mode used by TrueCrypt 4.1 is provably more secure than the mode used by TrueCrypt 4.0 and earlier. But correct use of CBC with a random IV would be more secure than TrueCrypt 4.1. However the random IV would require exstra disk space and introduce problems with atomicity of updates, which would then need to be addressed. Kasperd 15:05, 21 January 2006 (UTC)

LRW actually is provably more secure than CBC (even if you use CBC with random and unpredictable IVs). That's why LRW was introduced in the first place -- to thwart all the severe attacks that CBC is susceptible to (some of those attacks apply especially to disk encryption). Maxt 00:26, 23 January 2006 (UTC)Maxt
Then there must be a mistake in the proof, because http://eprint.iacr.org/2005/083 give an attack that works against LRW but does not work against a correct implementation of CBC. Theorem 4 give a chosen plaintext attack against semantic security. That attack works against any disk encryption with expansion ratio 1. Kasperd 09:55, 23 January 2006 (UTC)
There is probably a mistake in how you read the paper. Because the author of that paper, Kristian Gjøsteen, 7 months after releasing that paper, recommends on sci.crypt to the TrueCrypt team to implement the LRW mode. See his message: http://groups.google.com/group/sci.crypt/msg/825a0ed2c715d3d6?hl=en&
Another well-known cryptogologist, David Wagner, (co-designer of Twofish) also recommended LRW for TrueCrypt on sci.crypt in November 2005, see: http://groups.google.com/group/sci.crypt/msg/ef87ade05fd809bf?hl=en&
Moreover, if you think about it, CBC is essentially LRW with known tweaks (except for the first tweak, which is IV). Pure logic tells you which mode is more secure (LRW has unknown and unpredictable tweaks).
Maxt 16:33, 23 January 2006 (UTC)Maxt
There is a compromise between security, performance, disk space and a few other factors. LRW is more secure than the flawed CBC usage in earlier TrueCrypt versions. However there exist even more secure ways to encrypt a disk for example using CBC with a random IV. But higher security have a price in performance, disk space, complexity and portability.
That comparision [CBC to LRW] is mostly correct. However LRW reuse the tweaks, a correct CBC implementation would not. And it is the reuse of the tweaks which is the primary weakness in LRW. Kasperd 22:12, 23 January 2006 (UTC)
I suggest you read the rationale that motivated IEEE to use LRW. They have been looking for a mode that is more secure than CBC with random IVs (and than other "classic" modes, like OFB or CFB). LRW is the answer. Reuse of tweaks happens in CBC too. However, reuse of tweaks is a problem only in "stream cipher" modes, such as CTR. LRW is a good choice particularly for disk encryption (unlike CTR or CBC, which have serious problems). See for instance, http://clemens.endorphin.org/nmihde/nmihde-A4-ds.pdf Maxt 21:43, 26 January 2006 (UTC)Maxt
I have looked through the chapter on CBC attacks to see if there was anything new to me. It mention three different CBC modes, but it completely ignores the possibility of fully random IVs which are more secure than the three IV modes mentioned in the article. I'm willing to believe the three IV modes mentioned in this article are all less secure than using LRW. The attack I mentioned earlier against encryptions with expansion ratio 1 works against LRW as well as any deterministic IV computable from key, cleartext, and sector number. The attack does not work against CBC with random IV. Next the article discuss random leaks because of collisions. With appropriate cipher block sizes, the probability of such leaks can be proven negligible. Next the article discuss how to exploit weaknesses in the IVs, that part does not apply to CBC with random IVs. Finally it discuss integrity in case of active attacks. Neither CBC nor LRW protect against active attacks. So this article does perhaps show LRW to be more secure than deterministic CBC, but it does not show anything about probabilistic CBC encryption. Kasperd 10:53, 27 January 2006 (UTC)
I'll say it for the last time: CBC is LRW with known tweaks. This simple fact should hint you which mode is more secure. Several experts respected in the field of cryptology, IEEE, and many others recommend LRW instead of CBC (with random IVs) for disk encryption. You obviously know better. I'm done with this pointless discussion. Maxt 19:57, 28 January 2006 (UTC)Maxt
There is another important difference between CBC and LRW. CBC is probabilistic, LRW is deterministic. And that is the reason for the weakness in LRW. LRW reuse the tweaks, that is insecure. If it had been safe to reuse the tweaks, you could have used the same tweak for every cipher block, but that is essentially equivalent to ECB. Kasperd 12:14, 29 January 2006 (UTC)
Are you just trolling here? I already replied to that "reusing tweaks" above. CBC reuses tweaks too (for example, IV is reused every time a sector changes). Moreover tweaks in CBC are known to the adversary (unlike in LRW) which allows for easy watermark attacks (you didn't think a random secret IV makes CBC resistant to watermark attacks, did you?). But most importantly, tweak reuse is not a problem in CBC nor LRW. The last sentence you wrote is just pure nonsense. Tweak reuse in LRW is allowed not among different blocks, but for a single block only. This makes it "different" from ECB. Also, you might want to read a definition of "deterministic": In Computer Science a Deterministic Computation is a computation that given an initial state of the system will always produce the same final state. Obviously, CBC mode is as deterministic as LRW. Learn the basic terminology, before you start using it. Maxt 00:49, 30 January 2006 (UTC)Maxt
Many disk encryptions does reuse the IV for CBC in the way you describe. Those encryptions are less secure than LRW. However CBC can be done securely using a random IV. As far as I remember CBC with random IV has been proven resistant to watermarking attacks. For that to work it is essential that the adversary does not know the IV before choosing data. But as soon as the data are fixed, there is no need to keep the IV secret. If you can give any reference saying otherwise, I will take a look. It is correct that LRW only reuse the tweak for the same position on the media. That means it is harder to collect a large number of encryptions under the same tweak, but it is still possible. Of course if everything else is kept the same, then replacing an ordinary block cipher with a tweakable block cipher can only improve security. And using the optimizations described in the Disk encryption article, it may even perform just as good. Using a tweakable block cipher in CBC mode is probably more secure than ordinary CBC as well as LRW. Kasperd 07:22, 30 January 2006 (UTC)
> Many disk encryptions does reuse the IV for CBC in the way you describe. Those encryptions are less secure than LRW.
Finally, you apparently agree with me. The crucial thing now is I don't know of any disk encryption that would not reuse sector IVs. If you do, tell me its name. As far as I know, there is no practical way to avoid CBC per-sector IV reuse in on-the-fly disk encryption software. That's also the reason why CTR is useless for on-the-fly disk encryption.
> That means it is harder to collect a large number of encryptions under the same tweak, but it is still possible.
You can collect even 2^64 blocks encrypted using the same tweak in LRW mode. However, as long as the cipher is resistant to DC, KPA and CPA (which any good cipher should be), these blocks will be useless to you. You have just 2^64 PRPs. The only thing you could do with them is "replay" (but this works on all practical non-authenticated modes). Maxt 19:19, 3 February 2006 (UTC)
I think the question is, what does CBC mean? I say it means a random IV is chosen each time an encryption is done. What has been used by most disk encryptions is a reduced CBC which is less secure. As for implementations, I don't know any. However GBDE is quite close to the CBC use I had in mind. It's close enough to show the approach is practical. GBDE randomize the key rather than the IV, the one-time-key is encrypted using a fixed key. If the same fixed key had been used for every sector, I would have considered GBDE to be secure against any passive attack. However a weak pseudorandom generator is used to generate different fixed keys for each sector.
I agree the "replay" attacks works on any non-authenticated modes. Authenticated modes resistant to this has been designed, but I don't think any has been implemented. Kasperd 11:17, 6 February 2006 (UTC)
> As for implementations, I don't know any.
Yes, there is indeed no practical method to use CBC mode for OTFDE while sufficiently preventing watermark attacks (due to per-secor IV reuse and to the fact that successive tweaks are not secret). Thus, I can safely conclude that LRW is more secure than CBC for practical on-the-fly disk encryption. By the way, frequent rekeying is impractical and too costly because cipher key expansion (schedule) takes very long. It was in fact one of design goals of LRW: To create something analogous to rekeying but much faster. Maxt 15:11, 7 February 2006 (UTC)Maxt
Your claim, that correct use of CBC isn't practical, is incorrect. Though I don't know any implementation of correct CBC encryption of a disk, an implementation could obviously be done more practical than GBDE. And correct use of CBC does not need any rekeying. If you modify GBDE to use a fixed key rather than new keys all the time, and use the randomness for IV rather than key, then the result will be a correct CBC encryption. And since there is no more any need for encrypting the randomness, and no need for rekeying, the result is clearly simpler than GBDE.
But being practical or not is really not the point I was trying to make here. Saying LRW is provably more secure than CBC mode is incorrect, whether or not CBC is practical doesn't change that point. I don't claim CBC is the most secure way to encrypt a disk. I just point out, that correct use of CBC is resistant to an attack, which works against LRW. Combining the best of GBDE with the best of LRW would give a result which is more secure than any of them, and more practical than GBDE. Kasperd 20:21, 9 February 2006 (UTC)
First, keep in mind that we are discussing modes of opeation in the context of practical OTF disk encryption (OTFDE). While, for instance, CTR mode is a very secure NIST-approved mode, it is absolutely insecure for practical OTFDE. Similarly, this applies to CBC (although CBC certainly is more secure than CTR here). The proof for the statement that LRW is more secure for OTFDE than CBC has already been given. Just like CTR is insecure for practical OTFDE because there is no practical way to protect it from some attacks, CBC is vulnerable to watermark and other attacks in practical OTFDE and therefore insecure. (You yourself acknowledged that you know of no practical solution to the CBC sector IV reuse problem in practical OTFDE). LRW does not suffer from these attacks. Therefore it is more secure for feasible OTFDE. Reread what I wrote, the proofs are there. I'd like this discussion to end because it's getting pointless. Both of us are just repeating the arguments. Maxt 11:15, 12 February 2006 (UTC)
CTR as well as CBC can be insecure if used incorrectly, which is the case with most disk encryptions. If used correctly a probabilistic encryption like CBC can give you security properties that no deterministic encryption like LRW can ever offer you. Also notice, that I did not acknowledge, that I don't know any practical solutions. I do know practical solutions, I just don't know any actual implementations. I already pointed out in detail why GBDE is close enough to the solution to judge the practicality. I'm surprised that pointing out one minor mistake in the article could lead to such a long discussion. The incorrect statement is still in the article. Why not just fix that one statement? Saying LRW is more secure than the deterministic CBC variant used by older TrueCrypt versions, would be true. The discussion about practicality is completely irrelevant (I don't know why you brought it up). The statement in the article is about security, you cannot claim a mode is insecure just because you find it impractical. Kasperd 07:42, 19 February 2006 (UTC)
You are just repeating the arguments again. For answers to all your questions and arguments, see my comments above. I am not going to repeat myself infinitely. Life is too short for that. I'm just going to say that the statement in the article is perfectly correct. Again, for substantiation of the claim, see my comments above. I'm not going to waste any more time on this pointless discussion. Maxt 16:17, 20 February 2006 (UTC)Maxt
How can you consider that statement correct, when there are known attacks against LRW which do not work against CBC? Kasperd 10:13, 22 February 2006 (UTC)
Really? How would you attack LRW-AES then? Describe it. Here and now. Describe what you will gain by your "attack". Remember that LRW is secure as long as the underlying cipher is secure. Also remember that tweakable ciphers/modes have clearly defined upper security bound (similarly, eg. hash functions have the birthday paradox limit). Any "attacks" beyond the bound would be effectively invalid. (I'm not sure why you are defending an insecure mode like CBC when LRW is provably more secure -- and everybody except you seems to know this. You make the impression that you are perhaps trying to avoid getting ashamed for having supported CBC in some work you wrote about disk encryption even though CBC is actually insecure for OTFDE.) Keep in mind that I can give you dozens of kinds of feasible attacks on CBC in practical OTFDE. Now describe exactly how you would attack LRW-AES in OTFDE and what you would gain by the "attack". Don't post any hazy references to papers lacking peer review (note that there's no peer review at eg. eprint.iacr.org prior to publication). Describe it yourself simply using your own words. Show me that you actually know what you are talking about. Maxt 23:01, 23 February 2006 (UTC)Maxt
Consider a sequence of writes to the same sector. Assume each of them flip the same bit in the plaintext, which means all the writes alternate between two similar plaintexts. If we assume LRW is being used, the sector will alternate between two ciphertexts which differ in just a single cipherblock. An adversary who is able to get two or more versions of the ciphertext is able to notice this pattern. Had CBC been used with different IVs for each write, there wouldn't have been the same kind of pattern. As long as there are no collisions, the result will be indistinguishable from random.
Before anyone claims such an adversary is unrealistic, let me point out six ways it could happen. The encrypted version may be stored as a file on a filesystem where the data are for some reason stored in different locations. (Could be caused by journaling or defragmentation). The encrypted version may be stored on a harddisk which at some point needs to relocate the data because of a bad area on the disk. The encrypted version may be stored on a flashdisk, where location is changed dynamically to distribute writes to different physical locations. The encrypted version may be stored on a network attached storage. The adversary may be able to get a backupcopy of the encrypted version. The adversary may have access to read the encrypted version without getting notice, for example because he has physical access to the storage.
The adversary doesn't get much information from this attack. But notice that the adversary does get something in case of LRW and nothing in case of a correct implementation of CBC. This means in this case CBC is slightly more secure than LRW, which contradicts the statement you are defending.
This shouldn't be seen as just a defense of CBC. I understand LRW has advantages over CBC, but it also has this disadvantage. A combination of the two could be more secure than each would be on its own. Kasperd 12:38, 24 February 2006 (UTC)
> But notice that the adversary does get something in case of LRW and nothing in case of a correct implementation of CBC.
It's funny that I expected you to come up with this. First, where's the attack? Second, you said that the "attack" works on LRW but does not on CBC. However, in feasible OTFDE this works on CBC too. The only difference between CBC and LRW here is the granularity of the "attack". But it works on both modes. Period. Do you have any other "attack" on LRW? I've seen none so far.
But now as you touched this area, let me show you just two feasible related attacks (and yes, they are actually attacks, unlike yours "attack"), which work on CBC but not on LRW.
To save time, I'll directly quote the IEEE material:
Two solutions that were rejected by the group as insecure were to use either counter mode or CBC mode, deriving the IV from the sector number.
... an attacker with read/write access to the encrypted disk can copy a ciphertext sector from one position to another, and an application reading the sector off the new location will still get the same plaintext sector except perhaps the first 128 bits). For example, this means that an attacker that is allowed to read a sector from the second position but not the first can find the content of the sector in first position by manipulating the ciphertext.
• Another drawback of CBC mode is that an attacker can flip any bit in the plaintext, if it is willing to pay the price of randomizing the previous plaintext block.
[end of quote]
The ability to flip any bit in plaintext in CBC is sufficient to claim that LRW is more secure than CBC (even with randomized non-reused IVs). But there are dozens of other kinds of real attacks that work on CBC but don't work on LRW. And there are none on LRW. Simple. Maxt 19:04, 26 February 2006 (UTC)Maxt
Why do you ask for the attack I just gave you? Are you unfamiliar with semantic security? As soon as you understand how semantic security is applied to disk encryption, the attack is obvious. The adversary generates a sequence of sector numbers and two sequences of plaintexts for the writes, the oracle chose one set of plaintexts and reply with the encryption. The adversary must then try to guess which of the plaintext sequences it was. The sequence I described can easilly be distinguished from random. Next you bring up integrity, but I already explained, that neither of the modes provide security against active attacks. You still assume that the IV is chosen deterministically. Correct use of CBC means the IV is random. You cannot show the statement to be correct by comparing LRW to something slightly weaker than CBC. Kasperd 09:15, 27 February 2006 (UTC)
> The sequence I described can easilly be distinguished from random.
What are you talking about? What you wrote does not make any sense whatsoever. Also, read my previous comments on how easy it is to watermark-attack CBC in feasible OTFDE. Watermark attacks do not work on LRW.
> You still assume that the IV is chosen deterministically.
Of course I do, because there is no feasible way to use random IVs in disk encryption. And we are comparing security of CBC vs LRW in the context of feasible disk encryption. Again, see my previous comments. You keep going in circles, and I'm really not going to waste my time on this. Maxt 17:56, 28 February 2006 (UTC)Maxt
If you have too little cryptographic background to understand the problem, there is not much I can do about that. You seem to have made up your mind about what you consider feasible and pretend everything else is nonexistent. I already pointed out a long time ago, that GBDE does probabilistic encryption. Yet you still claim probabilistic encryption is infeasible. Even if it was infeasible, it wouldn't make the statement in the article correct. The statement says LRW is more secure than CBC in general. And BTW even a deterministic version of CBC could be made resistant to watermark attacks, the IV just needs to be computed as a hash value of the sector number, some key material, and as much of the plaintext as possible. Of course being deterministic it would still not be semantically secure. I will not waste anymore time on this discussion. If you want to leave the incorrect statement in the article, then please do so. Kasperd 22:42, 28 February 2006 (UTC)
> If you have too little cryptographic background to understand the problem
I'm sorry, but that seems to be your problem.
> The statement says LRW is more secure than CBC in general.
Nope. Read better. The article has always said that LRW is more secure for disk encryption. And it is. That's why IEEE chosen LRW instead of CBC for disk encryption. However, I would add that LRW is more secure than CBC in general as well (not just for disk encryption).
> the IV just needs to be computed as a hash value of the sector number, some key material, and as much of the plaintext as possible.
Typical "home-grown" cryptography. IV's dependent on plaintext represent a sure way to introduce vulnerabilities (I've seen this happen).
> If you want to leave the incorrect statement in the article, then please do so.
The sentence in the article is correct. LRW is provably more secure than CBC for disk encryption. There are dozens of kinds of feasible severe attacks on CBC in practical disk encryption that don't work on LRW. Vice versa it does not hold.Maxt 16:40, 7 March 2006 (UTC)Maxt
Supporting Kasperd's argument, probabilistic disk encryption is feasible in practice. For example, GBDE uses per-sector pseudorandom keys and CBC for each sector individually. But don't take my word for it, please see their design document: http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf -- intgr 03:15, 25 December 2006 (UTC)
Curious I missed this the last time. "Typical "home-grown" cryptography. IV's dependent on plaintext represent a sure way to introduce vulnerabilities (I've seen this happen)."
Maxt: How exactly would you attack the "plumb IV" approach? I have yet to hear anyone claiming that it was insecure, and people appear to believe that it defeats the limitations of ESSIV. As far as I can tell, the only reason why it hasn't been used in real life is its inherent slowness due to processing each sector twice. -- intgr 21:21, 2 January 2007 (UTC)

[edit] added features, made some tweaks

I've just tinkered a little, I hope my edits look OK. I thought the article needed more clarity on what TrueCrypt does, especially features that are not standard across all OTFE products, to complement the sizeable history section. Skewer 11:10, 20 April 2006 (UTC)

I moved your text to the main section. The reason is that the main section+intro already was about the program features (i.e. supported ciphers, virtual disk, etc.)Maxt 16:37, 19 May 2006 (UTC)Maxt

[edit] What do people typically put in it?

I was wondering what people put in this program? I would think if you were a real spy or something your government would provide you with their own program. I suppose business documents with social security numbers could go in. Or pornography. 64.40.60.33 23:50, 13 July 2006 (UTC)

Mostly porn is probably what's stored. Maybe some sensitive documents too. (Steampowered 02:14, 13 August 2006 (UTC))
How about storing encrypted data on memory sticks?
Because of the wear leveling used in many such devices, there may be multiple versions available of some of the sectors. This will give an attacker more data to work with when trying to break the encryption. Most disk encryption products were designed without considering this. The security proof of LRW does not apply if the attacker have multiple versions of the same sector. Kasperd 17:55, 30 September 2006 (UTC)
By the way, in case anyone thinks this is something new, the TrueCrypt User Guide warns the users about the security issue of wear leveling. Also, if you encrypt the entire device (as opposed to creating a file-hosted container on it), there can't be any free sectors on the device, so there can't be multiple copies of a sector either. So if you have issues with wear leveling, encrypt the whole USB flash drive with TrueCrypt. —The preceding unsigned comment was added by Maxt (talk • contribs).
I couldn't see the link you provided since the site is apparently down and there's no Google cache, but I would think that wear levelling is often implemented at the level of hardware. I'm not aware of any specializations for flash devices in FAT/NTFS or other mainstream filesystems, or the block device code in operating systems. Instead, I would think that this is typically implemented in the hardware and it wouldn't know the concept of "free sectors". They would have a reserved reallocation space where dead sectors will be mapped to. At least this is what the current generation of harddrives do in case of bad blocks. Technically, as the deprecated blocks will still exist where they were once stored (before they were remapped), they can still weaken the security - even though it might require bypassing the device's logic. -- intgr 13:26, 2 October 2006 (UTC)
I have never seen the link before, where did you get it from Max? There does exist file systems with wear leveling, for example JFFS. But most people use FAT anyway, since that is what Windows supports. So many flash devices have wear leveling build in at a layer below anything seen by the OS. Wear leveling and bad block remapping are slightly different since wear leveling happens all the time even if there are no bad blocks. But the security implications for encryption are the same. The link only warns about the implications when changing password (which in some sense is even worse than the problem I pointed out), but the problem I pointed out also applies if you choose one good password and sticks with that. The link does not give any suggestion on what to do about it, other than using a media without wear leveling. I'm not sure if you can find a media without it, it might have wear leveling even if they don't explicitly tell you about it. Kasperd 14:33, 2 October 2006 (UTC)
> I have never seen the link before, where did you get it from Max?
I'm not sure it's relevant here, but: The TrueCrypt manual is included as a PDF in the distribution zips (I'm using version 4.2 form 17th April 2006 and the section on Wear Leveling is there -- so nothing new as you can see) and also online at http://www.truecrypt.org/docs/ (go there, look on the left side, there's a table of contents, click "Wear Leveling", then in the upper right corner of the main page the "External Link" is the link I posted).
> The link only warns about the implications when changing password
The linked page warns in the first place about the fact that wear leveling may cause duplicates or older copies of sectors to be stored and says "This may have various security implications" and gives an example. There may be dozens of unknown security implications of wear leveling so it's unrealistic to expect them to give full treatment of the issue. It's sufficient to give just an universal warning (and you should just follow their recommendation and avoid wear leveling devices, then you'll be secure). Maxt 14:46, 9 October 2006 (UTC)
That basically means you should avoid USB sticks and all other flash medias. AFAIK most vendors do use wear leveling (not that I have any reference proving it). And if the documentation doesn't explicitly mention it, you can't know for sure if a particular media use wear leveling. But you can get the same kind of problems from remapped sectors on harddrives, so you should avoid those as well. But as long as you don't put your encrypted data on flash or a diskdrive, your data should be secure. An alternative would be to use an encryption designed to be secure without making assumptions about the underlying media, but I don't know of any actual implementation of storage encryption satisfying that. Kasperd 03:19, 10 October 2006 (UTC)
"But as long as you don't put your encrypted data on flash or a diskdrive, your data should be secure." Nicely put. I would almost consider that an axiom of secure computing. ;) —GrimRevenant 13:17, 10 March 2007 (UTC)

[edit] Is TrueCrypt cross-platform or not?

The edit war of removing and re-adding "cross-platform" to the infobox has been going on for some time now, so I decided to address it on talk.

My reason for not considering TrueCrypt a cross-platform program is that since it works at the operating system level as a driver, it is inherently platform-specific – meaning that it cannot be ported to yet another platform without writing a significant amount of code. I believe this is fundamentally different from cross-platform user space applications, and would go as far as to say that the Windows and Linux versions are essentially separate implementations, even though they do share a fair part of the backend (crypto) code.

While one may argue that porting user-space applications to other platforms will also require platform-specific code, this is not often the case with different operating systems in the same family – for example, Windows 9x and Windows NT are generally compatible, and different flavors of UNIX differ in only subtle ways. -- intgr 18:53, 11 December 2006 (UTC)

Has this been a long-running dispute? I hadn't noticed; it seems that "Windows and Linux" is optimal in that it conveys the maximum amount of information in the least possible space. "Cross-platform" either conveys less information (by itself) or is redundant (if we spell out the OSes). I don't intend to spend any more time on the "issue", though ;-) — Matt Crypto 19:28, 11 December 2006 (UTC)
The definition of cross-platform software is simple (see the corresponding Wikipedia entry). Basically, a program that runs on multiple distinct operating systems is cross-platform. Firefox is cross-platform even though one implementation is for POSIX and one for Windows. So to answer the topic question: Yes, TrueCrypt is by definition cross-platfrom software. Frankly, I quite don't get the, sorry can't find a better term, mumbo jumbo by Intgr above (I just hope Intgr doesn't have some hidden agenda). Maxt 14:18, 18 December 2006 (UTC)
Mumbo-jumbo? Hidden agenda? I'm sorry for having an opinion, but note that your "cross-platform" sign has been removed three times by three different people ([1] [2] [3]), and you alone have been putting it back there ([4] [5] [6] [7]). Ironic, isn't it?
I was trying to rationalize why I thought it shouldn't be classified as cross-platform despite the definition. So did Matt. Neither of us is asking you to like these reasons, and you not liking them doesn't make them any less valid. You, however, do not appear to have any additional arguments for your stance [besides attacking me, that is]. -- intgr 15:07, 18 December 2006 (UTC)
My "mumbo-jumbo" boils down to these two points:
  • I think it would be fair to consider the Windows and Linux versions separate implementations of a similar encryption tool.
  • I believe that "cross-platform" ought to be defined on a basis of portability. To be honest, I'm not very fond of the phrase anyway.
-- intgr 15:26, 18 December 2006 (UTC)
Intgr, I suspect you have some hidden agenda because you twice attempted to "prove" that TrueCrypt is not cross-platform in two different ways: First, a few weeks ago you wrote the absurd: Windows NT and Linux alone do not qualify "cross-platform". You failed, so you took a second try by saying that two implementations of a single program that do not share 100% of a single common code base are not cross-platform.
There isn't any program whose executable form runs on multiple operating systems (e.g. you can't run Firefox.exe on Linux, OS X and Windows). Even Linux distributions have mutually incompatible binaries. All cross-platform programs have code parts that are common for all platforms and platform-specific parts. Maxt 15:57, 18 December 2006 (UTC)
Even though I believe that many of your claims are irrelevant to this case, I will address them anyway, many of them are outright wrong. Unfortunately, this will have to be a long post, as I will back it up with examples and facts:
  1. "you twice attempted to "prove" that TrueCrypt is not cross-platform in two different ways" – I have never considered my opinions to be proof. I did not start an edit war with you after you reverted my changes. Nor do I have any plans of doing so. That said, I had not developed this rationalization [please do read that ariticle] when I initially reverted your edit. People may change opinions without a "secret agenda".
  2. "You failed, so you took a second try by saying that two implementations of a program that do not share 100% of a single common code base are not cross-platform" – I did not "fail", I do not have a secret agenda to push. Neither did I state or believe that they have to share 100% code in order to be cross-platform [refer to the kernel/driver section below].
  3. "There isn't any program whose executable form runs on multiple operating systems" and "while it's fairly obvious that no cross-platform program can have 100% common shared code for all its ports" – Wrong. DOS applications run on Windows 3.1; Windows 3.1 applications run on Windows 9x and Windows NT-based kernels. They also run under Wine (software), which, contrary to a popular belief, is not technically an emulation layer, but an independent reimplementation of the Windows userland [8]. SCO UnixWare contains a subsystem for Linux binary compatibility (UnixWare#Timeline of Unixware). There is absolutely nothing to stop code compiled for the same (or compatible) architecture from natively running within another operating system. Not to mention that the definition of "operating system" is pretty vague, too – for example, do you consider ReactOS and Windows different operating systems?
  4. "Even Linux distributions have mutually incompatible binaries" – Wrong. Applications compiled for newer major glibc versions fail to work under older ones, but not the other way around [9]. Binaries compiled for compatible versions of glibc are compatible across distributions. [see below for kernels/drivers, however]
  5. "All cross-platform programs have code parts that are common for all platforms and platform-specific parts" and "while it's fairly obvious that no cross-platform program can have 100% common shared code for all its ports" – That depends on how far you go with your definition of "platform-specific parts". For example, simple C programs that rely on functions defined by the standard require no additional code to run anywhere where a conforming compiler exists. Different Unices are source-compatible to some extent, but many applications utilize autoconf to check whether the host operating system supports particular features (which may also differ between versions of the same OS), achieving much wider compatibility across Unices, and also Cygwin. There are also many cross-platform libraries that wrap all functionality provided by the operating system, such as wxWidgets and numerous others (while the wxWidgets library itself obviously is platform-dependent). The claim of 100% shared code does inarguably apply to different implementations of the ABI interface I described in point 3 above, however, these are not generally considered "cross-platform". Nowhere did I state that a cross-platform application must share 100% code between ports.
Drivers and kernel-space code, however, are a completely different matter. As I already pointed out to you in another thread, [10] documents that Linux doesn't even have a stable driver API/ABI. While different kernels in the same operating system family might have compatible driver APIs/ABIs (such as WDM), it is often not the case (including older Windows NT/Windows 9x driver APIs), and especially OSes from different vendors. Different flavors of Unix and Unix-like OSes, for example, have wildly differing methods of implementing drivers. This even includes variations of BSD. BeOS also has a different kernel and different driver APIs from Haiku (former OpenBeOS project).
I hope this is enough examples? -- intgr 16:58, 18 December 2006 (UTC)
I guess I should also mention that the only user interface provided by TrueCrypt on Linux is the truecrypt command-line utility. The GUI from Windows was NOT ported, and as the kernel portion of TrueCrypt inherently relies on the kernel, the kernel<->user-space API is different between the two versions. I still do think that the reliance on code running in kernel mode is more significant than the difference in the UI, but I probably should have mentioned this fact earlier.
My reasoning is that, if a piece of code is designed to be portable (e.g. cross-platform), then it should not rely on the internal interface of the most platform-specific entity, that is, the kernel. Essentially all software that people use on a daily basis works entirely in the user space, relying on the stable user-space<->kernel interface, not the internal kernel interfaces. -- intgr 19:17, 18 December 2006 (UTC)
Wow, this is a big post. You clearly don't have any hidden agenda. All right. I don't have so much time as you, so just briefly.
> DOS applications run on Windows 3.1; Windows 3.1 applications run on Windows 9x and Windows NT-based kernels.
Again, programs that run on Windows 9x and on Windows NT etc. are not considered cross-platform. Cross-platform means e.g. Windows-Linux-OSX-BSD. Not Windows1-Windows2 (two editions of one operating system). I'd be curious to know the name of one truly cross-platform program that has 100% code shared by all ports.
> "Even Linux distributions have mutually incompatible binaries" – Wrong
Wrong see e.g. http://www.freestandards.org/en/LSB
> Nowhere did I state that a cross-platform application must share 100% code between ports.
In fact you did (see your "just common backend of TrueCrypt" arguments, etc.)
> The GUI from Windows was NOT ported
IMO, the key functionality is disk encryption and it's cross-platform, including the volume layout. The user interface can never be the same on all platforms. Some systems don't even have a GUI (e.g. MS-DOS). Does it prevent cross-platform? But let me tell you try really hard to prove it's not cross-platform. Why do you even care so much if TrueCrypt is cross-platform or not? This whole discussion seems to me to be about a non-issue and is really quite ridiculous. It can matter only to someone who has hidden agenda, if you ask me. Maxt 15:36, 21 December 2006 (UTC)
"Why do you even care so much if TrueCrypt is cross-platform or not? This whole discussion seems to me to be about a non-issue and is really quite ridiculous."
I agree, I am taking this discussion ridiculously far, and I apologize for wasting your time. I mainly care because I don't think inherently unportable code should be classified as "cross-platform". I also care because your edits weren't done with a consensus.
I am not going to start an edit war, but nevertheless I consider it important to state my opinion and defend it. The long post above was primarily written to point out factual errors in your preceding post, I know it is mostly irrelevant to the question of whether TrueCrypt is really cross-platform or not. For what it's worth, I have nothing personal against you.
"Again, programs that run on Windows 9x and on Windows NT etc. are not considered cross-platform."
Yes, for user-space applications, I entirely agree. I only stated that to demonstrate that one of your claims was false.
"I'd be curious to know the name of one truly cross-platform program that has 100% code shared by all ports." and "In fact you did (see your "just common backend of TrueCrypt" arguments, etc.)"
While I don't believe that cross-platform code should share 100% code in its ports — this is a straw man of yours — the answer to the question depends on how far you go with your definition of "platform-specific parts". In short, applications relying on (de facto) standard APIs, such as the C standard library, BSD sockets API, or OS functionality wrappers, such as wxWidgets. Also, refer to my fifth point above as I addressed this there.
For the record, the TrueCrypt Windows NT driver is 101 kB, the Linux driver is 16 kB, the Windows frontend is 339 kB and the Linux frontend is 75 kB. The shared crypto code used by the Linux port is 572 kB, the backend code not used by the Linux port is 237 kB (some files in the Common directory were not referenced in the Linux makefiles). That makes 43% of shared code, while the rest is for supporting two kernels alone – not even platforms with compatible user-space ABIs (such as Wine, Windows 9x), or mostly-compatible user-space APIs (which is the majority of Unices).
"see e.g. http://www.freestandards.org/en/LSB"
Linux Standard Base effectively specifies (1) which libraries, and (2) which versions of those libraries [among other things] would be supplied/supported by certified distributions, although they do specify it on the ABI-level in order to guarantee ABI compatibility. The set of libraries and their versions indeed varies from distribution to distribution, but the ABI of the same versions of the same libraries is compatible among different distributions, which is what I stated. Additional patches applied by distributions do not typically break ABI. -- intgr 18:11, 21 December 2006 (UTC)

[edit] References cleanup

Just done a cleanup of the various in-text HTML links and replaced then with footnotes, which allow readers to look for further information without disrupting the flow of the article (also restored a missing but still-used reference footnote!), and converted the newspaper references to citation templates, giving proper credit to the authors and making for a more standardised appearance. Also, cleaned up some excessive descriptive text related to the HTML links – some of this was reading like an advertisement – and made some minor changes to such things as formatting, style and links. diff. —GrimRevenant 13:05, 10 March 2007 (UTC)

Retrieved from "http://en.wikipedia.org../../../t/r/u/Talk%7ETrueCrypt_af7d.html"