Currently if I understand it correctly, when using a large key-file VC only uses the first MB of the file together with a hash. A standardized hash however can be recreated for a file and the first MB is easy to copy. Making it possible to fake large key-files.
I've experimented with up to 10GB worth of 1MB keys. It is possible to use that many keys on a VC volume, however when used from usb/sdcard it becomes too slow for VC to be of any use and it tends to crash VC. When used on a standard HDD with sata connection VC is able to process the 10GB of keys in ~2 minutes without crashing.
The reason to use bigger keys is simple: When a system is compromised a user only needs to use the 1MB key together with any keyboard or mouse input once for the attacker to gain access to a VC volume. It is easily stolen with modern internet connections and the attacker can slowly copy the VC volume without the user decrypting it. However a large enough key would prohibit the attacker to gain it quickly. The attacker would need to copy the key over a long period of time too. When the key-file is changed frequently on a secure offline system the attacker can't access the VC volume without gaining physical access to the key-file. However using keys that big has its limitations as my 10GB experiment has shown.
Thus my idea is to implement different modifiable hashing algorithms that only use part of the large key-file but force the attacker to gain a copy of the whole key-file.
Desired behavior
The user would select multiple of thousands of pre-selectable algorithms, where the order also changes the results, to hash the file/process the "1MB of data". "The user stacks the algorithms dynamically as if using multiple key files." Not like VC pre-made selections of different encryption algorithms. The attacker can't gain the algorithms that were used via a logger because they are never selected again. It's important to use thousands of available hashing algorithms, even if they are really simple. 1000 possible combinations of hashing algorithms would make it almost impossible to only hash the key-file. Even if only one or two hashing algorithms are used so VCs processing doesn't take too long, with that many different possibilities it is easier and faster for the attacker to copy the whole key-file.
VC should also not just use 1MB but what is technically possible for the device to process, something like 1 to 10% of the file depending on the overall size. Size select-able by the user.
Currently if I understand it correctly, when using a large key-file VC only uses the first MB of the file together with a hash. A standardized hash however can be recreated for a file and the first MB is easy to copy. Making it possible to fake large key-files.
I've experimented with up to 10GB worth of 1MB keys. It is possible to use that many keys on a VC volume, however when used from usb/sdcard it becomes too slow for VC to be of any use and it tends to crash VC. When used on a standard HDD with sata connection VC is able to process the 10GB of keys in ~2 minutes without crashing.
The reason to use bigger keys is simple: When a system is compromised a user only needs to use the 1MB key together with any keyboard or mouse input once for the attacker to gain access to a VC volume. It is easily stolen with modern internet connections and the attacker can slowly copy the VC volume without the user decrypting it. However a large enough key would prohibit the attacker to gain it quickly. The attacker would need to copy the key over a long period of time too. When the key-file is changed frequently on a secure offline system the attacker can't access the VC volume without gaining physical access to the key-file. However using keys that big has its limitations as my 10GB experiment has shown.
Thus my idea is to implement different modifiable hashing algorithms that only use part of the large key-file but force the attacker to gain a copy of the whole key-file.
Desired behavior
The user would select multiple of thousands of pre-selectable algorithms, where the order also changes the results, to hash the file/process the "1MB of data". "The user stacks the algorithms dynamically as if using multiple key files." Not like VC pre-made selections of different encryption algorithms. The attacker can't gain the algorithms that were used via a logger because they are never selected again. It's important to use thousands of available hashing algorithms, even if they are really simple. 1000 possible combinations of hashing algorithms would make it almost impossible to only hash the key-file. Even if only one or two hashing algorithms are used so VCs processing doesn't take too long, with that many different possibilities it is easier and faster for the attacker to copy the whole key-file.
VC should also not just use 1MB but what is technically possible for the device to process, something like 1 to 10% of the file depending on the overall size. Size select-able by the user.