Talk:TrueCrypt/Archive 1

Archive 1

Archive 2

Archive 3

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.

In addition to what the previous commenter said... there seems to be an unwritten assumption that when using TrueCrypt, the machine you are using is secured. That is, if an attacker already had enough access that he could see your screen at any moment, you're already in trouble. If you cannot trust the machine and your environment to be secured, how much security could you possibly hope to gain by using an encryption tool on it? If someone is getting a peek at your keys, either you have been compromised already (to which there are many more serious consequences having nothing to do with TC), or something is wrong with your security model (letting people shoulder-surf while you're working, not such a good idea). --Robomojo 21:05, 8 April 2007 (UTC)

This is not necessarily true, especially in the case of portable computers. As emphasis on personal and business computing shifts to notebooks, tablets, and PDAs, the chance of your machine being physically accessible to unauthorized personnel increases. Erik Carson (talk) 21:48, 7 February 2008 (UTC)

How does that relate? You are echoing the same idea. I didn't say that your device could be secure in the hands of others, of course it cannot. There's no silver bullet if a serious adversary can get his hands on it while you aren't looking. This is getting a bit off topic now though. Robomojo (talk) 04:58, 8 February 2008 (UTC)

Exactly — if someone has access to your computer, they could install a keylogger, so all bets are off. -- intgr [talk] 02:25, 8 February 2008 (UTC)

Note to G-Man: "The Fat Man Attack" - How to defeat the Hidden container Plausible Deniability

1. Torture victim until they reveal the password to the fake container.

2. Fill fake container with files until it is full. (Yum yum)

3. Compare size of files inside container with the actual size of the encrypted file on HDD.

4. If the encrypted file on HDD is 2GB and you can only store 1.8GB inside - there is a 200MB hidden partition.

5. Beat the guy some more - because a normal TrueCrypt file will give you almost 100% of the space to use. —Preceding unsigned comment added by 86.16.148.246 (talk) 22:27, 10 June 2009 (UTC)

That will not work. Unless you specify both passwords (hidden and outer volumes), TrueCrypt treats the outer volume (what you call the fake container) as if it had the full capacity of both. See this document from TrueCrypt's website. Step 2 in your example would fill the entire outer volume with 2GB of data, destroying the hidden volume. – jaksmata 13:07, 11 June 2009 (UTC)

Thanks for clearing that up. Didn't realise hidden volume protection was a "per opening" option, I thought it would be auto enabled every time to protect against "accidents" :) —Preceding unsigned comment added by 86.16.148.246 (talk) 23:20, 13 June 2009 (UTC)

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)

Security of modes of operation

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)

Mido : I've just wanted to say, getting random unique IVs for CBC is still possible. A simple way is to encode the sector number in a way to be 128-bit (padding with zeros is OK), then encrypt it with the encryption key. As the sector numbers are unique, then the IVs are unique.

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

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)

A group working towards extending Truecrypt's cross-platform abilities has established a website at http://www.osxcrypt.org which redirects to a fundable.com website, with the following explanation.

Truecrypt is the leading product for encryption and plausible deniability. it comes in Windows and Linux flavors and is perfectly multi platform and usable.

The actual implementation, though, isn't compatible with MacOs X and multiple contacts with developers have resulted in nothing at all.

Considering this we've contacted a programmer, one of the leading core developers in ReactOs Operative System, which accepted to port the entire application in native MacOs X for $1.500,00.

The resulting project will be released in OpenSource as a Fork of the main project and freely available to all the community after the development. Repository will be held in SourceForge and the developed project will be fully compliant with the current implementation, thus allowing full disk and/or file based volumes, plausible deniability and inter operation with same files between Windows, *x and MacOs X.

To date, the effort has raised $680.00. 165.91.215.88 18:16, 12 October 2007 (UTC)

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)

Dropping of the GPL

It appears that, while the current official version history makes no mention of the dropping of the GPL license, previous versions did. I've found several forum posts appearing to be verbatim copies of the release announcement for TrueCrypt 2.1, which contain under "Miscellaneous" the phrase "Released under the original E4M license to avoid potential problems relating to the GPL license" – as well an old user guide with the same text, which I'm thinking is probably the most reliable source? —GrimRevenant 05:58, 1 May 2007 (UTC)

External Links

Would it be better if the discussions section of the external links was moved in with "TrueCrypt in the Press"? And maybe change the name to coincide. Then reduce the TrueCrypt official links section to just the main website. --Huntere45 05:05, 30 July 2007 (UTC)

Cryptanalysis & Credibility

Has anyone done any cryptanalysis or perform any sort of attack against the TrueCrypt volumes to prove its credibility?

Shin-chan01 (talk) 21:53, 17 November 2007 (UTC)

I don't quite know but I think that TrueCrypt volumes are impossible to crack using current technologies. Firstly, each volume is protected by a password/keyfile or encryption keys that must be entered/used untampered exactly in order to access the volume. Secondly, the main volume can be disguised as an innocuous looking file provided it isn't likely to be accessed using other applications that can corrupt the file. The volume is impossible to identify because it looks like random data until the volume is mounted. So if there are many files in the folder, provided you know the password, you'll have to try every single file until you get it. Even worse, since a password can be nearly anything, the brute force attack method has to be used, which can take literally forever. Thirdly, since there is an option to create a hidden volume, even if you managed to open the main volume, you'll still have to find the hidden volume inside, adding to the time it takes to get to your target files. All in all, TrueCrypt volumes are extremely secure if you take the proper steps and they are quite credible. --Bruin_rrss23 (talk) 06:24, 18 November 2007 (UTC)

However none of these are attacks against the design of TrueCrypt.

To the OP: no, I don't think there have been any public source code or design reviews. -- intgr [talk] 03:21, 19 November 2007 (UTC)

For the sake of the argument, since the software is free and open-source; it shouldn't be difficult for others to analyze and review the software's effectiveness of performance and security. If anyone has found a review or an independent report of the attacks against the TC software or its "encrypted" volumes, then I don't see the problem of posting the information into this discussion page. Shin-chan01 (talk) 17:14, 19 November 2007 (UTC)

XTS Support

I got a confirmation via the official E-Mail support that TrueCrypt is going to support XTS in Version 5.0 and that the functionality is already implemented. Please don't remove it as it is a really important information. —Preceding unsigned comment added by 84.56.158.11 (talk) 20:54, 20 January 2008 (UTC)

Personal e-mails are not verifiable, thus this will stay out until there is a reliable source. -- intgr [talk] 23:56, 20 January 2008 (UTC)

What about calling it a rumour then, because when a new user wants to decide between TrueCrypt and FreeOTFE this is certainly a decisive point. —Preceding unsigned comment added by 84.56.190.21 (talk) 13:02, 21 January 2008 (UTC)

Post it as a quote and reference the persons email address I suppose, or if you can ask the person to post the information on the website where it can simply be pointed to. Mrsteveman1 (talk) 03:05, 5 February 2008 (UTC)

Personally, I wouldn't say basing any decisions on rumour was a particularly sensible idea - especially when choosing security software! Besides, as intgr pointed out, private emails are not verifable, or reliable.

I'd wait until the next release before making assumptions. Nuwewsco (talk) 08:46, 5 February 2008 (UTC)

Turns out he was right, new version is XTS. Mrsteveman1 (talk) 06:40, 6 February 2008 (UTC)

Free license?

I put a dubious tag on the free license claim since it seems the email cited as a reference does not support the claim that it is free. ⟳ausa کui ^× 04:05, 12 April 2008 (UTC)

Yes, can someone clarify if it's "Free, Open-Source", since it doesn't seem to be on: http://www.fsf.org/licensing/licenses/ Ojw (talk) 13:25, 30 October 2008 (UTC)

It's the first line of content on the homepage of TrueCrypt's official website. You can download the software and source code for free there. – jaksmata 13:16, 31 October 2008 (UTC)

There's a mailing list thread on this licence starting here. :: MentalMaelstrom (talk) 08:31, 3 November 2008 (UTC)

Its the first line on the website. =P Smallman12q (talk) 00:57, 23 January 2009 (UTC)

The website claims that the license is free, but it seems pretty clear that a lot of people think it isn't. ⟳ausa کui ^× 23:26, 3 June 2009 (UTC)

Should this section make it clear that the software is freely available (source and binary) but for legal technicalities of compatibility with other FSF icenses it isn't FSF certified OpenSource. —Preceding unsigned comment added by 24.87.70.209 (talk) 21:45, 21 October 2009 (UTC)

Recent vulnerabilities

This Slashdot post is about a paper by Bruce Schneider that seems to indicate, that there are some new vulnerabilities in TrueCrypt. The paper itself is here. Subwy (talk) 23:30, 17 July 2008 (UTC)

Having no obvious header does not equal "plausible deniability"

Although the truecrypt changelog claims to have added "plausible deniability" in v1 - it didn't. If you have a 10GB container file, for example, pretending that it's not encrypted data simply isn't plausible. Why else would you have that volume of data stored away - especially when it can be proven that you had used truecrypt? v3 added hidden volumes, which can be plausibly denied. I've put back my edit to reflect this Cralar (talk) 19:40, 18 August 2008 (UTC)

That's original research, though. I think, if the changelog claims it, we should put that the changelog claims it, even if it isn't accurate. If a reliable source discusses its inaccuracy, then we can include that, too. --Sydius (talk) 19:45, 18 August 2008 (UTC)

[11] has details as to why it's not plausible, although I would have thought it obvious? v3 has hidden volumes, which pretty much covers it anyway Cralar (talk) 20:32, 18 August 2008 (UTC)

If the unmounted container is indistinguishable from random data, which it is, as it has no identifying features, it is plausible to state that the container could be anything. You cannot prove that the container is a container, that it contains any data, that it is encrypted, what it is encrypted with, or what had encrypted it. The TrueCrypt official changelog states that "plausible deniability" was added with v1.0.

Hidden volumes were added with v3.0. You know it, I know it, and the TrueCrypt official changelog states this.

The revert you made should be reverted. 72.88.213.114 (talk) 22:01, 18 August 2008 (UTC)

We could say it claimed to add it in version 1 (citing the changelog) but that the claim of plausible deniability is debated with a citation of some reliable source debating it. Without a good source, though, I still think it's original research to contradict the changelog. --Sydius (talk) 22:13, 18 August 2008 (UTC)

Lets review the facts:

* The TrueCrypt changelog clearly states that 1.0 adds plausible deniability.

"It is impossible to identify a TrueCrypt container or partition. Until decrypted, a TrueCrypt volume appears to consist of nothing more than random data (it does not contain any "signature"). Therefore, it is impossible to prove that a file, a partition or a device is a TrueCrypt volume and/or that it has been encrypted."

* The cited FreeOTFE.org link states "This [plausible deniability] claim is only possible with OTFE systems which do not embed any kind of "signature" into their encrypted data", and TrueCrypt has no such signature, as stated by the format specification, and as stated in the changelog. She (sdean) goes on to say that "this simplistic approach to plausible deniability has drawbacks." She agrees it IS plausible to deny such a volume, but in practice may not legally provide the same protection as having hidden volumes may add. As such I assume we would be interested staying in agreeance with the official Changelog, and the fact that it is plausibly deniable on a purely scientific and logical basis, and it should be reverted to the last ("Dscarth" as of 11:01, 18 August 2008) revision.

Dscarth (talk) 22:34, 18 August 2008 (UTC)

I don't think she is stating that it IS plausible to deny such a volume - far from it, the WWW site cited only refers to it as a claim (which is that it is), and details what that claim is - it doens't state that it's actually plausible, and goes give reasons why (i.e. it isn't plausible)

Sydius's comment seems sensible though, so I've reverted my edit. Cralar (talk) 22:55, 18 August 2008 (UTC)

I think your edit seems to be a fair compromise. Dscarth (talk) 22:58, 18 August 2008 (UTC)

Significant changes table.

I might be BOLD and overhaul this more but I think right now having the latest version separated might be better than having it as if the latest version added the changes? —Preceding unsigned comment added by Dscarth (talk • contribs) 04:45, 22 August 2008 (UTC)

In my opinion, the 'History' table should go as a whole, and be replaced by prose of truly important changes. Right now it's mostly listcruft; i.e. "we have to write something for every version because otherwise it would look odd". If anyone wants a detailed changelog, it's always available at TrueCrypt's site -- this is not what Wikipedia aims to be. -- intgr [talk] 09:42, 22 August 2008 (UTC)

Ah, I was thinking maybe changing it to 1.x, 2.x, 3.x, 4.x, 5.x and 6.x and so we just have a list of major points for each of the major releases... which I suppose is another step closer to prose. Dscarth (talk) 03:55, 23 August 2008 (UTC)

Compatibility

Is TrueCrypt compatible with any other programs? I.e. for an encrypted file, do you need to use TrueCrypt to unencrypt it, or just the encryption algorithm and the password? Or another program? If so, this should be noted.

Coolhandscot (talk) 04:04, 29 August 2008 (UTC)

Backdoor for national security issues?

At de:Diskussion:TrueCrypt#Glaubwürdigkeit des Codes bzw seiner Programmierer (German) is a discussion about the possibility of a backdoor forced by the U.S. government in either the source code or at least the downloadable binaries of TrueCrypt due do national security concerns. In a German talk forum of heise.de there had been concerns that, although the freeely available source code might contain no backdoor that otherwise would have been revealed by reviewers quickly, the downloadable binaries might have been built from a modified, non publicly available source that includes a secret backdoor for the NSA or CIA. Of course, such a backdoor wouldn't be used for anything minor than top-level terrorism (9/11-like) or in war times, since no government would waste such a joker just for copyright (or even child porn or drugs) issues. Since there is no evidence for such a backdoor, it might not have space in the article yet. However, are there reliable arguments against the existence of a (source or binary-only) backdoor, i.e. that the existence of such an NSA "joker" might simply not be plausible at all (e.g. due to other exististing strategies other than cracking the encryption)? If so, such arguments should indeed be mentioned in the article.

One argument supporting the existence of a backdoor might indeed be the fact that TC, although developed in the U.S., can be exported via the internet to other countries. I remember a U.S. law being mentioned that prohibits the export of strong crypto algorithms to other countries unless there is a special permission by the government. Therefore, the fact that TC can be exported legally implies that U.S. intelligence has the ability of cracking it (and according to the high security level of the algorithms this could only be achieved by a backdoor). Or has this law been removed meanwhile or can be circumvented by a suitable disclaimer?--SiriusB (talk) 12:24, 27 October 2008 (UTC)

I don't know the details of the laws, but my understanding is that the government essentially gave up prosecuting people for exporting of encryption software. Philip Zimmermann is the only one I know of who had to deal with the government over this kind of thing, and even he wasn't prosecuted. There are laws that allow books to be exported, no matter what they contain (as long as the publishing of such a book would otherwise be legal in the US). Since software can be published as a book (the source code), it effectively gets around the ban on exporting any kind of software, and that is what Zimmermann threatened to do (I don't remember the details, though) and the case was dropped before it began. --Sydius (talk) 17:32, 27 October 2008 (UTC)

Option 2 (gov. gave up) seems more likely but option 1 is more fun and makes for better movies 121.209.147.52 (talk) 08:28, 1 November 2008 (UTC)

Perhaps, but if you compile the source code in the manner they tell you, you get the same md5,sha256, and sha512 hash.Smallman12q (talk) 00:59, 23 January 2009 (UTC)

Actually, the NSA or other countries security agencies might use such backdoors to compromise trade secrets if they are wort enough for the own country's economy. So, it would be pretty serious if there where such backdoors.
—Apis (talk) 09:35, 17 April 2009 (UTC)

Forums and Support

I think it's worth noting that it is nearly impossible to get official support for Truecrypt. The vast majority of email communication goes unanswered and forum sign ups nearly always fail to allow the user to post messages. Even if you're one of the small minority whose forum sign up is successful you, along with existing users, then face the increasingly heavy moderation and censorship of forum posts. Link 121.209.147.52 (talk) 02:46, 28 November 2008 (UTC)

Nope. Not unless it's been picked up by reliable sources. This is an encyclopedia, not a manual to using the Internet. Chris Cunningham (not at work) - talk 10:15, 28 November 2008 (UTC)

You have missed the point but thank you for sharing your compelling argument. 121.209.147.52 (talk) 11:09, 28 November 2008 (UTC)

If the "point" was to vent on this talk page, I'm just going to remove this thread as chatter. Chris Cunningham (not at work) - talk 12:41, 28 November 2008 (UTC)

Sorry to disturb your argument but I think the original comment is of relevance at least for the discussion page as may reflects on how trustworthy people judge the source of Truecrypt to be. I agree that it should stay out of the article unless others can confirm the "censorship" etc. —Preceding unsigned comment added by 212.186.105.130 (talk) 16:06, 11 January 2009 (UTC)

Authors

Who wrote Truecrypt? Why do they not offer CVS of source? —Preceding unsigned comment added by 69.180.219.27 (talk) 17:06, 11 January 2009 (UTC)

False address and developers identity

I've just deleted a number of unsourced claims about the TrueCrypt developers banning users who made attempts to prevent anyone wanting more transparency about its development on their forumns.

However, the false address used to register the domain name issue is interesting. I've kept this in as a very pertinent fact, given this is security software.

ISTM that if the TrueCrypt binaries are signed, the developers must have published their full details somewhere - the whole point of signing software being that you can verify who published it, and ensure it came from a trusted source. I'm not entirely sure how to go about a citation for the registration (contact) details for the TrueCrypt signing certificate in order to balance out this section though. Any suggestions? Nuwewsco (talk) 23:34, 12 January 2009 (UTC)

I agree with your general intent, and have reverted some of the article, improved some grammar, and added an additional reference. -Dscarth (talk) 06:12, 19 January 2009 (UTC)

This is the original section for reference:

Security concerns

TrueCrypt's hidden volume deniability features may be unintentionally compromised by third party software which may leak information through temporary files, thumbnails, etc, to unencrypted disks. In a recent study, Windows Vista, Microsoft Word and Google Desktop were evaluated and found to have this weakness. In response to this, the study recommends using the hidden operating system feature now available in TrueCrypt versions 6.0 and later. However, the security of this feature was not evaluated because it had not yet been released at the time.

Developers identity

The TrueCrypt developers use the aliases "ennead" and "syncon", whose real identities are unknown.

The domain name "truecrypt.org" was originally registered to a false address ("NAVAS Station, ANTARCTICA"), and was later concealed behind a Network Solutions private registration.

The TrueCrypt trademark was registered in the Czech Republic under name of "David Tesarik".

Transparency

Moderators on the TrueCrypt forum have banned users insisting on more transparency related to the application's authorship.

Developers motives

The article should attempt to address the developers motives for hiding their identity. If the identity and motives of the authors of TrueCrypt were known, it would help inform the users of TrueCrypt about the security of TrueCrypt as well as to the likelihood of deleterious or illegal purposes of the authors of TrueCrypt, for example, if the author was Al-Qaeda, North Korean, a Scientologist, or a well-respected scientist. If preventing public speech prevents the discovery of truth about deleterious or illegal purposes, then a broad spectrum of freedom of speech case law consistently supports greater freedom of speech rights under the U.S. Constitution. 99.38.150.192 (talk) 21:44, 28 August 2009 (UTC)

Licensing

The TrueCrypt Collective License is considered "non-free" (based on the Debian Free Software Guidelines) because its license has an "advertise-me" clause (similar to the type that caused the XFree86/X.Org split) that requires TrueCrypt to be named in any derivative work.

Regarding this section, it needs to rewritten for neutrality as it narrowly defines open source into a notional activist definition and it attempts to mislead the reader into believing the software is "dangerous" to the user. In fact, the software is open source by the generic definition: 'of or relating to or being computer software for which the source code is freely available' (http://wordnetweb.princeton.edu/perl/webwn?s=open-source), and the software is only potentially "dangerous" (whatever that means) to entitles like Fedora who might attempt to modify / redistribute Truecrypt as part of a fee based package. The rewrite should clearly indicate that Truecrypt's license doesn't meet a notional (non-legal) definition of open source as it pertains to redistribution and entities like Fedora that are desiring to modify / redistribute software as part of a non-free software package are "claiming" that the software is dangerous for THOSE purposes - Fedora's recommendation is obviously biased. If one believes the software license is generically dangerous to all users (not just those who intend to redistribute it for money), than state exactly HOW the software license is dangerous and provide the factual citations to that end.Markbyrn (talk) 11:10, 31 May 2009 (UTC)

I'm going to remove the quote for being unnecessarily biased and unsourced. Although we know exactly who said it, why they said it hasn't been disclosed, therefore can't be rebutted and that makes it POV. From the fedora website, this is the guy who called it "dangerous" (and also "horrifying"), but he gives no real reason. The unsupported opinion of just one guy gives undue weight to the argument that the software is "dangerous". Like Markbyrn suggested, I agree that this kind of language should be excluded from Wikipedia unless it can be supported by facts.

Digging into it a bit more, I have some theories as to why it might be "dangerous":

• It was developed by several separate developers, each of whom have their own license section (see the license here). Mutually exclusive requirements of those licenses may be the "danger".
• There are laws in several jurisdictions (the United States, for example) that prohibit export of cryptographic technology. Users who redistribute or use the software in accordance to the license could be in legal "danger" because of export laws based on where they live and where the software was written.

These are, of course, just my theories. Personally, I believe that the risk of being sued just for being an end-user of TrueCrypt is zero. It's been out for over five years, and I don't believe any end user has been sued yet. – jaksmata 16:16, 1 June 2009 (UTC)

I just want to mention this post, http://lists.freedesktop.org/archives/distributions/2008-October/000276.html , which I think gives atleast some clues to what is being objected to in the license. --80.169.179.210 (talk) 05:44, 10 July 2009 (UTC)

Thanks - that's a very interesting link, written by the same guy who originally called the TrueCrypt license "dangerous" and it answers exactly what he thought was dangerous. He has three complaints: the first about ambiguity of source code requirements, the second about an implied "promise not to sue" and the third about a waiver of intellectual property rights. After comparing his quotes to the current TrueCrypt license ([12]), it's obvious that the second and third complaint have been addressed by TrueCrypt in their license since October 2008 when he wrote about it. His suggested changes for those two complaints, while not verbatim, have been incorporated into the license. The first complaint (ambiguity) is a bit more difficult to analyze with respect to the current TrueCrypt license, but the license has changed from what he quoted last year.

At any rate, all of the complaints he had about the license referred to dangers involved in modifying and/or distributing copies of TrueCrypt, not in using TrueCrypt as an end-user. – jaksmata 14:13, 10 July 2009 (UTC)

How does TrueCrypt's pre-boot authentication/full disk encryption work?

What I don't understand is:

1. Computer is turned on
2. TrueCrypt bootloader starts up, asks for password
3. password is entered, therefore data can be decrypted
4. for the whole boot process, data needs continously be decrypted. This requires some sort of decryption mechanism

Is TrueCrypt therefore running in a higher mode than the to be booted OS, such as rootkits do? What "thing" implements the decryption mechanism during the whole OS start/run/shutdown phase?

Thanks, --Abdull (talk) 13:59, 10 April 2009 (UTC)

No, TrueCrypt works like a Windows driver. Before control is passed to the kernel, the NT bootloader enumerates Windows registry for drivers that must be loaded on boot. These include disk drivers as well as TrueCrypt itself. So by the time the kernel is invoked, it already knows how to decrypt your disk. -- intgr [talk] 23:43, 18 April 2009 (UTC)

Aha - thanks, this already makes sense by now (with some help of Windows Vista startup process#winload.exe). Shouldn't then there be an entry for this TrueCrypt driver in the Device Manager? I cannot find one in mine. --Abdull (talk) 20:29, 20 April 2009 (UTC)

No, because it's not a device driver, i.e. it doesn't introduce any new devices to the system, just mediates access. I'm not sure if calling it a "driver" is entirely correct in Windows kernel lingo, but you get the point. :) -- -- intgr [talk] 13:13, 21 April 2009 (UTC)

Yes, you can see it. Choose "View - Show hidden devices", expand "Non-Plug and Play drivers" and you should see its driver. —Preceding unsigned comment added by 117.0.132.205 (talk) 14:01, 15 August 2009 (UTC)

"Security concerns" section needs some work

Why are the two points 'Developers' identities' and ' Licensing' under 'Security concerns'?

Perhaps you could construct an argument how not knowing the true identity of the developers of some encryption software could be considered a violation of trust, but there is no such argument in this section at the moment, just the plain fact that the developers use pseudonyms. Similar problem for the 'Licensing' information.

I would like do delete those two points, unless someone comes up with a coherent argument why those two points constitute a security concern. Alternatively, I could put them into a new section of their own. In any case, I strongly dislike the way it looks now. Any thoughts on this?

Minvogt (talk) 14:26, 15 April 2009 (UTC)

I think you can argue the developers identity is a valid security concern, though it doesn't make sense to have licencing in that section; it would better moved to a section on it's own. Nuwewsco (talk) 19:07, 15 April 2009 (UTC)

I agree 100% with Minvogt. If this was closed source, then the hidden identities would be a concern, but being open-source (as in: source-available), I don't think that is a concern, if it is, it should be explained. Regarding the license part: it's even worse, it almost looks like software under GPL or similar license is OK/secure and software not under that kind of licenses is not secure. Remove it ASAP in my opinion. Cheers -- SF007 (talk) 21:14, 15 April 2009 (UTC)

Additional note: I just removed the two subsections 'Developers' identities' and 'Licensing' that I mentioned above. In the form that they appeared they simply didn't belong under 'security issues'. By doing so, I also removed a large part of a new edit by Cronopios. He had an interesting point about a licensing debate concering TrueCrypt, but it was written an unacceptable rant against the software, and in addition just doesn't belong under 'security concerns'. Note however that I did not revert his change from 'open source' to 'Proprietary, source available', as this seems justified.

Cronopios, if you're still interested, please add the information about the licensing debate that seems to exist again, but you might want to read NPOV first.

- Minvogt (talk) 14:53, 21 April 2009 (UTC)

inclusion on Super OS repository relevant?

The article says many distros do not include TrueCrypt on the repos, however, I noticed Super OS includes that in the repos. Do you think that info is relevant to be included in this article? 85.241.113.69 (talk) 22:43, 10 July 2009 (UTC)

Weasely synthesis

Regarding this edit, which restored some text that I deleted: There is no source given stating that File Investigator and/or TCHunt have been used to establish these legal standards, so I've tagged it as "citation needed".

Quoting from Wikipedia:Verifiability: "The burden of evidence lies with the editor who adds or restores material. All quotations and any material challenged or likely to be challenged must be attributed to a reliable, published source using an inline citation. The source cited must unambiguously support the information as it is presented in the article." - So let's see a source. Stating that it's the "same principle" is original research. Either add a source saying that File Investigator and/or TCHunt have been used to establish these legal standards or leave it out.

I've also tagged "can certainly" as a weasel statement, since there's no evidence to support what is claimed to be certain. – jaksmata 19:47, 29 September 2009 (UTC)

I've added a reference to support it; it's not difficult to see why it would be suspicious. Nuwewsco (talk) 20:59, 29 September 2009 (UTC)

That reference says nothing whatsoever about using File Investigator and/or TCHunt to establish reasonable suspicion or probable cause for a crime. It talks about using encryption software (not TrueCrypt) to establish plausible deniability. What is and isn't suspicious is a matter of opinion and not verifiable. The threshold of inclusion in Wikipedia is verifiability, not truth.

There still is no source given stating that File Investigator and/or TCHunt have been used to establish these legal standards by "detecting" TrueCrypt volumes, or even that they could be used in such a manner by police/prosecutors. – jaksmata 21:49, 29 September 2009 (UTC)

Evil maid attack

The newest attack against TrueCrypt (by Joanna Rutkowska), apparently more dangerous than Stoned: http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html GregorB (talk) 15:12, 23 October 2009 (UTC)

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)

Because it is completely encrypted, a truecrypt file would appear random. If it doesn't appear random, then the encryption failed. There is no way(or so I believe) to identify a truecrypt volume unless its labeled as such. It would appear as a mass of random data. —Preceding unsigned comment added by Smallman12q (talk • contribs) 00:52, 23 January 2009 (UTC)

You guys should see http://www.forensicinnovations.com/blog/?p=7 ==> there's some user stories where they have practical evidence that indicates the detection is no different than detecting "random data", and that these mechanisms flags go mad when they see random data.

Random "implies" truecrypt volume is NOT a form of detection. And, quite frankly, it's wrong! QUOTED from the forensic innovations comments on their site, in the above referenced link:

"What is the probability of such random files appearing on a typical user’s system? Why would any typical user application create such a random file? None of the systems we have tested contain such files, so it appears that you have to intentionally create such files solely for the purpose of tricking detection tools. If typical systems do not contain such random files, then our solution is quite useful in the real world."

This is NOT a factual detection or a proper proof, but instead an argument that specifically testifies that "I saw random therefore I think it's encrypted", which is scientifically speaking, BULL, and would NOT stand up in court to provide evidence of a truecrypt volume.

You're misrepresenting what's being said there - they are not saying "random data == encrypted data". As to whether it would stand up in court, this is something that could only be decided on a case-by-case basis and in light of all relevant circumstances. Nuwewsco (talk) 19:51, 5 March 2010 (UTC)

Several bogus "concerns" need to be removed

As already supported during this week by valid arguments (and, unfortunately, incorrectly called "vandalism"), several bogus "concerns" need to be removed:

You have repeatedly attempted to start an edit war in violation of Wikipedia's policy, despite calls from several editors to discuss your deletions first. It's only now, after I requested the page to be protected and you can no longer delete things, that you've finally decided to talk about your issues.

Thankyou for finally doing this.

Making edits supported by valid arguments is not a vandalism. Reverting all such edits at once is a vandalism -- unfortunately this lead to the edit war. Bookew (talk)

Rest this case, please. Arguments are irrelevant if you refuse to hold a civil discussion. And you refused to start a discussion, despite being asked to do it by 3 different people on 1, 2, 3, 4, 5, 6, 7 occasions. It turned into an edit war because you alone kept reverting back to your own version — not because we were trying to preserve the original state that reflected WP:CONSENSUS. -- intgr [talk] 18:29, 22 February 2010 (UTC)

The problem is that my edits (including minor) were falsely labeled "vandalism". Bookew (talk)

True. -- intgr [talk] 00:48, 24 February 2010 (UTC)

---

Concerns: Identifying TrueCrypt volumes

TrueCrypt documentation states that containers without a hidden volume do not provide plausible deniability. Therefore, this "concern" is bogus -- it ignores the security model of the application.

Many people think that the lack of any identifying information within a volume provides security.

Until version v6.2, this included the Truecrypt developers, when they finally changed their views on this (see the documentation included with all earlier versions)

It doesn't provide security, as I think you understand. This section states this fact quite clearly.

It would make sense to include the fact that this myth was promoted by the Truecrypt developers in all releases up to this version though.

It is clear before 6.2 it was left up to the user to decide whether the random container alone is deniable (called first level of deniability IIRC). For example, one could claim that he often analyzes RNGs and hide a TrueCrypt volume among other random files (dd from /dev/random). This cannot be called a "myth". What can be called a myth are tools like Tchunt which should actually be called "Randomhunt" (see the dd example). Bookew (talk)

I agree with Moonrader here, the presense of massive files with high entropy is pretty suspicious; a big file with high entropy may not contain encrypted data - but as the article states, it's certainly enough to generate reasonable suspicion, especially on a PC with traces of disk encryption software on it! The truecrypt authors do seem to agree with this (see their WWW site). The existing article text is very clear here in what it says, and I can see no reason to remove it. Nuwewsco (talk) 20:32, 22 February 2010 (UTC)

The reason for removing this article is that it is actually no valid "concern" about TrueCrypt. The documentation states that containers without hidden volumes do not provide plausible deniability. Bookew (talk)

The documentation used to claim it and it's still a common misconception among users. That said, the section can really use some rewording. -- intgr [talk] 00:48, 24 February 2010 (UTC)

I would not call this a misconception. The deniability clearly still works. For example, storing files containing random data as a result of testing RNGs and hiding TrueCrypt containers among them. What matters here is that tools like Tchunt can't differentiate between a TrueCrypt volume and a dd-copy of /dev/random. Bookew (talk)

That's the theory. The reality is that on balance of probability, such files found on any computer are considerably more likely to be encrypted volumes rather than alleged "RNG test files". As the Truecrypt WWW site states quite clearly: "there is practically no plausible explanation for the existence of a file containing solely random data". Whether TCHunt can differentiate between a truecrypt volume and a genuine file containing RNG output (which are typically much smaller) is irrelevant - and this is already covered in the existing article as-is. 01:09, 26 February 2010 (UTC)

See my example for a case where it would be impossible to prove whether a file is a TrueCrypt volume or a file full of random data. Bookew (talk)

Concerns: The "Stoned" bootkit

The "Stoned bootkit attack" ignores the security model of the application -- the attacker is required to have administrator privileges.

"Stoned" doesn't need administrator privileges. Please read the article. It is a program which targets Truecrypt, and is therefore highly relevant and of concern to anyone who wants to know how it can be attacked. —Preceding unsigned comment added by Moonradar (talk • contribs)

Indeed the Stoned bootkit is a very real and practical attack. Even if you shut your laptop down, just leaving it anywhere unprotected makes it vulnerable to this attack. -- intgr [talk] 17:26, 21 February 2010 (UTC)

It does not matter whether administrator privileges or physical access is needed. Both types of privileged accesses ignore the security model of TrueCrypt. This "attack" is definitely a bogus. Bookew (talk)

You are right, this attack bypasses TrueCrypt's security model. And it applies to pretty much any disk encryption software. The whole point of the attack is that the disk encryption security model does not apply to some significant real-world scenarios. Does this make the attack irrelevant or bogus? No. It's like accusing the attacker of "cheating" — because they were not playing by the "rules" (TrueCrypt security model). -- intgr [talk] 18:49, 22 February 2010 (UTC)

intgr's right - this is a good example of a museum having strong locks, robust doors, and metal grills over the windows - only to have burglars drive a JCB through a wall in order to steal the paintings inside. I think it makes sense to leave this section in; the subject is treated fairly in the existing article text, and I can see no reason to just delete it all Nuwewsco (talk) 20:32, 22 February 2010 (UTC)

This "bootkit" is security-wise the same as a hardware mini-pci keylogger which can be installed in a notebook (search google for the shops selling this). Physical security is a prerequisite of a secure system. That's why this article does not describe a concern about TrueCrypt but actually a concern about physical security. Bookew (talk)

Yes, but Stoned is specific to TrueCrypt's MBR, so it makes a lot of sense to cover it in this article. Again, you're welcome to try to improve the section, but you'll never get away with deleting. -- intgr [talk] 00:48, 24 February 2010 (UTC)

Should a section "Concerns: Mini-PCI keyloggers can be installed in notebooks" be added here? The list of such concerns would be endless. The list of malware like this "bootkit" is also potentially endless. Bookew (talk)

"Mini-PCI keyloggers" aren't Truecrypt specific. Stoned is, and is certainly relevant, hence its inclusion. Nuwewsco (talk) 01:09, 26 February 2010 (UTC)

Attack A: Hardware keylogger

Attack B: Infected MBR

Solution 1: By protecting MBR, you avoid only attack B.

Solution 2: By protecting physical security, you avoid attacks A and B.

Which solution is required? Bookew (talk)

This is a red herring. The argument is not about whether there are defenses against this attack. The argument is about whether the Stoned bootkit is relevant to the TrueCrypt article. Stoned is relevant — and so are protections that would defeat the Stoned attack. I think it's important to remind you that The threshold for inclusion in Wikipedia is verifiability, not truth. -- intgr [talk] 18:59, 1 March 2010 (UTC)

Why should this attack be a concern about TrueCrypt? It is a concern about physical security. TrueCrypt documentation states that physical security is a requirement for using TrueCrypt (for a good reason -- see other attacks like hardware keyloggers). Bookew (talk) —Preceding undated comment added 16:54, 3 March 2010 (UTC).

"Physical security" would also seem to imply making sure that the attacker can never have access to the physical computer. However, if a user can guarantee this, then why does he even need disk encryption for? His disks are already secure.

To the contrary, physical theft and loss of laptops is perhaps the main use case for TrueCrypt, and TrueCrypt indeed successfully protects the user in these scenarios. So "physical security" is certainly not the right term to use.

But back to Stoned. Instead of trying to delete sections that you disagree with, you should be finding ways to change the article so that would be more fairly represented — that should be your mindset when editing articles. For instance we can start the section off with wording like "TrueCrypt cannot protect the user from someone physically tampering with computer hardware. Such physical tampering can bypass the security of TrueCrypt. A known example of physical attacks is the Stoned bootkit that [yadda yadda]..." -- intgr [talk] 17:56, 3 March 2010 (UTC)

"Physical security" is certainly the right term to use (the attacker needs physical access). Encryption cannot protect physical security and, therefore, the article should be deleted as it does not describe a valid concern about TrueCrypt. Is a hardware keylogger device a valid concern about TrueCrypt or about physical security? Bookew (talk) —Preceding undated comment added 16:17, 4 March 2010 (UTC).

Why would you encrypt your disk that is already safe? What's the purpose of TrueCrypt if it can only "protect" disks that are already physically safe? Think about it. -- intgr [talk] 17:24, 4 March 2010 (UTC)

Encryption can protect your data in case of a loss or theft. Encryption makes no sense if an attacker can, for example, capture the contents of the RAM of your computer. Bookew (talk) 16:27, 5 March 2010 (UTC)

This is exactly what I stated about loss and theft, 4 comments above. The point I was making is that losing a laptop has everything to do with "physical security" — you lose the physical item — so it's the wrong term to use. The attacks that TrueCrypt doesn't protect against can be summed up as tampering (or, obviously, when you lose it while your drives are unlocked). -- intgr [talk] 21:48, 5 March 2010 (UTC)

The documentation talks about protecting the physical security in order to prevent an attacker from tampering with the computer. Bookew (talk) 17:08, 6 March 2010 (UTC)

I don't think the stoned bootkit is an attack on truecrypt at all. If the stoned bootkit is an attack on truecrypt, then so are all general MBR infectors. Privileges have already been escalated to the point where one can interact with the hardware, therefore it's already been won. mbr infectors/bootkits/rootkits are all things that are just code loaded for post-exploitation. they aren't tools for "attacking" software such as truecrypt. the attack in this case is unnamed unless someone escalates privileges themselves (which i bet he did and then he jumped to a conclusion, he is 18 after all). All the stoned bootkit is, is just a piece of truecrypt's history. I think that's what people are trying to say, but that section is very fucking convoluted. — 66.68.167.173 (talk) 05:55, 11 March 2010 (UTC)

Stoned is notable simply because it generated significant media coverage, not because we claim it's a valid attack (see WP:V). What makes Stoned more relevant, compared to a random hardware keylogger or MBR rootkit, is the fact that it's TrueCrypt-specific — where else would we cover it, if not in the TrueCrypt article? -- intgr [talk] 22:53, 11 March 2010 (UTC)

"The "Stoned bootkit attack" ignores the security model of the application -- the attacker is required to have administrator privileges."

1) It's no good to the person whose sensitive data has been stolen to be told that the attacker wasn't using a "valid" attack is it? The section is called CONCERNS, not what some people consider to be "valid" attacks.

2) Did you notice that ALL of the security concerns could be applied to other encryption software as well??? I don't see any problem with adding in keyloggers, other rootkit attacks, RAM sniffers etc. in with the concerns if they are widely-held concerns, you can put them in the same paragraph. But keep in mind that the stoned bootkit was the very first rootkit to get the keys of truecrypt, the others copied stoned bootkit. Perhaps you could call it Rootkits and begin with: "A number of rootkits, starting with the stoned bootkit". The rootkits don't affect Bitlocker.

3) The reason that rootkits like the stoned bootkit and its derivatives are of such concern to some people using Truecrypt is because it provides the only possible way that Law Enforcement can decrypt their hard drive and prosecute them, barring a massive, unlikely, covert investigation. Now do you understand why it's a big deal? They can be infected with these rootkits by executing a file they find on the internet, they could not possibly do that before the stoned bootkit and so could have been swarming with viruses and it wouldn't have mattered for law enforcement purposes. Other types of rootkits would not work with Truecrypt because they were not designed for it and there would not be space on the MBR.

4) You are also wrong in your assertion that the attacker has to have administrator privileges, he can have physical access to your computer twice with no administrator privileges. Anonywiki (talk) 23:02, 26 May 2010 (UTC)

Concerns: Developers' identities

This section is trying to cast doubt about TrueCrypt (a deliberate work of a competitor?). Obsolete information from whois records is presented as a reason for worry. Obvious explanations for an anonymous/incorrect whois record include: privacy and spam protection. Trademark registration information cannot be used to identify the developers of the product. The developers alias information is inconsistent with the Contact page on the official web site.

This is a valid concern - falsifying details on their domain registration, a trademark registration in one country, an address on their WWW site in another... If you're depending on a piece of software to protect your security, knowing that it comes from an honest and trustworthy source may not be an issue for you, but it is a very serious issue for most people! Truecrypt may be a popular program, but that doesn't mean nobody should question where it came from. —Preceding unsigned comment added by Moonradar (talk • contribs)

Unfortunately this section in the article seems to be mainly original research, so I'm not too fond of it. -- intgr [talk] 17:26, 21 February 2010 (UTC)

Protecting against spam or protecting one's privacy does not affect the security of TrueCrypt. Bookew (talk)

I'm not sure how this can be seen as original research? It does include citations, and is certainly verifyable. There's a lot of trust involved in using security software - especially for non-technical people who are unable to review source code; let alone build it (which does require money to buy the compiler, setup the build environment, etc). As another editor commented, this is something likely to be a serious concern to some users.

As far as the authors "protecting their privacy" - that is as assumption. It's quite possible this is what they were trying to do this (they don't want anyone to "find out" who they are) however,

1. there is no need to falsify information in order to achieve this aim
2. it isn't possible within the security model that they are working under (i.e. Microsoft requiring device drivers to be countersigned, which must by extension allow the publisher to be tracable) Nuwewsco (talk) 20:32, 22 February 2010 (UTC)

Yes, the binaries are signed by a digital signature of TrueCrypt Foundation. AFAIK whois records leak personal information and this cannot be disabled. Bookew (talk)

@Nuwewsco: I think it's an inappropriate use of primary sources (referring to WHOIS results) because the article adds editor's interpretation of the material. Especially listing these as a "concern" cannot be attributed to an actual source. -- intgr [talk] 00:48, 24 February 2010 (UTC)

It doesn't actually give an interpretation that I can see, it just presents the facts and leaves it up to the reader to draw their own conclusions. As Moonradar pointed out, trust is a serious issue where security software is concerned, and it's certainly relevant to include this. Nuwewsco (talk) 22:23, 6 March 2010 (UTC)

The article presents obsolete information to give an impression there is currently a reason to worry about TrueCrypt. As I said already, if someone wants to be, for example, protected against spam, there is no reason to distrust TrueCrypt. The fact that someone uses an anonymous whois record does not make him/her an untrusted person -- that is only your speculation. Bookew (talk) 16:22, 7 March 2010 (UTC)

Bookew - This is the eighth time you've deleted this section, and had your deletion reverted by about six different editors. Please stop doing this - it's clearly not constructive, and doens't help anyone; the consensus is clearly against you here. 22:28, 6 March 2010 (UTC)

The reverts were not supported by valid arguments. Bookew (talk) 16:22, 7 March 2010 (UTC)

Since the sub-sections on "Developers' identities" and "Licensing" don't specifically mention any concerns (as of right now), I suggest moving them out of the "Concerns" section and into their own respective sections. The information they contain is verifiable and possibly important, but whether or not it is concerning should be left up to the reader unless there is a specific, verifiable source that says that these facts are concerning.

Hopefully, that change will placate both the parties who say the information is valid and important, and those who say it does not indicate a valid concern. – jaksmata 20:28, 8 March 2010 (UTC)

I don't think that's a good idea - you could just as well say the same about the rest of this section. As it stands now it does leave it up to the reader how important it is. It would be better to leave this section as-is, and ISTM that the other editors who have reverted Brooke's changes agree. Moonradar (talk) 21:04, 8 March 2010 (UTC)

Where's the verifiable source that says the facts about the developer's identities are a "concern"? I've read everyone's original research and synthesis on why it's a concern here on the talk page... Now how about a source? Otherwise, I don't see why that info belongs in a section named "Concerns". – jaksmata 15:18, 10 March 2010 (UTC)

I, for one, agree with jaksmata. -- intgr [talk] 19:16, 10 March 2010 (UTC)

Open source

Last but not least, the security of the product is based on the fact that it is open-source (it can be reviewed).

Bookew (talk) 17:41, 20 February 2010 (UTC)

As anyone with an interest in open-source security software can confirm, being open source doesn't mean that anyone has acutally reviewed the source! Nor does it give any indication that the binary distribution (which the overwhelming majority of users will actually run) was actually built from the published source.

Being open source is better tham closed source source software, but being open source isn't a proof of security, unless:

1. You review the source, or have it reviewed by a competant and trusted party
2. You use a version built from the reviewed source

Moonradar (talk) 19:24, 20 February 2010 (UTC)

Open-source products are trusted because any backdoor can sooner or later be found. This is not true for closed-source products. Published binary can be compared to match the source code -- there is no need to rebuild from source. Bookew (talk)

Umm... How exactly would you compare a binary to source code, Bookew?! :) Nuwewsco (talk) 20:32, 22 February 2010 (UTC)

A reviewer can build binaries and compare them (make a diff of disassembler listings) with the official binaries. Bookew (talk)

That requires rebuilding from source - which you said wasn't any need for. Nuwewsco (talk) 01:09, 26 February 2010 (UTC)

An ordinary user does not need to rebuild from source. Reviewers make that unnecessary. Bookew (talk) —Preceding undated comment added 16:23, 26 February 2010 (UTC).

It's not really "open source" in terms of development methodology. The software is developed under a blanket of mystery; changes are not discussed publicly, there is no public version control repository, they are not trying to build a developer community, etc. And the license is debatable as well. TrueCrypt is what open source developers call "viewable source". -- intgr [talk] 17:26, 21 February 2010 (UTC)

I looked at some public version control databases and found them hard to review. Development of computer programs involves many changes on identical places until a final version is reached. Actually you spend time "reviewing" something which does not need to be reviewed (a code which was later replaced by a different code).Bookew (talk)

Source code control systems are an extremely valuable tool, and form part of best practice within the industry. This applies to any software development - not just security software. They means that you can see what changes went in, why change was made, gives accountability for change, can be linked in to fault tracking, etc (the article on source code control should give further insight as to why they are so critical in practically all non-trivial software engineering projects).

Having access to the source code control system used is good, and provides a very "open" way of working, which is why so many open source projects offer access to their code control system (it fits the ethos of openness!)

Brookew - your comment about "reviewing changes which were later backed out" sounds more like user error on your part. I'm not being judgemental when I say that - most people who have only ever worked on small projects often can't see the point of code control. All the time they have to "waste" spent checking in files, "wasted" checking out, "wasted" entering checkin comments, "wasted" because someone has an exclusive lock on a file they need, etc. On small-scale projects, you can get away without the using source code control, but when you start working on larger systems though, it's a different story. You quickly realise that it's more of a necessity than a pointless bureaucracy, and begin to realise that you can do a lot more things much more efficiently within a code control system than without one (e.g. reviewing changes!) Nuwewsco (talk) 20:32, 22 February 2010 (UTC)

If you check the final version of a source module only, you do not need to analyze every development change (later replaced by several different changes). You check a much smaller number of diffs. One thing that comes to mind is that public source repository is vulnerable to hacker attacks (a backdoor could be injected to the code). Bookew (talk)

Please keep your discussion focused on the article, Wikipedia is not a forum. :) -- intgr [talk] 00:48, 24 February 2010 (UTC)