Alex

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...

Currently, when a favorite volume is mounted, unless the favorite settings are for specific hash (pkcs) algorithm (ie blowfish), VC will only try the hash algorithm that is set in the "default mount parameters". And if the default parameters are different than the volume hash, it will return WRONG PASSWORD. In fact I believe it is the same for non favorite mounting: if the volume hash is not as the default mount parameters, the user will get an error message and will not be able to mount the volume....