This project has moved and is read-only. For the latest updates, please go here.
15
Vote

VeraWipe

description

https://veracrypt.codeplex.com/discussions/572862

At the moment no one can actually claim plausible deniability with Truecrypt or even VeraCrypt. The reason is that there is no plausible excuse to having so much cryptographically random data on a hard drive.

Users could claim to have used DBAN, but not only does DBAN sometimes fail to write to the entire disk, I am not 100% convinced the random data outputted by DBAN is statistically similar to the data written by VeraCrypt.

This is why I am suggesting a new product called "VeraWipe" This should be a stand alone product separate from VeraCrypt. VeraWipe would allow users to securely wipe (data destruct) their hard drives like DBAN offers now.

The main reason for VeraWipe is that it produces the exact same random output as VeraCrypt would. Having this separate tool available gives all users the excuse they have simply wiped their hard drives with VeraWipe and they are not encrypted at all.

Without VeraWipe no user can be confident to make a claim of a wiped disk as I am sure (guessing) there will be some difference in the output from DBAN ( or any wipe program) and VeraCrypt.

I hope this would be an easy tool to make as VeraCrypt has all the functionality needed to do this now. Just create a random 63 character password and encrypt the entire hard drive, then dispose of the password. This would obviously be packaged and distributed as a hard drive wiper / overwriting software to enhance the plausible deniability.

file attachments

comments

algreider8 wrote Jan 16, 2015 at 4:28 PM

One of the most valuable options that VeraCrypt suggests is the plausible deniability. Thеrefore, your idea, L0ck, is very good and important.

Definitely+1!

Degski wrote Mar 1, 2015 at 9:47 AM

If we assume for a moment that VC produces proper random uitput (that's the basic premiss of encryption in the first place), then the only way the output of DBAN and VC would be distinguishable from one another is that somehow DBAN's RNG is inadequate. I did/can not check the next claim, but I would think the developers of DBAN put a bit of thought in their RNG(S) (it's not that hard really), and implemented a good enough (for its purpose) RNG in DBAN.

In my view to put it succinctly, SnakeOil!

Definitely-1!

TGS wrote Jul 13, 2015 at 4:33 AM

I just found this discussion and have another possible suggestion that might be a lot easier to create as well as functionally use within the current implementation. The main TC and now VC idea for plausible deniability has laid within hidden containers. But as it stands the way hidden containers work, you stick all your data in the hidden container that you wish to hide, and then put in the outer volume things you don't want to hide pretending that it is what you were trying to hide. But the way this implementation works makes little to no sense from a usability perspective.

If you have a 1 TB container (Or drive) and you have 600-800gb of data that you want to hide and 50gb as mask data to show a potential attacker. Your plausible deniability is pretty well shot because 1. You won't have accessed the data recently due to the limitation of "changing" data" 2. You have a massive chunk unused. Which becomes somewhat obvious.

So a simple solution would be to change the protection system for hidden containers to instead allow you to open both outer and inner volumes as well as altering the way VC sees the outer volume if the protection option is enabled so that it only shows the up to the "free space" of that container. Furthermore allow the user to open both simultaneously. The idea being that you can actually use both equally provided you know both passwords. If you know both passwords and enter both passwords there is no reason for it to throw some error when you start writing on the hidden volume, as you've deliberately protected it.

This way you can actually maintain active live outer and inner volumes. If you are ever confronted with a situation where you are being forced to give up a password, give up the outer volume password and not the inner. No one will know that the inner exists exactly per the original intention. The fact that the current implementation doesn't allow you to use both outer and inner as well as not determining the end point on the outer as to allow you to use it without risking the inner just doesn't make sense to me given that against an attacker you would never put in the hidden volume password anyway.

With this implementation you could simply encrypt everything and have a hidden section for the stuff you wish to hide. Instead of having to have a largely static outer volume that you are never meant to touch, and that you can't touch at the same time as working on the hidden volume.

TGS wrote Jul 13, 2015 at 11:15 AM

Btw, just realized can't edit or delete the post. I want to add though that I understand that the concept of writing to an outer volume might appear to compromise the plausible deniability, but I'd contend that it would actually aid it. Provided the system (if the hidden volume password is put in as well) recognizes the limits between the outer and inner space. I've been working with TC and now VC for quite some time and the only time I can imagine a hidden container in its current implementation actually being useful is in very small containers. The larger the container/partition/drive becomes the harder the plausible deniability becomes due to the fact that you'd always have an abnormal amount of free space and the files on the outer volume wouldn't have as much file activity.

Would love to hear some opinions on my comments though. Or if there is a solid opinion as to why writing to the outer volume is a no-go outside of the original TC methodology. Which I firmly believe was created back in a time when home users did not have and house "big data" as in hundreds of GB or even multiple TB's of data.

eisfhvaeofp9 wrote Aug 14, 2015 at 8:23 PM

you are missing the point.
Free space WITH or WITHOUT a hidden volume SEEMS ALWAYS random data!
hdd is full with random data = wiped or more probably encrypted
but
encrypted partition containing random data = this is the way the program works, it fills the free space with random data until is used (or hidden os)
so there is no way to tell if a hidden os is present.
(image from true crypt guide)

if you have 600-800gb hdd and you have only 50 gb used it means:
nothing! in fact you can have a huge hdd that it is near to empty why not? where is the problem? if i install the os and a few programs i will fill 50 gb and if someone ask why 800 gb hdd for 50 gb of data? i tell why not hdd are low cost and i might fill in future (i have 1 tb unencrypted hdd that is filled about 100 gb).
the other option is that you have huge hidden system but noone can prove it.

codegrind wrote Jan 8, 2016 at 1:16 PM

I am not 100% convinced the random data outputted by DBAN is statistically similar to the data written by VeraCrypt.
Then prove it or disprove it using scientific (mathematical, statistical, cryptological) methodologies, but don't request that other do work based on your convictions.

-1 this is false assumption, besides it's minor use case, and energy of developers can be better spent somewhere else.

I'm voting to close this issue as "won't fix".

mojo_chan wrote Jun 27, 2016 at 11:04 AM

+1

I would suggest including this functionality in the main VeraCrypt app. That gives plausible deniability for having it installed or on a flash drive. After all, if you don't use it, why have it on your computer? You could claim it was just for the secure wipe functions.

An initial version wouldn't even need to be complicated, just a simple file shredder type function that writes crypto quality random numbers over the content of an existing file, rounding the file size up to the next 1024 bytes. For security also rename the file before deleting it. On most (all?) systems this forces the OS to flush data.