Alex

Don't worry at all! There is no relation between the 2 passwords. I wont go into the details, but your weak password on the outer volume has NOTHING to do with your inner volume password. You can make the outer password "12345678", don't worry.

Yes, you are right, adding this feature is no security risk at all. The problem is however that there are millions of other handy add-ons that can be added to VC core program. But your particular suggestion is really a bad idea. It sorta suggests that the user should be not afraid of using overly complicated passwords (as you did) and that VC will eventually help him to recover it. To me it is like putting ashtrays in a gas station, for the convenience of the smokers that cant resist...

You can try one of the many password crackers, which are designed to do just that. Hopefully you remember enough to be able to brute force it in feasible time. Don't expect from VC to include a password cracking tool. It's like requesting to include a word processing app to be included in VC so you can write an article, or anything of that sort. I hope you will be able to recover your passphrase, but I would advise you not to use a length of 35 (even if these are characters). It's an overkill and...

If in "Favorite volumes", in the field "Label of selected favorite volume:" there is a "[" or "]" in the description, VC messes everything after restart. The Volume ID field disappears and the volume can not be found/mounted. There may be also other characters, other than [ and ] that may cause a problem if the user enters them in the description field.

The settings of VC to define default mounting parameters is a nice feature that helps speed up mounting times after entering the password. But for a system encryption, are the default mounting settings applied as well? I have the feeling that they are not. Having tested an old computer with system encryption and SHA256 hashed password, it mounts exactly the same, no matter if default mounting parameter is set to SHA256 or SHA 512. Does someone know how VC is trying to hash the password at system...

@idrassi, the most logical solution would be to force the user to always create the containers with password, as it is now. Then however, there may be an option to change the password to an empty thing. So nobody will create non-password container by accident.

@idrassi, the most logical solution would be to force the user to always create the containers with password, as it is now. Then however, there may be an option to change the password to an empty thing. So nobody will create non-passord container by accident.

I think making the keyfile read-only is a bad idea from security point of view (as Enigma has suggested it will point to it as being used as a keyfile). I thikn myself that the user should ALWAYS make backup, even multiple backups, of the keyfile. Keyfiles are small in size and the backups can be easily stored or even uploaded online and if used wisely, nobody will ever suspect these are keyfiles. There is another point that is not really worrying me, but I am curious to know. If a keyfile is used...