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

IMO, a potential design flaw within "hidden" volumes

description

Fundamentally, a hidden volume should be, well, hidden. Adding context to the UI that you must "specifically"
display and use goes completely against this "hidden" concept.

Case in point: The documentation states that you should never enter in the hidden volume password to keep your hidden volume secure, correct?

"These files will be there for anyone who would force you to hand over the password. You will reveal only the password for the outer volume, not for the hidden one. Files that really are sensitive will be stored on the hidden volume."

So what happens if you are forced to mount the outer volume and someone tries to manipulate the data located within the outer volume? As I understand the documentation, there is a very high chance that the data within the hidden volume with be corrupted with total data loss.

Therefore, would it not be more prudent to "automatically" set the hidden data volume as "read only", by default, when the outer volume is loaded? In this way, when you are forced to load the outer volume you won't have to go into the "more options" menu to set the hidden volume password, so your data isn't potentially corrupted?

In a real-world scenario, it certainly won't be feasible to sneak into the "more option" menu and set your hidden volume password without someone seeing you do it. Therefore, the logic should be to set the hidden volume to read-only, by default, if only the outer volume is loaded. Realistically, there isn't even a reason to have the UI option to set the hidden volume password inline with the outer volume password. It's redundant since you can simply load the hidden volume any time you choose, and leaves the user open to being forced to enter the hidden volume via a number of unsavory methods.

Certainly, the hidden volume file can be deleted via intrusive and accidental means. That said, it's much safer and easier for the user to NOT have to worry about and/or use hidden volume options within the user interface. It causes confusion and leaves the use open to attack.

If any of my assumptions or understanding of the program are incorrect, please feel free to respond in kind.

-Thank you

comments

Lurkios wrote Mar 1 at 12:17 AM

Setting the hidden data volume to read-only gives away the fact that there's a hidden volume and exactly how large that volume is.

Those needing to use a hidden volume would usually consider the loss of data an acceptable risk in comparison to discovery of the volume. It would be highly recommended to keep backups in a safe location.

Fenderluvr wrote Mar 1 at 5:59 PM

Thanks Lurkios.

I suppose I can conceded to your point, as I was not aware of that fact (If you could expand on "the how", I'd appreciate it). However, the "Protect Hidden Volume" section within the UI seems as bad or worse of a give away; to me at least. If a user is truly being "coerced" into giving up a password to an encrypted volume, then it's logical to assume that the person doing to the coercing is informed enough to realize the possibility of a hidden volume within said encrypted volume. This being the case, a better option be to simply remove the UI option for hidden volume protection, completely, and live with the "acceptable risk", as you put it.