Proposal to create a new technique in the program veracrypt

Topics: Feature Requests
Oct 19, 2014 at 6:27 AM
Edited Oct 19, 2014 at 6:29 AM
Hello everyone.

Thank you for your efforts in the development process of data encryption.
But I think we need technology to enable us to delete files that are inside the containers veracrypt through the introduction of a private password has been prepared in advance, and that in critical times if we have experienced.

An example of this:
Suppose that one of us was forced to recognize the password, he does not want them to see the data secret, but wants to get rid of the content encrypted, all you will do is to enter a password ordered deletion hidden, which will delete the files in the background without the knowledge of the party that compels us to confess to see our private and confidential.

Greetings to all.
Oct 23, 2014 at 8:33 PM
This is a good idea, but there is a better and more effective way to approach it.

Allow the user to set a password when creating a volume or WDE as normal.

Password = Normal password to open WDE or container.

Passworddelete = Overwrite headers, including backup headers with CSPRNG.

If a user has some time (seconds) to defend their data from being stolen they can simply start their computer and enter their normal password but this time suffix "delete". A confirmation box should pop up with a simple warning and a Yes / No answer.

If the user clicks YES, VeraCrypt should immediately overwrite the headers, including backup headers and also WDE boot.

This would make all connected hard drives useless to an attacker. It would also allow the user to claim plausible deniability by claiming all connected drives are wiped clean.

This feature would be very useful if the user could access this function while their computer was running and WDE or volumes were mounted. Also via a user custom batch file perhaps.

Any accidental deletion can be rectified by the user using the recovery ISO. These recovery ISO's could be stored online, or at another physical location.

The benefits of my method compared to above are as follows...

User only has to remember 1 password, simply suffix's "delete" to genuine password to activate.

Wiping headers and backup headers is very fast. Terra-bytes of data could be 100% protected in seconds.

There is a possibility for the user to recover their drives if they accidentally use this feature by employing the recovery ISO.

This feature would be very useful to people working in hostile environments, oppressive countries and those under threat of physical / criminal attack etc.

Nov 5, 2014 at 12:27 PM
I think this would be a nice feature though maybe you could have a completely different password for delete the headers so if you somebody is knocking on your door and you know they want your info you do not have to type in your 64 character password + delete. You would have to type in this delete password before the government or whoever got a hold of it otherwise they would make a complete copy of your harddrive. Then they would beat you for giving them a false password. Though if the government really wants information from you that bad they probably would just torture you to you told them the information you wanted.
Nov 5, 2014 at 1:18 PM
secure101 please read my post above, I think it encompasses your request :)
Nov 5, 2014 at 8:18 PM
Real password=342#%@339398r897

Delete password= 123

I was not sure if that was what you were trying to say or not in your one post. Though I would get rid of the "are you sure prompt?" because if in a bad situation every second could count. Thanks for your response L0ck.
Nov 7, 2014 at 9:58 PM
A little reminder: when a password is entered, it is first checked against the main header and if it doesn't work with any key derivation algorithm, it is then checked against the hidden volume header.

So, if we define a third password that should function as an erase password, how should we detect the purpose of this password? The only answer is we have to create a third header that must be checked after checking the main header and the hidden volume header.

I don't think that having a third header is an acceptable solution especially knowing the use case for this erase password.

So, the only possible way to implement this feature is to add fixed suffix to the password as proposed by L0ck that VeraCrypt will ignore when deriving the key from the password and it will be used to activate the erase function if the password is correct.
For maximum security, the value of this suffix must be defined by the user himself and stored as a configuration parameter for a volume. When the erase functionality is activated, VeraCrypt will wipe the header of the volume and also this configuration parameter so that no one can tell that it was ever defined by the user.

Any thoughts on this?
Nov 7, 2014 at 11:16 PM
Thank you Mounir for your interest in this.

I don't understand this part "For maximum security, the value of this suffix must be defined by the user himself and stored as a configuration parameter for a volume."

I understand you say the suffix can be user definable but I don't know where you are storing the value. If you are storing it encrypted within the header on each separate drive then I understand.

If however you are suggesting that this value is stored in the VeraCrypt program files on the local computer then I would like to suggest this is not a good idea.

We must assume the user may be using a portable version of VeraCrypt and also installed versions on other computers with removable drives.

I have given thought to try to prevent user error and complaints, especially as we are dealing with deleting access to users data. Allowing the user to define their own deletion code might lead to some accidental wipes, forgetfulness and claims the function does not work etc.

As this suffix may only be used after many years the likelihood of a normal everyday user remembering their special suffix, under stress of having their computer stolen, is probably very low.

Can I make another suggestion ? Have a simple tick box next to where users enter their password. In fact, to avoid error or accidental presses, have two tick boxes but at opposite ends of the password window. Both boxes must be checked to delete, after the user enters the normal correct password.

No storage of user defined special suffix's is required and it works from portable.

There is no need for confirmation questions or for the user to remember more than one password or to remember a special suffix. A very clear GUI tick box can be understood by anyone of any ability.

The fact the user has to know the actual password prevents malicious interference.

I would also really appreciate this feature to be available via batch script, with some additional features. As batch scripts or command line is unlikely to be used by inexperienced users there is scope to add more risky features, like the ability to run the deletion without knowing the password. This is useful because it is not wise to store the password on a batch script.

I would really appreciate the ability to make a panic batch script that would wipe all my headers without me having to store my password in the script or enter it on execution.

Thank you and I am sorry for such a long reply :)
Nov 7, 2014 at 11:36 PM
Just an addition to the above, as if it wasn't long enough :)

When VeraCrypt is wiping a given drive, it must check to see if it is a system drive or a storage drive.

The reason for this is that the system (normally C ) drive does not have a backup header at the end of the disk. If you overwrite this area then the user may not be able to use the ISO to restore that drive.

Obviously the backup headers need to be wiped on storage disks .
Dec 2, 2014 at 8:42 PM
Edited Dec 3, 2014 at 3:08 PM
I would like to discuss the merit of this panic button feature request and the application of using this requested feature.

If a government agency wants to seize your computer, disk drives and paper files, they will not likely knock on your door. They will force entry into your home or into your business, subdue any persons in the dwelling and begin seizing all equipment and materials.

The user Maknoon wants a panic button to permanently prevent access to the data and be executed immediately since he will be forced by law or coercion to reveal the volume passwords. I assume the wipe header keys feature would be for all mounted and unmounted volumes that are connected to the PC.

You may have different partitions and/or drives that are not currently mounted in VeraCrypt at the moment you use the panic button. However you want the unmounted header keys destroyed since these volumes are connected to your PC. For the C partition, you will need to reboot to prevent access to the C volume since a currently running OS will not be impacted by the header key/bootloader being wiped until reboot.

Even if it is technically possible to wipe the header keys of mounted and unmounted volumes connected to the PC, this creates a new problem of false security that the data has been permanently destroyed due to the header keys have been wiped. This is due to the likely event that the person has taken the prudent precaution of performing backups of all their header keys.

I highly encourage users to make backups of their header keys and not rely on the embedded backup header key for non-system volumes. The TrueCrypt forums had many incidents from people that may have been able to regain access to their data if they only made backups of their header keys that were damaged by other software or on rare occasion a BSOD even with the built-in backup header key for non-system volumes.

Storing the backup of the header keys will have to be on some other physical media or in the Cloud. Both will be seized by the government and used to restore the header keys in the event you use the panic button feature. In order to prevent permanent access to the data, the entire encrypted partitions more would need to be wiped to render restoration of the header keys useless. As an example of permanent destruction of data, review IronKey self-destruct features to see what it takes to prevent any access to the data after 10 failed password attempts. In short, the thumb drive first secure wipes the memory chips in the thumb drive then destroys its encryption key and then shorts-out the encryption chip.

So let me purpose a modified panic button request feature to mitigate some but not all the limitations I discussed above.

To me, the criteria for the panic button/destroy header keys feature request are:
  1. Both the standard and hidden volume header keys should be wiped. Even if a volume does not have a hidden volume, the hidden volume header key is located at bytes 65536 through 131071 (at least was in TrueCrypt) and should be wiped along with the standard volume’s header key. When the hidden volume is not used, that location is merely random data. For non-system volumes would require wiping the embedded backup header keys for the both the standard and hidden volume.
  2. The wipe header key feature should not require the password or be password protected in order for the panic button feature to be used immediately.
  3. Provide wipe header keys options in the hot key section by allowing the user to map the hot keys to something of their choosing.
    a. There should be at least two types of header key wipe hot keys options available, wipe all VeraCrypt volumes and wipe selected VeraCrypt volumes.
    b. The GUI should have a specific menu option for wiping the header keys which would take too much time to use in a crisis moment but would allow for those moments when immediate action is not needed.
  4. Provide a pop-up box with a list of check marked boxes for each volume’s header key to wipe.
    a. Have a select all volumes option for one-click to select all volumes.
    b. If using the hot keys, all volumes will be selected or none of the volumes will be selected forcing you to pick the volumes.
    c. Also note in the message if the list represents only mounted volumes or both mounted and unmounted volumes or only volumes from the Favorite list.
  5. Only one confirmation warning dialog box or pop-up window which should be explicit to confirm the wipe header keys for the selected volumes will result in loss of access to data on those volumes unless external header keys are restored to an unmodified partition. Meaning, if you wipe the header key and a month later try to recover the data using the external backup header key after you have formatted and modified the volume, you will not be successful or may require extensive recovery tool effort to restore some of the data.
  6. After the header key wipe has completed, provide a pop-up box to alert the user to securely destroy all external backups they may have made of their header keys for the selected volumes to permanently prevent access to the data on those volumes and if time permits, run a partition wipe utility until VeraWipe is available for each selected volume.
  7. Another pop-up box to alert the user if any mounted/unmounted volumes may not have had the header keys wiped depending how the software “knows” what is a VeraCrypt volume. For example, if you are relying on the Favorite list to tell you which volumes are VeraCrypt, then you would have missed volumes that were not in the Favorite list.
Thank you to all for contributing ideas and to Mounir for moving VeraCrypt forward.
Dec 7, 2014 at 9:06 PM
Thank you all for enriching this discussion.

One point that is starting to be clear is that verifying the password in order to activate this feature defeats its purpose because of the time needed to verify the password.

That's why I'm considering Enigma2Illusion proposal of the use of hot keys to activate this function along side a confirmation message. In emergency situations, this approach should take 3 seconds which I think is adequate.

Any comments from the other discussion participants?
Dec 7, 2014 at 11:21 PM
I'm ok with hot keys, but I have a problem with it for myself. It's ok now setting a hot key configuration up but in 18 months time when I have a burglar kicking my door down will I remember this hot key sequence which I have not used for 18 months, no I won't !!!

I suggest allowing hot keys, but also something in the GUI, perhaps on the main GUI screen at the top ?

I think 2 confirmations should pop up, first explaining you are about to destroy your headers and lose access to your data unless you have a header backup.

The second message should simply be a repeat but the OK button switched sides to prevent double clicking.

I certainly don't think any more messages should pop up after that. If we have the pop up advising to delete backups as you have just destroyed your header, it might land the user in a lot of trouble !

If the burglars notice you have deliberately destroyed your headers it may cause further violence. If there is no other warning then the computer could shut down quietly. In fact the burglars may power it down by taking it away anyway. Either way, they won't know the data is inaccessible until a later date.

I think there could be some sort of pre configuration within the GUI for this feature. Allow the user to set if ALL drives should be wiped, including non encrypted or unmounted drives.

The value of the data may be so great that the user is prepared to spend a day reloading drives from backups rather than risk allowing it to fall into a thief's hands.

Also I would be grateful for some command line control of this feature.

Dec 8, 2014 at 1:00 AM
I should have clarified number 5 regarding the confirmation warning dialog to include the message as stated in my post with a proceed Yes/No buttons. Meaning you would have to move your mouse over one of the button to click or use the keyboard "Y" or "N" key to activate your response.

I think we should take a clue from Windows prompting for deleting a file or formatting a drive, you get one warning box. If there is a second warning box, I agree the buttons should be reversed in their location from the previous screen to prevent double clicking confirmation incorrectly. However, it is still possible via the keyboard to double key "Y" or "N".

Regarding number 6 to securely destroy your external header key backups and if time allows to secure wipe the volume is a reminder to the user. It is the user's decision if they want to permanently prevent access to the data on those VeraCrypt volumes.

I agree that the same functionality should be available from the GUI without setting-up the hot keys and if feasible being able to initiate the panic button via command line in case you want to call a script instead of using a hot keys.

Regarding L0ck's idea:
Allow the user to set if ALL drives should be wiped, including non encrypted or unmounted drives.
I do not believe this should not be part of the panic button feature since the time to secure wipe non-encrypted drives is going to a long time.

Kind Regards,
Dec 8, 2014 at 1:05 PM
I'm not sure how wiping an unmounted drives headers are going to take longer than those of a mounted drive. As for the unencrypted drives, who has those ??? LOL ..... overwriting, where the headers would have been, will render the drive useless to a non computer literate attacker. This provides valuable time to a user, the idea is to do as much destruction in as little time as possible.

It is a valuable feature and necessary to ensure ALL the users drives are safe, very quickly.

I also mentioned this is a pre-configuration, which means optional. If you don't need it then you have the option not to select it.

If we did not have this feature the user would either have to always ensure they have their encrypted and important drives mounted or the user will have to mount each drive and then wipe the headers in an emergency.

I don't believe you would think that is a good idea :) LOL

I am not sure what additional security is offered to the user if this feature is denied ?

Ideally I would like VeraCrypt to handle the entire process of a panic button, I did not go into full details of this because I didn't want to scare Mounir away from the idea as it may go beyond the scope of VC.

However, Mounir seems quite keen on these features so I might push my luck :) My dream would be that on activation VC would overwrite the VC headers and backup headers regardless if the drive is mounted or not and encrypted or not.

With the headers gone the encrypted data is "safe" from physical attack if the power is removed from the computer. However I would like to think those who have valuable data would be smart enough to physically protect their PC. This allows time for further protection.

My fantasy ideal solution.

On activation...

VC wipes all headers / backup headers, encrypted / unencrypted drives.

Lock keyboard and mouse input.

Disable firewire / USB ports.

VC then zero's out MBR on all currently mounted drives. (I assume with the key in RAM this is possible).

VC then zero's out the entire drive from beginning to end.

The "zero" selection and not "random" is an effort to help those living under the RIPA law.

So as you can see above, we protect the encrypted data almost immediately. If the user has hidden their PC, or physically protected it well enough every second it takes the attacker to get to it more and more valuable data is wiped. Without a MBR data recovery is VERY hard. Also the attacker cannot power off the computer or even access it via keyboard. We have also blocked the use of "Kung Fu" USB and firewire attacks to capture the key from RAM.

The above would be my perfect solution but as I say, I didn't want to over burden Mounir or frighten him away LOL :)
Dec 8, 2014 at 10:35 PM
Hello L0ck,
I agree with your statement about the speed of wiping the unmounted VC volumes. I mistakenly overlooked that part of the sentence as I was more focused on the non-encrypted statement. My bad. :)

While your post above has merit, the shortcomings will still allow someone to recover some or all the data on non-encrypted drives/partitions by connecting them as a secondary drive on another computer to run recovery tools or MBR rebuild tools in order to access the unencrypted data. Hence, wiping the MBR and/or where the header keys would be located on non-encrypted drives/partitions will not prevent recovery of the some or all of the data depending on the success of the recovery tool. This can lead to a false sense of security which would damage the VeraCrypt brand name when reviewed by security audits.

My thoughts are that the panic button feature is only for the VC volumes and does not touch other drives and partitions that are not encrypted by VC. If a person deems every drive/partition as sensitive data based on their threat model, then they need to encrypt all drives and partitions connected to the PC with VeraCrypt to be wiped by the panic button.

I think we need to know from Mounir what is possible with the proposals of wiping the VC volumes.
  1. How will VeraCrypt know which drives/partitions and file containers belong to VeraCrypt when they are unmounted? I do not think it would be wise to have a file with the location of every VC volume and file container that was ever mounted on the system to be used as pointers to the volumes. The irony is the Favorites have this information stored in the XML files when you create Favorites.
  2. Will VC wipe both mounted and unmounted VC volumes when the panic button is pressed without touching other non-VeraCrypt drives and partitions?
  3. Will the VC volumes need to be mounted, unmounted or can either state in order to wipe the volume’s header keys including the embedded backup keys for non-system volumes? For example, when you want to backup the header keys for a volume, the volume must be selected and unmounted in order to perform the backup. Will that be the case for wiping the header keys?
Once Mounir provides guidance with what is feasible for the panic button feature, the community can narrow our feedback.

Kind Regards,
Dec 9, 2014 at 12:16 AM
Good grief, look at this thread :D

My offering the pre configuration ability to wipe unencrypted drives has good reason.

Rather than expecting VC to contain some logic code to work out what is mounted, encrypted and unencrypted it would be a simple cover all solution. How will VC know what is sensitive data mistakenly copied to unencrypted drives ? It can't know and it is not possible to know. With security products, simple is always better.

Don't forget the ever present "just typical" law. No doubt when the time comes a user will "just typically" have an unencrypted drive connected to their system. We need to at least try to help the user.

There are no shortcomings with my panic button idea within it's limited scope as explained above, particularly if the user follows simple and basic security practises. The additional inclusion of attempting to wipe unencrypted drives is to allow for human error and bad practice. I have worked with and worked on development of security software for a good few years, the "human" element is the weak link.

No matter how many times we preach to users not to employ bad practice, they will. There is little pleasure in sneering at them and pointing out their security infractions. Many people who may potentially use VC may do so in war zones, under oppressive regimes or simply not be as educated in computer security as we are on this forum. To be concerned about the reputation of VC's overwriting abilities, during a restricted time period, on unencrypted drives seems somewhat diminished under these circumstances.

I understand your concerns for VC and it's reputation, I am all for protecting VC's good name and I have challenged people who have threatened to undermine it, on this forum and elsewhere. We have to accept VC is not a 100% cure all, however we must not allow this fact to stifle ambition or attempts to make it so.

A few direct questions if I may and only if you have time :)

Remember this is a "Panic" button for panic situations.

How will security be improved by not allowing the attempt to wipe unencrypted drives ? I don't mean just educating the user or removing a false sense of security, as everyone gets slack occasionally.

You say you fear for VC's reputation if wiping of unencrypted drives is implemented. How will VC appear if a user forgets sensitive data was once written to an unencrypted drive connected to their computer ? This drive was not wiped due to the feature not being implemented. The user is convinced ( in his own mind ) he has never saved this data unencrypted and so spreads the word that VC's encryption has been broken.

Are you really claiming it is better or more secure to have a computer sitting idle with valuable data unencrypted when it could be wiping at least some of that data ?

You imply the use of recovery and MBR rebuild tools will defeat wiping. I suggested VC wiped the MBR to make it very difficult to recover data very quickly, using the "cause as much damage as possible as fast as possible" approach. I then said zero out the entire drive from beginning to end. Do you know of any example where data has been recovered after such a wipe ? I understand this is theoretically possible but I have never seen it done.

Regarding your questions for Mounir, we should be free thinking, let Mounir worry about coding LOL :D I think he likes a challenge, so don't try to make it easy for him :)

Thanks for your time and comments on my ideas throughout the forum. It's good to be able to demonstrate we have discussed these features before implementing them.
Dec 9, 2014 at 2:32 PM
Hello L0ck,

As stated in the manual, there are issues of data leaking from applications by using data within the encrypted partition leaking the data to the non-encrypted partition. For example if you do not encrypt your system partition, many people are not aware that MS Office will create a saved file on the C drive after a period of time. This file is not the same as the temp file you see in the current working directory. When you close the application, the saved file will be deleted from the C drive. However, as with all deleted files, you can recover the file or parts of the file depending if the file was overwritten by something else.

The point I am making is data leaks can occur from encrypted to non-encrypted volumes unless you encrypt all drives and partitions as discussed in the manual. Attempting to wipe non-encrypted drives/partitions will give less experienced users the false sense of security. Not many people read the manual. They attempt to use the product and expect the GUI to provide message boxes to guide them to proper security. It is like opening a Christmas present, putting in the batteries and just using it. Only if you get confused do you reach for the manual. :)

I understand your solution is to provide another option on the panic button feature that you call “pre configuration” to wipe the MBR and I would add to your request for future proof, GPT formatted volumes along with the likely locations of the header keys. Let me know if I understand that option correctly. However, a clearer name for the option in the wipe options section could be “Include non-encrypted volumes” with a good explanation in the manual pointing out the shortcoming that I believe exist with this approach.

Your request to perform the zero out approach for non-encrypted drives/partitions would take a long time and raise suspicion that something is being performed against the drives while the authorities or intruders are present. Using your example of when the thief kicks-in the door causing you to hit the panic button, when the thief ask you why are your drives so busy, answering with “I don’t know” may be met with violence against you and/or others in your household because the thief will know it is unusually disk activity behavior and/or they sense you are lying. Another consideration is not everyone will be using latest hardware with quad-core CPUs to perform the wipe utility against several drives/partitions in parallel to provide the maximum damage to the non-encrypted drives/partitions during the crisis situation.

That is why I suggested in number 6 in my post the message if time permits to run a wipe utility against the encrypted drives/partitions verses VC automatically initiating a built-in wipe utility during the panic button process.

All software development benefits significantly from more time spent on the analysis and design of the software features before any coding is performed. I hope these debates provide other forum member’s and Mounir with ideas that improve on the proposals for this and other feature requests discussed in the forums.

Thank you for being open to my counter proposals. :)

Kind Regards,
Dec 9, 2014 at 5:30 PM
It is frustrating trying to reply to long posts without a good quote system. I wish we had a PHPBB forum for VC.

I am sorry if this post looks blunt, I am finding it difficult to set things out :)

Your first 2 paragraphs rehearse the warnings from the documentation about data leaks, I understand the problems when users use unencrypted drives on an otherwise encrypted computer. We all know, or should know all drives should be encrypted. My points above acknowledge that but as stated, the feature request is intended to address human failings.

However, don't your comments about leaks reinforce my point about allowing the user the ability to wipe unencrypted drives ?

Addressing your third paragraph...

Wiping the MBR is ONLY for UN-encrypted volumes. Encrypted volumes only need their keys and backup keys wiping at first.

Yes, include GPT.

I wasn't arguing a case for the terminology used just yet, I wanted to establish the feature first, but “Include non-encrypted volumes” sounds good. I was thinking of "All attached drives" but I am not concerned with the term employed.

I am not calling the panic button "pre configuration". I am saying there should be a pre configuration option to the panic button. A user can sit and think about their unique situation and in a calm manner pre configure their own requirements. Allowing them to make decisions before an event means the panic button will be more effective for them personally.

I understand a full zero out would take a long time. Don't forget the encrypted data is almost immediately safe when the keys are wiped. The zero out is to help protect the users from RIPA and the full overwrite is to allow for the user being careless and using unencrypted drives etc. Again, very common human failings.

Raising suspicion may not matter, or even be noticed. If the data is valuable enough the user may prefer to take his chances with explaining rather than not at least attempting to do something about it. This is why it is so important to allow the user to decide with the pre configuration of the panic button.

Your point about not everyone has the latest hardware and quad-core CPUs is something which used to restrain the development of TrueCrypt. If we base design decisions on the lowest capable hardware we remove valuable features from other users. The panic button and wiping is optional, no one is forced to use it.

Your issue about hardware ability reinforces the case for wiping the MBR first on UN-encrypted drives. Once the MBR is gone, it is very difficult to recover data, especially if the zeroing out process gets time to start.

This isn't a smart comeback, but I noticed you did not answer my direct questions, that's ok you don't have to. I would however like to know if you concede those points ? It's hard to tell from your replies as it seems you are now in favour of this feature.

Thanks :)
Dec 9, 2014 at 6:34 PM
Edited Dec 9, 2014 at 10:59 PM
Hello L0ck,

I thought that my previous statements answered your questions. The extra dot between the lines below was to get the forum quoting to stop bunching the quotes and responses into one big paragraph.
How will security be improved by not allowing the attempt to wipe unencrypted drives ?
Per my previous statements regarding the ability to recover the data that is still on the drive. I will not rehash my statements. :)
You say you fear for VC's reputation if wiping of unencrypted drives is implemented. How will VC appear if a user forgets sensitive data was once written to an unencrypted drive connected to their computer ?
These limitations are addressed in the manual and did not harm TC's reputation since the user should have read the concerns about data leaks. Having VC attempt to wipe the non-encrypted drives leaves the ability to recover the data by a government or a thief that knows how to use Google. :)
Are you really claiming it is better or more secure to have a computer sitting idle with valuable data unencrypted when it could be wiping at least some of that data ?
I stand by my assertion that data remains recoverable due to the power plug will be pulled since it will take hours or days depending on the hardware to zero-out from start to finish on each non-encrypted drives/partitions.
Do you know of any example where data has been recovered after such a wipe ?
My statements center on systems with several non-encrypted partitions/drives that will take a very long time to complete the zero wipe operation allowing for the data to recovered. I highly doubt the government agency is going to let the PC continue to run once they make entry to your home.
I think those are all the questions you asked. :)

Thank you for explaining the pre-configuration. Now I understand that this is would be something in the GUI to configure the panic button actions/options. I still would like to use the hot keys for:
  1. Wipe all encrypted drives/partitions.
  2. Wipe selected encrypted drives/partitions.
  3. Wipe all encrypted & non-encrypted drives.
  4. Wipe selected encrypted & non-encrypted drives.
To be clear, I am not in favor of the wipe of non-encrypted drives.

However, I am willing to compromise since it is a configurable option that is not enabled by default. :)

When the option for wiping non-encrypted volumes is enabled, a warning box of the limitations should be provided to the user and maybe reference the user to see the manual for detailed information. The "See manual..." to explain the process and that the data can still be recovered for non-encrypted drives/partitions if the operation of zero-out is not completed. This would help protect VC's reputation. :)

I think there should be two options for Wipe all non-encrypted volumes:
  1. Wipe only MBR/GPT and header key locations due to time constraints.
  2. Wipe MBR/GPT and header key locations and zero-out volume (will take hours or days depending on hardware).
I would like to hear from other forum members on what are their opinions after reading this thread carefully.

Kind Regards,

Edited to fix grammar errors.
Dec 9, 2014 at 9:13 PM
There are many good ideas coming out from this discussion although some points may trigger further debates.

It is good to have the point of view of others on this and the possible implication of its implementation. The length of the posts may discourage other from following the discussion so maybe I'll have to do a little summary before inviting others to participate.
Dec 10, 2014 at 11:48 AM
Edited Dec 10, 2014 at 11:54 AM
Per my previous statements regarding the ability to recover the data that is still on the drive. I will not rehash my statements.
I stand by my assertion that data remains recoverable due to the power plug will be pulled since it will take hours or days depending on the hardware to zero-out from start to finish on each non-encrypted drives/partitions.

It's almost like you are saying that because there is a possibility, in your own scenario, that the wipe may not 100% complete then we should give up and not attempt it. An example of how that sounds is similar to saying there is no point using encryption because someone may find your password. It's a defeatist argument I have trouble understanding or find any common ground with. I do not see what you or VC will gain by not trying, the overwritten data is gone for good and that might have been the sensitive data.

Have you considered other scenarios ? Some may make an effort to physically secure their PC's, or even hide them. Some have UPS units and other situations where the computer may be accessed via VPN and might not be reached in time. There are many situations where this feature is useful, I appreciate it may not help you personally but I have not read anything you have written to convince me it is not good for others yet, which is why I asked for confirmation.

The wiping of unencrypted drives is not intended as a replacement for encryption, it is an attempt to help non skilled, unaware or careless users in their time of need. Ridiculing at them afters and pointing them to the manual because they once attached an unencrypted drive will do the VC community no popularity favours.

The main thing I would like you to remember, this is a "Panic" button, as in desperate times need desperate measures.

1 Wipe all encrypted drives/partitions.
2 Wipe selected encrypted drives/partitions.
3 Wipe all encrypted & non-encrypted drives.
4 Wipe selected encrypted & non-encrypted drives.
Yes something like the above, although they can be reduced to simplify things. Don't forget the most important, wipe the header and backup header first :)

However, I am willing to compromise since it is a configurable option that is not enabled by default. :)
YAY ! :D

I think there should be two options for Wipe all non-encrypted volumes:

1 Wipe only MBR/GPT and header key locations due to time constraints.
2 Wipe MBR/GPT and header key locations and zero-out volume (will take hours or days depending on hardware).
There is no gain in deliberately limiting or restricting the wiping in option 1. We only need option 2 and only having that option removes unnecessary clutter from the UI. The simpler it is the better for everyone. Wipe the MBR/GPT and headers on all drives then go back and try to wipe as much as possible before being interrupted.

As I said before there is no logic in having a computer sat idle when it could have been wiping sensitive data, regardless of the fact it might not get chance to finish. The user can do his best to delay access, safe in the knowledge the longer he stalls the attackers the less they steal.

It seems to me, you don't actually have much of an objection to the whole idea after all. While I am pleased we have it down to one last issue, I have to admit it still does not make any sense to me :)

I have a philosophy with regards to VC, which helps me make decisions on this forum and whilst making my own requests. The question I ask myself is "Does this (insert feature here) have the potential to make the users data more secure", I believe from previous discussions this is also Mounir's approach. When employing this concept, I have to say it is better to attempt (time permitting) to entirely wipe a drive, especially considering this is a "panic" button.


In an interest to move forward here is the summarised request again incorporating Enigma2Illusion's hot key request and the ability to opt out of certain parts.

Panic Button..... Mounir please can we have the following ?

Allow user to run panic button from GUI.
Allow user to create "Hot Keys" to run the panic button.
Allow pre-configuration of the actions performed by the panic button.

Options in the pre-configuration page...

Wipe the header and backup header locations on all attached drives.
Wipe only user defined drives header and backup header locations.

Unencrypted Drives Options ( if it is possible to work out which are unencrypted )

After header and backup header areas are wiped on all drives attempt to reduce data exposure on unencrypted drives.

Wipe MFT / GPT first.
Attempt full wipe of drive, time permitting.

Jan 7, 2015 at 11:36 AM
Hi mtpagkatipunan

I don't wish to sound rude, so please be aware this is text based communication :) I am also writing in a rush before I go out.

However I don't think you have understood the point of this feature at all.
I think everyone here is getting paranoid. It seems that most of you don't believe that VeraCrypt can't secure your files.
The opposite in fact, I / we believe VeraCrypt is so strong that Governments will be forced to intimidate / attack innocent users rather than brute force or crack a VeraCrypt protected drive.

You may be lucky where you live, encryption may be a legal right. However in many other countries including some first world ones, encryption is basically illegal now. This forces innocent users to think of other ways to protect their private data, such as this request.

Please take the time to look at a law called RIPA, which effectively outlaws encryption. This is why it is so important to fill the drives with zero's, any random data alone is enough to secure a conviction in the UK.

You may feel safe in your country at the moment but laws can change very quickly, it is much better to be prepared in advance for these changes.
Jan 7, 2015 at 10:57 PM
mtpagkatipunan wrote:
As I said, if you're not keeping any illicit material in.your hard disk, then you need not worry. There's nothing to be afraid of even if you're force to open your hard disk by government people.
This one paragraph of yours, which I have quoted above, has just lost you all credibility on this or any other encryption orientated forum.

You are either woefully misguided or deliberately trolling.
Jan 8, 2015 at 1:26 AM
mtpagkatipunan wrote:
Hate to say this..but you are paranoid L0ck. If government authorities force me to open my hard disk and found nothing but just bunch of my personal files, my holiday pictures, letters to my fiancee.. What will they do to me? --Nothing.
In some countries they would imprison you for a very long time as they will claim that you have a hidden volume.

This feature, given enough time, is an effort to defend against this.
If our hard disks or laptops got stolen or suddenly seize from us, then what good is this wiping procedure?
This feature aims to address a different scenario.
It is is only good as long as we still have the equipment in our possession, because we control the procedure of wiping.
Some of us use VPN or remote desktop, you don't have to be physically there. The computer can be hidden or made inaccessible within the same building, it has to be found before it can be stopped. This feature may not be suitable for you personally.
I think most of users of Encryption programs like VeraCrypt are more concerned in preventing unauthorized person(s) in getting access to our personal files in the event our laptops or hard disks are stolen or lost. That's why we resort to encrypting our drives--hence, the very main function of VeraCrypt.
Yes, in an ideal world that would be wonderful, things are not that simple. Did you read RIPA ?

Your suggestion of the ESC key is not a good one. The ESC may be used for a cancel feature in VeraCrypt in the near future.
Jan 8, 2015 at 2:58 PM
mtpagkatipunan wrote:
Perhaps an automatic wiping procedure will initiate after a considerable number of unsuccessful attempts in the password entry. Is is feasible?
The simple answer is any competent attacker will copy your volume first. They will also extract the hash and run it in a brute force program.
Have you encountered a hard disk drive encrypted using a Dell laptop
Closed source firmware has no respect amongst crypto geeks. Take a look at some lectures by Bruce Schneier about how the [insert 3 letter agency here] infiltrate and corrupt propitiatory crypto, firmware and even hardware !