@Paranoid Eye
This is actually a question that could go in the Privacy Technology section.

The answer is, it depends. A TrueCrypt encrypted partition is supposed to be indistinguishable from random data (as, that's what the encryption looks like, randomness.)

So yes, the idea is that an adversary should not be able to identify the drive is encrypted or simply wiped. However, there are a number of things that could give it away. This is why a great deal of the TC manual is dedicated to detailing such things.

Check out the sections on Plausible Deniability and Security Requirements.

I wasn't clear of whether or not you are talking about a non-system disk being fully encrypted or an actual OS (system disk)? System disks require a bootloader and a distinguishable partition table to hold it. While the encryption cannot be broken its existence on a platter with a system disk cannot easily be denied either.

For non-system disks no such restriction applies. While you cannot prove the "blob" of encryption is a truecrypt volume, logic would still beg the question as to what 100 Gig of thoroughly wiped space is doing there. Fortunately the answer is hidden volumes for sensitive stuff and then for sure its existence cannot be proven (unless there is operator error involved).

Speaking in "lay terms" but as a really long term user/instructor on this subject: even with the bootloader fully removed (forensically removed in fact), deniability is still impeded by the existence of the partition table holding the OS. Assuming you are will to consume about 2 minutes of time every instance you wanted to mount the encrypted OS you can in fact easily accomplish what you want. You would have bootable media to restore the partition table and then boot from a "rescue disk" and once up you are flying along. When finished you wipe/restore a bogus pile of 111111's and 000000's to the partition table location leaving no evidence of any organized wipe or structured partition!

You STILL have the "loose end" of that removable media physically existing to be found. Can you predictably hide that where you know an adversary won't ever find it? If not, this is a futile exercise!

I have quite a bit of time using LE forensic examination tools of windows systems. Let me just cut to the chase. Absolutely forget trying to cover any OS tracks with anything but FDE. You will come up short in more places than I can mention in one post.

So let me see if I am understanding this correctly. A TC volume can be determined to be a TC volume because of it's properties. But an encrypted external hard drive or an encrypted USB stick cannot be determined to be encrypted with TC, correct? And if a person has encrypted their C drive and also have a hidden OS there, it cannot be determined that there is a hidden volume, correct?

That sounds about right, if by "TC volume" you mean "file container". There's actually three different kind of TC volumes...

-File container, (which is a virtual encrypted disk within a file).
This is where you end up with a file, which can have any extension you want to put on it (.jpg, .doc, .txt, et cetera). Or it could have no extension at all. You mount the file and a virtual drive shows up and you can copy files to it, which are encrypted on the fly.

TC documentation:

"Although file-hosted TrueCrypt volumes (containers) do not contain any kind of "signature"
either (until decrypted, they appear to consist solely of random data), they cannot provide
this kind of plausible deniability, because there is practically no plausible explanation for the
existence of a file containing solely random data. However, plausible deniability can still be
achieved with a file-hosted TrueCrypt volume (container) by creating a hidden volume
within it (see above)."​

(emphasis added)

So if someone is analyzing files on your computer and finds one that consists of random data, it can be pretty well determined it's an encrypted container.

-A non-system partition/drive
This is where you encrypt a logical disk (i.e. partition), or an entire physical disk (or any external drive including flash drives).

TC documentation:

"Until decrypted, a TrueCrypt partition/device appears to consist of nothing more than
random data (it does not contain any kind of "signature"). Therefore, it should be impossible
to prove that a partition or a device is a TrueCrypt volume or that it has been encrypted
(provided that the security requirements and precautions listed in the chapter Security
Requirements and Precautions are followed). A possible plausible explanation for the
existence of a partition/device containing solely random data is that you have wiped
(securely erased) the content of the partition/device using one of the tools that erase data
by overwriting it with random data"​

(emphasis added)

So for a non-system partition or device, as long as you follow the steps to prevent data leaks, there should be no way someone could prove the random data is encryption as opposed to the result of a clean wipe. (And even in the event of a leak, it would require they have access to your system. In other words, the adversary simply having your encrypted flash drive should not be enough to prove whether it's encrypted or just wiped.)

There are two caveats to this, though...

Some storage devices (e.g., some solid-state drives, including USB flash drives) and some file systems utilize so-called wear-leveling mechanisms. You can read more details in the relevant section in the documentation, but the bottom line is, it can negatively effect plausible deniability and if you need that, you must not use TrueCrypt to encrypt any part of (or create encrypted containers on) a device (or file system) that utilizes a wear-leveling mechanism.

The other caveat, as mentioned in my old thread, is if you've got a drive with a single partition that takes up all the space on the drive, and you use TC to encrypt that partition, you kind of lose the deniability because having an intact partition table followed by a gigantic partition filled with random data screams 'this is encrypted' and not securely erased.

So if you're going to encrypt the whole drive, you might as well just remove the partition and use the "encrypt the entire device" option.

-A system partition or entire system drive
This is when you encrypt the partition/drive where Windows is installed.

TC documentation:

"in order to boot a system encrypted by TrueCrypt, an unencrypted copy of the TrueCrypt
Boot Loader has to be stored on the system drive or on a TrueCrypt Rescue Disk. Hence, the mere
presence of the TrueCrypt Boot Loader can indicate that there is a system encrypted by TrueCrypt on the computer."​

(emphasis added)

So yes, when you encrypt the entire device (or partition) where Windows is installed, the existence of the TrueCrypt Boot Loader will prove the volume is encrypted.

The suggested method for dealing with this is a hidden operating system. This won't allow you to deny the device is encrypted, but instead gives a way to decrypt the device, allowing the adversary to believe they have gained access to your encrypted system...but you have instead provided them with access to a decoy operating system.

This is where the plausible deniability comes from: provided you follow all of the required guidelines, it should be impossible to prove the decoy is really a decoy and that there is in fact another OS hidden within the device.

If you want to be able to deny encryption entirely, even if you remove the boot loader, you'd still have the partition table giving you away (as mentioned above with the non-system volume), so you'd have to wipe that whole first track. This is what Palancar was talking about.

To have a system drive where you can deny its encryption, you'd have to be in the practice of restoring the partition table and using a TC Rescue Disk and booting directly from that each time you wanted to gain access to your system.

Is this accurate, @Palancar? The partition table is located in that unencrypted first track along with the boot loader?

Either way, his point about the Rescue Disk is valid. The existence of a TrueCrypt Rescue Disk is a pretty strong indication that you've encrypted something. So it does kind of create a "loose end" that you'd have to consider. You'd have to have a rescue disk in close enough proximity that you can use it any time you need to boot up, but it would have to be hidden enough that anyone who gets to your system wouldn't find it.

(I'd also like to invite @dantz to offer any corrections or additions to this.)

If I am correct, a file consisting of high entropy data is indistinguishable from a Truecrypt file container.

Click to expand...

Yeah, but that's not the issue. Read the quote from the TC documentation directly above the part of my post that you quoted:

"Although file-hosted TrueCrypt volumes (containers) do not contain any kind of "signature"
either (until decrypted, they appear to consist solely of random data), they cannot provide
this kind of plausible deniability, because there is practically no plausible explanation for the
existence of a file containing solely random data."

it's a possibility if Truecrypt is installed on the computer, but proving that the file was generated by Truecrypt and not an other program is as far I know impossible.

What if you have written a custom database application employing a large file of random data where only offset 0x1000 is used to store innocent information?

If you have a 1 GB file, and you have written a database program to only store records from space offset 500000 within the file, and you can show the police that the program displays your lewd diary, it's impossible to disprove that it contains a Truecrypt volume.

Click to expand...

If you say so. I'm just going along with the TrueCrypt documentation when it says: "there is practically no plausible explanation for the existence of a file containing solely random data."

If you say so. I'm just going along with the TrueCrypt documentation when it says: "there is practically no plausible explanation for the existence of a file containing solely random data."
Maybe you've come up with one, but it seems harder to believe.

Click to expand...

Sorry, but the Truecrypt documentation is not an exclusive authority for plausible reasons for possessing random data.
There are several reasons for possessing random data, and fortunately the legal system in most civilized nations do not require a suspect to produce plausible reasons for possessing random data.
That's either because the legal system allows a criminal suspect to remain silent or even assuming that the law compels someone to disclose the key the burden is always on the prosecution to prove willful obstruction.
Under UK's RIPA S.49 the failure to disclose the key or plaintext must be knowing, meaning that the government must prove the person was in possession of the key and knowingly failed to disclose it.
If the only evidence is possession of random data, there is only a good case if the person is stupid and taunts the police.

it's so far what happened in all publicized cases.

- The defendant lied claiming that the media was corrupt, but the government was later able to decrypt it.

- The defendant was entering a password while police was knocking down the door.

- The defendant gave the police a lot of incorrect passwords.

- The defendant outright refused to cooperate.

I have not been able to locate any case wherein the factual pattern consisted of (1) Possession of random headerless data; (2) The police claiming that it was a Truecrypt volume; (3) The defendant denying it but still being convicted.
What makes possession of a usb key consisting of high entropy data more plausible than possession of a file consisting of the exact same entropy?

Yeah, but that's not the issue. Read the quote from the TC documentation directly above the part of my post that you quoted:

"Although file-hosted TrueCrypt volumes (containers) do not contain any kind of "signature"
either (until decrypted, they appear to consist solely of random data), they cannot provide
this kind of plausible deniability, because there is practically no plausible explanation for the
existence of a file containing solely random data."

I'm not sure what you mean. What program would TrueCrypt generate?

Click to expand...

Sorry, what I meant was that you could write a database application using the same headerless random datafile for storing innocent stuff in encrypted form from a user specified offset..

If the database contains actual records, and the application works when shown to the police, search, display and add/edit entries, I can't see how they can prove that it's a cover for a Truecrypt volume.

There are several reasons for possessing random data [...]
What makes possession of a usb key consisting of high entropy data more plausible than possession of a file consisting of the exact same entropy?

Click to expand...

Well, again, the fact that there's virtually no reason for the existence of a file containing solely random data. You claim that there are several reason such a file would exist, but you haven't really offered any.

The only suggestion you gave was "well what if you wrote a program that generated a big file of randomness and you used a small portion of it to store actual data?" Okay. And what if there was a unicorn about to impale that guy I threw the beer bottle at, causing the potential victim to stumble out of the way just in time? Anything is possible.

I'm just going off of plausibility.

But even more to the point, "a big file of randomness with a small portion of actual data" is not the same thing as "a file containing solely random data," is it?

Maybe I'm not understanding what you're suggesting. In your first post (which you deleted?) you said "you have written a database program to only store records from space offset 500000 within the file, and you can show the police that the program displays your lewd diary," and now in this second post you say "you could write a database application using the same headerless random datafile for storing innocent stuff in encrypted form from a user specified offset.."

The second comment sounds like you're literally suggesting that you have deniability because you could potentially write your own encryption application that creates container files that look like random data, just like TrueCrypt. And therefore they can't prove it's a TC volume.

I don't see how that affects my point about them being able to assume with good plausibility that it's encryption...as, you just admitted your setup would basically be the same thing, just not a TrueCrypt™ container. (I would have thought it went without saying that it's not TrueCrypt™ containers that are the issue, but encrypted containers in general. Simply being able to show that you wrote a program that encrypts data and makes it look like randomness does not seem to be a viable strategy for denying you have encrypted containers.)

Either way, everything you have described consists of a file containing mostly random data, and relies on the assumption of you proving to the adversary that your randomness file contains "innocent" (or lewd?) data. That is not the same thing as "a file containing solely random data," which is of course what I said from the get-go.

I didn't say it was. But I would say the devs have a pretty good track record establishing them as authoritative in this field, and they seem to know what they're talking about.
Well, again, the fact that there's virtually no reason for the existence of a file containing solely random data. You claim that there are several reason such a file would exist, but you haven't really offered any.
The only suggestion you gave was "well what if you wrote a program that generated a big file of randomness and you used a small portion of it to store actual data?" Okay. And what if there was a unicorn about to impale that guy I threw the beer bottle at, causing the potential victim to stumble out of the way just in time?

Click to expand...

It's a daft analogy, because if I can prove (1) That my program exists; (2) That it performs the action that I claim it does -- namely using an area within a larger file to store database records, (3) it's ipso facto a legitimate non-Truecrypt reason for possessing a large random file.

The fact that an adversary may speculate that a large file being compatible with one program when opened with that program displays an innocent database might also contain hidden data compatible with another program does not negate the *plausible* and *legitimate* use of a random file.

Your example -- the unproven unicorn or an unproven or supernatural force being an intervening and allegedly exculpatory cause is so laughable that it's almost not worthy of a response but, it even fails on its own terms.

If someone claims that he is not guilty of assault because an intervening *unproven* natural force caused the bottle to hit the victim, there are often witnesses, video cameras and other physical evidence negating the defense, which is enough to have the defendant declared guilty beyond a reasonable doubt apart from the fact that courts take a dim view of supernatural or fringe
scientific theories.

It's you who by reference to the Truecrypt documentation make the claim that there is no plausible reason other than Truecrypt for possessing a large random file.

And I'll argue that it's a problematic claim because any program can use the same type of random data.

The point is not to deny the *possible* existence of encrypted data, but to negate the claim that the only plausible reason for possessing the data is that the file is a Truecrypt volume.

The adversary may still believe that if Truecrypt is installed on the computer, and the person is in possession of a large file consisting of random data, that the only or most plausible inference is that the file is a Truecrypt container, but without more evidence I doubt how it could hold up in court.

Of course, if we are speculating about an adversary unbounded by legal constraints, I'll grant that even a legitimate database program will not matter, but plausible for me means plausible enough to raise a reasonable doubt argument in a court where presumably due process is observed.

Plausible does not constitute proof sufficient to save me from an adversary acting on mere guilt by association.

If the adversary is ignorant of the infinite possibilities of software design and the unreliability of a lot of forensic snake oil such as the claim by a software company that its product can detect Truecrypt file containers, nothing will save me even if I am innocent.

Having Truecrypt installed will then be enough to go to jail, but that's fortunately not how the law works even in the UK.
Only if the suspect admits that there is a password, or the police from other evidence can prove that a file is encrypted and the suspect knowingly fails to disclose it, will he be found guilty.

None of the RIPA convictions under S.49 have concerned people being convicted after denying that a file was encrypted without the police offering more evidence.

This is significant, because it shows how far a civilized nation observing notions like presumption of innocence, proof beyond a reasonable doubt can compel suspects to produce evidence against themselves.

But even more to the point, "a big file of randomness with a small portion of actual data" is not the same thing as "a file containing solely random data," is it?
Maybe I'm not understanding what you're suggesting. In your first post (which you deleted?) you said "you have written a database program to only store records from space offset 500000 within the file, and you can show the police that the program displays your lewd diary," and now in this second post you say "you could write a database application using the same headerless random datafile for storing innocent stuff in encrypted form from a user specified offset.."

Click to expand...

The data would appear random to a forensic investigator using a Truecrypt detection algorithm, but a user opening my program would get an innocent intelligible plaintext after providing a password to decrypt the file.

My inspiration for this scenario is RIPA, under which the person must either disclose the key or intelligible plaintext.

And no, of course I do not argue that I would have plausible deniability just by barely asserting that I could have written my own program.

Rather I'll argue that if I had already a functioning program using a large random file detected as a Truecrypt file container, the investigator would be unable to prove the existence of something else.

It's a daft analogy, because if I can prove (1) That my program exists; (2) That it performs the action that I claim it does -- namely using an area within a larger file to store database records, (3) it's ipso facto a legitimate non-Truecrypt reason for possessing a large random file.

Click to expand...

lol I don't understand why you're so hung up on it being a TrueCrypt volume. As I said, the point is that it's encrypted...not that it was created by any specific program.

The issue is not with being able to deny the file was created by TrueCrypt...it's with being able to deny it's an encrypted container...

And once again, simply being able to show that you wrote a program that encrypts data and makes it look like randomness does not seem to be a viable strategy for denying you have encrypted containers.

It's you who by reference to the Truecrypt documentation make the claim that there is no plausible reason other than Truecrypt for possessing a large random file.

Click to expand...

Again not "TrueCrypt" specifically, but encrypted container, yes. And you still have not provided any example of otherwise.

It's also pretty revealing that you've chosen to completely ignore my other point about how I spoke of "a file containing solely random data," and all of your supposed counter examples have been "a big file of randomness with a small portion of actual data."

Rather I'll argue that if I had already a functioning program using a large random file detected as a Truecrypt file container, the investigator would be unable to prove the existence of something else.

Click to expand...

I'm still not seeing your point. How does having plausible deniability against using a specific brand of encryption software (by simply pointing out an encrypted file could have been created with some other piece of software) provide deniability against the notion that the file is an encrypted container?

Just because someone can't prove it's a "TrueCrypt™ container" doesn't mean they can't assume with a high degree of certainty that it's an encrypted container.

lol I don't understand why you're so hung up on it being a TrueCrypt volume. As I said, the point is that it's encrypted...not that it was created by any specific program.

Click to expand...

Let me quote the original poster:

Perhaps a strange question If I use truecrypt and do full disk encryption on a single hard drive is there any way a forensics could suggest that drive is
encrypted or has been accessed recently ?

Or is the drive letter appearing and saying not accessible a dead give away!?

Click to expand...

The Truecrypt documentation which you cite seeks to distinguish between file based containers and full disk encryption by arguing that there is no other practical reason for possessing random data files.
And that's here I must disagree.

yes, I don't deny that a forensic investigation would suggest that the high entropy file might contain encrypted data.
But suggesting is far from proving it in court.

No, a random file is just a random file. It can't be proven that it's a Truecrypt disk container, or if has ever been mounted by Truecrypt on the same computer.

And that's how I understood the poster's concern:
Is it possible to plausible deny the existence of a Truecrypt filesystem?

The issue is not with being able to deny the file was created by TrueCrypt...it's with being able to deny it's an encrypted container...

Click to expand...

It might be an issue if you are compelled to disclose a plaintext or a key under RIPA S.49.
If you are in possession of a file containing random data and the government knows it's likely encrypted data, but is unable to prove which software having generated it, you can have prepared for the eventuality by only decrypting some of the file with your own custom solution.

It's like a Truecrypt hidden volume hidden within another larger volume.

Both solutions rely on the possibility to use a large amount of data to hide a smaller amount of data.

The Truecrypt documentation which you cite seeks to distinguish between file based containers and full disk encryption by arguing that there is no other practical reason for possessing random data files.
And that's here I must disagree.

Click to expand...

This is not really accurate. Once again, all the TC documenation says is "there is practically no plausible explanation for the existence of a file containing solely random data." And as I said before, you haven't provided any evidence to the contrary. The most you've done is presented hypothetical cases of "a big file of randomness with a small portion of actual data."

On top of that, I'm not sure what makes you think any of that has anything to do with how the TC documentation distinguishes between encrypted containers versus FDE. Obviously the difference is a container is a virtual encrypted disk within a file (something else I said in the original post), whereas FDE is literally encrypting the full disk (go figure.)

yes, I don't deny that a forensic investigation would suggest that the high entropy file might contain encrypted data.
But suggesting is far from proving it in court.

Click to expand...

It's not about proving anything in court. All he asked was "is there any way a forensics could suggest that drive is encrypted." And since "there is practically no plausible explanation for the existence of a file containing solely random data," such a file existing on a disk is a pretty strong suggestion.

And that's how I understood the poster's concern:
Is it possible to plausible deny the existence of a Truecrypt filesystem?

Click to expand...

Maybe that's what you decided to read into his question, but I was just answering the questions he actually asked. I'm not sure how you jumped from everything in his posts to denying a "TrueCrypt filesystem" (meaning, I don't care about being able to deny it's encrypted, so long as they can't prove it's TrueCrypt encrypted.) That makes no sense, but it would explain why you've been so obsessed with asserting no one can prove the file was encrypted by TrueCrypt specifically.

I am again a bit late to the "party". In short I would answer NO to the post quoted here. This is exactly why and how TC was developed. In addition to a completely hidden OS, the decoy system accounts for the existence of the bootloader and critically important --- the reason for the partition table existing on the platter! A well planned outer volume does just what it needs to do and there will be no proof to the contrary. Of course the very use of TC will cause suspicion to abound, but nothing beyond suspicion will ever show up without significant operator error.

I guess I'm a little late to the party too, but this actually sounds similar to another thread I just added to a few days ago where there was talk of FDE.

This whole thing about the file containers is more than likely going to be a moot point in a real world situation anyway. I'll quote from my post in that other thread:

...having your volumes dismounted will not help you, because there will likely be data references from the encrypted containers (e.g. filenames, file paths, etc...if not files themselves) stored in RAM or on the system partition. The adversaries would then have proof the files exist and move to force you to decrypt the containers.

(This would likely happen even in US courts because if they have encrypted containers (which are easily identifiable) and filenames and file paths that don't exist on the unencrypted portions of the drive, it's a pretty safe bet they're in the containers and therefore the existence of the files is what the courts call a "foregone conclusion", and they will most likely force you to decrypt the drive.)

...having your volumes dismounted will not help you, because there will likely be data references from the encrypted containers (e.g. filenames, file paths, etc...if not files themselves) stored in RAM or on the system partition. The adversaries would then have proof the files exist and move to force you to decrypt the containers.

Click to expand...

Under the foregone conclusion test, location and custody is also a requirement which must be proven apart from existence.

Mere speculation that you might have something is not enough to prove existence of encrypted data.

And the government can not satisfy that requirement by pointing to possible prior custody or the mere existence of random data which can't be proven to be encrypted with Truecrypt.

In the 11th circuit case there was no question that Truecrypt was installed on the computer, and that there was a large partition.
But the forensic expert admitted that it was not even possible to prove that the data had been encrypted with Truecrypt.

Granted, there were other issues being fatal to the government's case in particular that it could not prove that there was CP on the computer.

But I think that the most significant issue was that the court was not willing to speculate that possession of a large blob of random data = partition encrypted with Truecrypt even where as in that case the installation of the software was a known fact.

Now if there had been Windows registry entries pointing to mounted devices, it might be a closer case, especially if the serial numbers matched physical devices in the suspect's possession, but I really don't see why the 11th circuit's reasoning would not be equally applicable to a suspect possessing a computer with Truecrypt and a large random file.

Remember that the the foregone conclusion is necessary in order to overcome the individual's Fifth Amendment right.

The individual is not required to profer any plausible reasons in order to rebut the government's theory.

@ justpeace :
Do you know,for a fact, that the OP is even from the US or are you just assuming it ?
A lot of us are not from the US, so what does 'The Fifth' do for us ?

@ The OP :
In my opinion, plausible deniability' is a flawed concept unless you keep your mouth shut .
DO NOT offer ANY 'explanation' as to why you have absurd amounts of random garbage,in fact :
DO NOT SAY A DAMN WORD, period .
You have no way of knowing what they know and could easily be caught in a lie the instant you start volunteering any explanation, especially because you ARE lying, you didn't really d-ban all your pr0n or whatever it is you don't want your GF to find and you don't have some mystery homebrew database, do you ?

@ justpeace :
Do you know,for a fact, that the OP is even from the US or are you just assuming it ?

A lot of us are not from the US, so what does 'The Fifth' do for us ?

Click to expand...

Consider the broader principle rather than the constitutional right.

Yes the Fifth Amendment is American, but the same principle that you can't be compelled to testify against yourself is recognized in all civilized nations.

For Europeans, it means Article 6 of the European Convention of Human Rights (ECHR) guaranteeing a right to a fair trial in criminal cases.

The implementation differs widely from country to country and the rationale is often intertwined with the presumption of innocence.

But the core principle that the state may not force an innocent to either incriminate himself, commit perjury by falsely confessing to unproven facts, or be jailed for contempt is well recognized in Europe.

And for that reason even in the UK, the law does not punish someone for failing to account for mere random data.
The law only imposes criminal punishment for knowingly failing to disclose a key or plaintext, and the state must therefore prove that the data was encrypted, and that you had the ability to comply but refused to do so.

Plausible deniability depends on the notion that the state is limited by due process and is limited in its freedom of action.

If you live in India or China, you can forget plausible deniability because the police will just torture you until you tell them everything.

But for those of us who are lucky to reside in western nations, plausible deniability may still be useful.

So I respectfully disagree with the argument that plausible deniability is flawed.

The hidden OS is WHY you will not have to worry about the "tracks, filenames, etc.... being seen as possible evidence. The outer volume and decoy can have all the tracks you want because those SHOULD only contain safe items. Any hidden volumes will only be used from within the hidden OS. In this model you have no loose ends on the machine. NEVER never access hidden volumes from within the decoy!! If you want to protect from an accident place a small keyfile on the hidden OS desktop and make that part of the authentication for the hidden volume. No keyfile, no access. Safe from accidents in the decoy.

Now learn how to place the hidden OS somewhere else on the drive other than partition 2. Beyond this thread and scope but its doable and lends tremendous deniability for tech types..

Next; you have to account for the online activity with your ISP. If an adversary approaches your ISP and they show you online 5 hours yesterday, you better have an explanation handy if the decoy only shows 45 minutes. Get it? Keep a live disk using the same OS as the decoy. Even if you never use the live disk DVR it is always available and you could state that you go online live. There is no record or track on any hard drive when a live disk is in use and the same is true when it is NOT in use. That "story" cannot be proven to be false. From there you can deny any usage that is not "clean". The "clean" part of things is why you learn to use TOR, TAILS, VPN's, etc... --------- because those don't lead back to you or your ISP.