TrueCrypt--Practical Questions

Hi Guys!

I wonder if someone could answer the following practical questions about using TrueCrypt.

For the sake of argument the only thing we are concerned about here is a TrueCrypt set up with an encrypted system disk and a separately encrypted data partition. No hidden stuff involved.

1. How does TrueCrypt handle the page file? If I set Windows to clear the page file, is Windows going to do something like write Hex 00 everywhere? If so, how does TrueCrypt handle this--since if it were to do a straight encryption it would in essence be giving clear text to the adversary who could then easily figure out the key? What is the best way to handle this?

2. Let's suppose that I do an NSA wipe on the data partition before I set it up under TrueCrypt. How important is it to do this wipe before running TrueCrypt to set the partition up as encrypted?

3. TrueCrypt is going to fill with random characters before I actually move data into the new data partition. What happens, however, if after I have set the partition up under TrueCrypt:

a. I defragment the partition. Is everything going to be fine because the defrag program is moving encrypted files around?

b. I wipe free space, say with an NSA wipe. Is this going to defeat the TrueCrypt random fill, again creating clear text for the adversary? Is this something that should be avoided?

4. Has anyone experience with using cascaded encryption with the System partition? TrueCrypt discourages it but I wonder if it is possible, perhaps with only a 2-cascade instead of a 3-cascade. I realize that there is a trade-off here between degree of encryptive safety and degree of danger arising from unnecessary program complexity (JT's point).

5. TrueCrypt gives a certain amount of information on the three encryption algorithms so that you can make some sort of choice, perhaps a half-educated one. But the information given concerning the HASH algorithms is very little, so it's very hard to make anything but a wild guess or choose the default. Anyone have any information on the relative advantages and weaknesses of each HASH algorithm?

6. Anyone have any idea how well keepass works together with TrueCrypt--not so much from a computer programming point of view (they run well together) but from the point of view of general security?

7. As far as I can see, the weak link in the chain is the lesser encryption on the System Partition coupled with the necessity to have a smaller password so that you can remember it.

a. Do keyfiles help or are they really false comfort? How well do internal keyfiles work for the system partition? Do the keyfiles have to be on a USB stick?

b. To change the encryption algorithm and/or the HASH algorithm on the system disk do I have to do a permament decrypt followed by a completely new encrypt? Have there ever been problems with this? (I am uneasy with these massive decrypt-encrypt operations.)

c. TrueCrypt says that the password should be more than 20 characters (let's assume a random string generated by keepass from the full allowed pool). For real comfort, how many characters do I need (64 seems a lot to memorize)?

Thanks.

George75

 

Georg, you have a extremely long list of questions here. I'll try to answer to a few.

4.

I use cascade for system encryption. My comp is very far from the best in the world.

AMD Athlon 2 GHz
1,5 GB of RAM

And I am not experiencing any performance issues. However, if you want to use cascade I suggest you to use AES-Twofish. If you combine any of those 2 with Serpent, it is very likely that you will have performance issues. Maybe I am wrong. I don't consider myself expert when it comes to cryptography or computer science in general. But people were writing about this on the web.

3a.

Heh, read the Truecrypt User Guide. It clearly says: "Do NOT DEFRAGMENT! Really, DON'T!".

7c.

Heh, your password combination should be inside your head only. And it shouldn't make sense to anybody in the world (even to you). It should be as long as possible. At least 50 characters (maximum is 64 characters).

I know it's hard to remember. That's why you should come up with your password months before you actually start to use it. And repeat it inside your head for months.

If you use password generated by some proggy it is very likely that you will have to write it down somewhere. Or you will forget it. You have to come up with a combination which consists of some words that are not used in english or your native language. You have to make it extremely hard and at the same time you have to make sure that you won't forget it. If you come up with the combination today, start to use it tomorrow, it is very likely that you will forget it.

7a.

Keyfiles can only be used for partition or file hosted none system volumes. They can not be used for system encryption.

Again, read the user guide. From the top to the bottom. Don't miss anything!

1.

Heh, I'm not sure I understand. If you do system encryption you should stop worrying about page file. You should only set it in registry to clear during the shut down. That is all.

 

Nagib, Nagib!

"Heh, read the Truecrypt User Guide. It clearly says: "Do NOT DEFRAGMENT! Really, DON'T!"."​

Please go to page 94 of the TrueCrypt 6.0a User's guide that gets downloaded with TrueCrypt (> Help):

Q: Can I use tools like chkdsk, Disk Defragmenter, etc. on the contents of a mounted
TrueCrypt volume?
A: Yes, TrueCrypt volumes behave like real physical disk devices, so it is possible to use any
filesystem checking/repairing/defragmenting tools on the contents of a mounted TrueCrypt volume.
​

My question was a technical one. Your answer is going to lead other people astray. The problem of data leaks you are alluding to arises when you are working with file-based encrypted volumes. But here I explicitly assumed system encryption and only partition-based data encryption.

Passwords: well, I guess it all depends on what you can remember of a string of random characters and how much time you have in a secure environment to practise. But what I did want was a serious evaluation of how many days/years to brute force a password for various lengths of randomly generated passwords.

Thanks for the information on using a 2-cascade without Serpent for system encryption on your machine. I will bear it in mind.

It escaped me that you can't use a keyfile for an encrypted system partition. Thanks.

Well, yes the problem, Nagib, is what happens when you clear the page file. In the good old days, IBM wrote Hex 00 to the page file. I don't know what Microsoft does to clear the page file. But what I do want to understand is how TrueCrypt handles the page file clearing. What I fear is that it might encrypt 1 GB say of Hex 00, thus giving the encryption key away. I just wanted someone to explain to me how the thing works on this point.

George75

 

Georg, your password can easily become compromised. If someone manages to sneak into your comp. Or if they plug in a hardware keylogger. Those are the most likely ways to get you screwed. The strength of your password won't help then.

However, if you're careful enough password strength is very important. If your password consists of combination of senseless words and numbers it is nearly impossible that anybody will manage to crack it in a few milleniums. What they can possibly do? They need a wordlists to start bruteforcing. If your password is a complete nonsense of 64 characters they simply can't do it. Even with comp 1 million times faster then mine.

If your words and combination of numbers can not be found in any book on the Earth it is impossible for them to break in. They have to wait untill the encryption algorithms are broken. Or there must be a crutial bug in TrueCrypt. Theoretically, this last possibility is the most likely to occur and get you screwed. But if TrueCrypt isn't faulty it all comes to the strength of your password. If parts of your password can be found in any dictionary in the world you have choosen a very wrong combination. Both length and strength are very important as we don't know how fast the computers will be in 20 or 30 years from now.

 

I'll do my best to contribute to this discussion:

I wouldn't even bother telling Windows to clear the page file if it's on your encrypted system drive. It's just an unnecessary delay when shutting down since the whole thing is encrypted anyway. I would hope that the page file is purged with random data since, as you say, anything less would be introducing "known plaintext", potentially reducing the amount of time required to break the encryption implemented.

It's more of a "peace of mind" function, IMHO. Since the entire partition is overwritten with what's essentially random data, when it's encrypted, any plaintext that was there previously will be reasonably unrecoverable. It depends on your potential adversary, though. Computer forensics companies are rumored to have the capability to retrieve some data from overwritten drives but I've also read reports that it's pretty much impossible.

Yeah, defragging the system drive shouldn't introduce any weaknesses. I think the random character fill is just to avoid having any "known plaintext" areas of the encrypted partition when it's first created. Once it's been filled with random data, you can do what you like with the partition [add data, move it around] without compromising security.

I'll assume you're referring to DoD 5220.22-M since NSA doesn't [AFAIK] actually have its own algorithm [surprisingly]. I think it's more of a wasted effort to do so since free space wipes are only useful on drives that aren't encrypted. Doing so won't introduce any "known plaintext", though, because the algorithm ends with a random overwrite pass.

No experience with this one, sorry!

The three hashing algorithms are only used for pseudorandom number generation [PRNG] and, as a result, your choice won't feasibly affect the security of your partition. All they do is introduce more "randomness" and they're equally as good as each other when implemented in this way.

Arguments regarding hash collisions don't apply due to the where these algorithms are used in TrueCrypt and the fact that no collisions have been found for any the three algorithms [predecessors don't count].

Quite well, provided that your KeePass master password is very secure. That said, if the adversary has access to an unencrypted version of your KeePass database then you probably have a lot to worry about!

Keyfiles definitely help to improve overall security as long as the file used has good "randomness". A file that starts with a large number of zeroes isn't a good idea! Use TrueCrypt's "Generate Keyfile" function if in doubt. The files don't have to be on a USB stick but, if not too inconvenient, it introduces a good layer of "physical security" since it could be anywhere away from your PC. Even if someone manages to obtain your password [eg. via keylogger] then they're still not going to get anywhere without making you cough up the keyfile. I'm not sure if you can use keyfiles when encrypting the system partition.

You can change the hashing algorithm used for a volume [partition or file] without decrypting the whole thing, but not the encryption algorithm, AFAIK. Unsure if you can do this for the system partition. I'd say you'd have to decrypt/re-encrypt. I've never had a problem doing this [multiple times] but, as always, make some backups first!

Don't think of it as a password. Think of it as a passphrase. Using a passphrase such as:

"Only difference between a hockey mom and a pitbull is lipstick"

makes it much easier to have a longer password. To make it more secure, mix in randomized capitalisation, numbers, and special characters:

"oNLy d!ff3rence^beTween*a h0ckey2mom anD A p1tbul) is-lip5tick"

Using dictionary words might seem like a bad idea [since password crackers can extrapolate in an attempt to guess variations you've used] but I can guarantee you that no-one is going to break a large password like that without some massive computing power. Even then it'd still take a VERY long time. If the password lasts longer than the useful life of the data it's protecting, then it's done its job.

Hope this rather large post helps in some way

 

Thanks, Traxx.

I agree that there seems no real reason to clear the pagefile if the system partition is encrypted. It would be nice to hear from some one who's worked on True Crypt how True Crypt handles this issue, however.

Well, for my peace of mind, I will do a NSA wipe on the free space before encryption. I don't have such anxiety as to do a Gutman wipe.

Yes, I think it's clear that defragmentation on a data partition or a system partition is not going to introduce a problem. That of course doesn't speak to issues of hidden partitions and file-based containers. Other story which doesn't interest us here.

From what you say, an DOD 7 overwrite pass (= NSA) might even introduce a weakness into the encryption. Since nothing is truly random at this level, the pseudorandom string introduced in the final write might be regular enough to assist the adversary. Incidentally the DOD has a 3 pass overwrite and a 7 pass overwrite (at least somewhere I saw it expressed thus). The latter is AFAIK usually known as the NSA standard. For example, see CCleaner options. What the guys actually do with their own computers, I don't have an idea. The Gutman standard is 35 overwrites, but I have no idea what the algorithm is that Professor Gutman designed.

Thanks for the elucidation of the three HASH algorithms and their roles and their functional equivalence.

Serious question: isn't the Keepass database stored in encrypted form? But let's assume that it's on the encrypted system partition. I agree that having it on an unencrypted partition wouldn't be smart, and certainly not in clear text.

As for the keyfile. One of the problems is that if I use say a photograph, I'm never sure that I won't take it into my head to improve the lighting on the photograph or whatever, or delete the photograph or move it around. Bye-bye encrypted partition.

And I am uneasy about labelling a folder or file 'True Crypt Keyfile'.

Incidentally, perhaps you could advise: is it feasible in an Internet Cafe say where I don't have admin privileges to use TrueCrypt from the USB in traveller mode--to open an encrypted container on the USB stick? Is this easy or troublesome?

"If the password lasts longer than the useful life of the data it's protecting, then it's done its job."​

The remark of a professional.

Actually, I have the ability to memorize--with certain mnemonic tricks--strings of random characters. What I don't know is how long a string I can memorize--and how long a random string is necessary to fulfil the criterion you provide. Any idea? Moreover, I am somewhat confused as to what characters are acceptable in these situations--I can't make head nor tail of all the different coding structures (ANSI, Western, Unicode ...) floating around and where they're used and where they conflict. If I am generating a password using KeePass, can I click 'use high ANSI characters' (assuming I can remember them and type them) so as to use the password on TrueCrypt? In the case where I am copying and pasting to open a separate encrypted partition from the open system partition, are all ANSI characters acceptable? I think the answers are yes, but I would prefer to hear your comments.

Thanks very much, Traxx, as one 75 to another. A very professional answer indeed.

George

 

Traxx75 thought that there really was no such thing as a formal NSA standard for wiping files. I thought about it and did a little checking and here is what I found. Lavasoft has a shredder which will shred according to your choice of umpteen different wiping standards. It also does free space. This isn't a plug, just some information from a reputable firm.

I got this information by going to the link

http://www.lavasoft.com/products/lavasoft_file_shredder.php?t=features
​

and then downloading their fact sheet in PDF format.

The standards listed are from the fact sheet. I believe 'HMG' means 'Her Majesty's Government'--i.e. a British standard.

About Lavasoft’s Shredding Technology
Lavasoft File Shredder’s shredding technology is based on well known
standards and approved algorithms for complete data removal. File
Shredder supports the following overwriting algorithms:

HMG Infosec Standard 5, The Baseline Standard Blowfish, 448 bits
HMG Infosec Standard 5, The Enhanced Standard
Peter Gutmann’s algorithm
Bruce Schneier’s algorithm
Navy Staff Office Publication (NAVSO P-5239-26) for RLL
The National Computer Security Center(NCSC-TG-025)
Air Force System Security Instruction 5020 (AFSSI-5020)
US Army AR380-19
German Standard VSITR
OPNAVINST 5239.1A
National Security Agency (NSA/CSS Manual 130-1) – for magnetic storage
only.
U.S.Department of Defense Sanitizing (DoD 5220.22-M ECE)​

Somewhere these standards are written down, obviously under the titles given.

Best wishes,

George75

 

It would be nice, but I don't think we're going to be that lucky I would guess that TrueCrypt has no special way of dealing with the page file, though.

FWIW, the Gutmann 35-pass overwrite is wasted on modern drives. Gutmann himself mentions this in an addendum to his own white paper [see: Epilogue].

I was intrigued by your posts that indicate there's an NSA overwrite standard out there somewhere but I haven't been able to find any conclusive proof of it. The closest thing I've found is the Joint DoDIIS/Cryptologic SCI Information Systems Security Standards document that references NSA/CSS Manual 130-2 [Media Declassification and Destruction Manual, November 2000]:

20.4.2.1. (U) Overwriting Procedure. The preferred method to clear magnetic disks is to overwrite all locations with a pseudo-random pattern twice and then overwrite all locations with a known pattern.​

I haven't been able to find any data-erasure products that implement the supposed NSA standard and actually disclose what the pattern is. They simply reference NSA/CSS Manual 130-1 [Operational Computer Security, October 1990], which I think in turn references 130-2, neither of which I can find anywhere. It's also interesting to note that NSA/CSS Manual 130-2 has actually been superseded by the NSA/CSS STORAGE DEVICE DECLASSIFICATION MANUAL 9-12 [December 2007]. This manual, and the ODAA Process Guide [Section 2.4.2, September 2008], seem to indicate that overwriting is no longer recommended for sanitizing media that's held classified data. Degaussing/destruction appears to be the only remaining method recommended. If someone could find a copy of the manuals then you'd know for sure if there was an actual NSA algorithm defined in the past.

Incidentally, the NISP Operating Manual [aka. NISPOM; DoD 5220.22-M], that the 7-pass and 3-pass standards are derived from, doesn't actually specify overwriting techniques. This was actually developed by the Defense Security Service and is specified in the Clearing & Sanitization Matrix [found in the ODAA Process Guide - Appendix O]. What's specified is a 3-pass overwrite as follows, but combined with degaussing and destruction:

d. Overwrite all addressable locations with a character, its complement, then a random character utilizing an approved overwrite utility.​

There's no mention of a 7-pass algorithm, though, so I'm not sure where that was derived from.

The Gutmann algorithm is 27 passes of predefined patterns with four passes of pseudorandom data at the start and end. See Section 3 of Gutmann's whitepaper for the exact patterns.

In my opinion, though, a few overwrites with pseudorandom data will ensure the data is not recoverable by most [if not all] adversaries if you wanted to re-use/sell hard drives. If the data previously stored on there is so sensitive that you cannot risk anyone disclosing it, then destroy the drive completely.

Yep, it is. Having it on an encrypted system helps to ensure that no-one could compromise your KeePass DB if your drive/laptop/etc was stolen.

That's one of the risks of using "regular" files as keyfiles. If you inadvertently modify the file then you're in big trouble. It's a trade-off between obscuring the nature of your keyfile and the risk of accidently destroying it. The best thing you can do is pick a file that you're unlikely to modify. That's why a TrueCrypt-generated keyfile is best. It's just a file of incompressible data that you're never going to modify.

You'd just rename the TrueCrypt-generated keyfile to something inconpicuous

You won't be able to do so unless TrueCrypt is already installed on the machine, unfortunately. An alternative is to boot using a LiveCD [like BartPE] so that you can run TrueCrypt as an administrator in that live environment. You probably wouldn't have much network connectivity, though, since many Internet Cafés use proprietary software [that you won't have access to from a LiveCD] to control that.

The suggested 20 characters would be more than enough to protect your data. Anything more isn't really going to improve security in any way [other than mathematically].

Only regular ASCII characters are accepted for TrueCrypt passwords. This is pretty much any character that can be found on a standard 102-key US keyboard [upper/lowercase letters, numbers, and special characters such as !@# etc].

While they do list an NSA standard, it's not the US DoD 5220.22-M 7-pass that you mentioned earlier. The 7-pass is actually the U.S.Department of Defense Sanitizing (DoD 5220.22-M ECE) standard they have listed. This is the 3-pass standard [E], mentioned above, performed twice with a random-character [not a pseudorandom pattern] pass [C] in between. Hence the [ECE] suffix

I'm still interested to find out what the NSA standard really is, though!

edit: I found this document which references the NSA 130-2 standard as being:

Erase the media and overwrite with random data 2 times, then erase and overwrite with a character​

This seems to confirm the old standard was two pseudorandom passes and then a single-character pass. I'm not sure what "erase" implies, though. Also, the document is entitled "Security Features for Solid State Drives in Defense Applications" so the standard may not apply to regular HDDs.

 

Well, Taxx75, that's quite a formidable answer, suitable for a graduate seminar. I'm impressed. It's taken me a while to digest your post--if I have digested it--but I have the following comments.

Once the partition is encrypted and free space is overlaid with TrueCrypt 'random characters' generated according to TrueCrypt's algorithm, presumably there is no real way short of breaking the encryption key to separate free space random character fill from encrypted data--the two types of character string are close enough that there is no real way to discriminate between the two. However, if one were to introduce free-space wipes using a lesser quality of random character string AFTER he had set up the TrueCrypt partition, he would presumably be degrading the encryption-quality of the fill, and perhaps enabling the adversary to separate out free space. Whether this is important is beyond my technical knowledge to assess.

Next, from what I understand from their manual, one of TrueCrypt's problems is that there is no API available in Microsoft Windows that would enable them to modify the page-file wipe so as to introduce a higher quality of random character fill from whatever Microsoft does (I don't know, but I doubt that Microsoft generates high-quality random character strings for their page file wipe). Hence, there would be an issue here what might be revealed if the adversary were to study the page file area in an encrypted system partition. It is true that TrueCrypt encourages its users not to use the page-file (in another context, I believe), but sometimes this is not possible for technical reasons (low RAM). However, it is true that when you do have 'clear page file' checked once your system is encrypted the clear takes far longer than in an unencrypted system--so something must be happening. It seems that this would be an area where TrueCrypt might want to explain their solution.

I am intrigued by the two 'HMG' standards. The presence of a reference to 'Blowfish, 448 bits' suggests that the Brits are using a very sophisticated random character generator to overwrite data. This might be interesting for the above issue.

In the meantime, it would make sense NOT to clear the page file for fear that TrueCrypt is encrypting without alteration to their standard algorithm, Microsoft clear text (say, Hex 00) for the page file fill. Of course this is my personal judgement, not infallible.

Next, with regard to the NSA standard, it seems that NSA 7 pass is actually the DOD ECE 7 pass, just as you say. I suppose that in investigating this, you might ask the authors of CCleaner what they think the NSA 7 pass wipe that they have in their product is doing and what they based themselves on. Presumably the Lavasoft people wil have studied the matter very carefully and might have a clear answer, if they choose to answer. From what you write, the actual NSA standard was a simpler thing, superseded by HDD destruction.

Finally, the long and short of it seems to be that if you have something really sensitive on your disk, burn the disk. The curious thing about degaussing is that it renders the disk unusable. Then they want you to damage the disk further. But in that case--just throw it in the fire. How much does a 120 GB HDD cost today?

For running data on a working system, well, I suppose the question is whether TrueCrypt is professional or amateur in quality--i.e. what protection you're really getting with TrueCrypt from which adversaries. That I have no way of assessing. It would require information from someone in the trade.

Well, at the moment, that is all I can add. Thanks for the post, with a little effort we will have a standard reference work on the subject here.

George75

 

Just a small but i guess very important observation:

TC does not fill free space on system drives with random data, cause it does not know what sectors are used and witch not, TC works below the FS level in case of normal volumes it creates a volume with 100% random data and then calls windows API's to format it.
For the System volume thats obviously impossible.

Of cause you can use a third party tool (that operates on the FS Level) to fill the free space of your boot drive with random data.

So I guess the Page file full of 0's is your least problem, for example if you encrypt a new HDD with a fresh installed OS you will have almost all the space field with 0's as its comes from the manufacture.

David X.

 

David,

Doesn't TC encrypt the entire drive however? So from the outside the entire drive appears to be encrypted, and there aren't any "holes" of data that arn't overwritten. Its just a direct encryption of every bit/byte already there, be they active data or left over remnants?

 

This seems to be an important issue about how TrueCrypt encrypts the System partition. If it's not filling the free space with anything but just leaving it as is, there is a problem with remnants--not eveyone is using a HDD fresh out of the box for system encryption. In such a case it would be necessary to do a free space wipe before doing the system partition encryption. However, such a free-space wipe should ordinarily terminate in a string of high-quality random characters--not a fixed pattern. For then of course it would separate out completely from the encrypted operating system.

In the case of the page file, the TrueCrypt guide states explicitly that it is permanently encrypting the page file. However, if you set the page file to be cleared and the system writes all 0's or some other character or fixed pattern to the page file, TrueCrypt is encrypting all 0's or even Hex 40 (or whatever) and it is giving the encryption key away to the adversary.

It is not the same thing as David suggests.

This is what the TrueCrypt guide for TrueCrypt 6.0a states:

TrueCrypt can on-the-fly encrypt a system partition or entire system drive, i.e. a partition or drive
where Windows is installed and from which it boots.

System encryption provides the highest level of security and privacy, because all files, including
any temporary files that Windows and applications create on the system partition (typically, without
your knowledge or consent), hibernation files, swap files, etc., are always permanently encrypted
(even when power supply is suddenly interrupted). Windows also records large amounts of
potentially sensitive data, such as the names and locations of files you open, applications you run,
etc. All such log files and registry entries are always permanently encrypted as well.​

I included the first paragraph because it indicates that TrueCrypt is saying that it is encrypting the system partition not just the files. If TrueCrypt is encrypting only the files on a system disk, they should spell it out.

Next, it is clear that TrueCrypt is saying that it is encrypting even the page file. So the question would be--if you clear the page file, what happens?

Thanks.

George75

 

It doesn't matter if you encrypt a couple hundred MB of 0's as AES (and the other included ciphers, is not going to compromise the encryption. Its not as if you are going to have a couple hundred characters of the same thing or a repeating pattern. AES I know is designed to look like pure random data no matter what is encrypted.

 

Maybe I'm being naive, Kooky, but I find what you're saying hard to believe. If it were so, it seems to me, a piece of encrypted plain text would be of no value to the adversary--since a little further down the road the same plain text would be encrypted differently. I thought the whole thing hinged on the size of the encryption block--that the appearance of randomness is limited to strings no longer than the encryption block. Even if there might be further 'mixing-up' algorithms downstream in the encryption procedure written into the encryption program, surely--and I admit that I am by no means a cryptographer--they have to be deterministic (i.e. functionally reversible) and known since open source. I would have to see some persuasive mathematical argumentation (perhaps not at the level of string of symbols and such but at the level of a plausibilty proof) to be able to accept that it doesn't make any difference if an adversary knows that what he has in front of him is 1 GB of encrypted plain text (i.e. text that he knows)--in the case at hand, by hypothesis, all Hex 0's. Moreover, I find it hard to believe that it would be that difficult for the adversary to search the system partition looking for such encrypted plain text even if the adversary didn't know in advance precisely where the page file was located (he would have a rough idea from knowledge of how the Windows O/S allocates the page file).

Best wishes--

George75

 

I know that someone did a test of a file to see the distribution, and it came out looking like pure random data as is possible.

Best way I could tell you to prove it would be to create a 10MB container, then create a file that occupies most of that (9MB+) and make it all 0's, 1's, etc.

Do you have any patterns in the data?

 

Kooky, the adversary is not going to look at the page file space with the naked eye. He's going to use mathematical techniques possibly with a large supercomputer. Hence, it is necessary to be satisfied just how TrueCrypt is handling this case.

George75