Specify more than 1 keyfile.

[dillfrescott]

This could be very useful, as you would need more than 1 keyfile to successfully decrypt the file. Meaning you could give a keyfile out to multiple people and it would require those people to all submit their files together to decrypt.

[dillfrescott]

I suppose a way around this would be to use a keyfile and then split the file up with 7zip. But that seems like a roundabout way to accomplish it.

[samuel-lucas6]

It's an interesting idea that I've thought about before. Trouble is the generic way of handling keyfiles doesn't work with multiple keyfiles because they'd have to be specified in the same order, which is a recipe for disaster. I'm also not sure keyfiles should really be encouraged anyway because they're harder to keep track of/more likely to be lost compared to passwords, get stored unencrypted on disk, etc.

If you're only talking about two people, then the better solution would probably be one person has a password and the other has the keyfile. As you say, splitting a keyfile also works, but I agree it's more fiddly. Whoever chooses/generates the keyfile can just keep the entire thing, even unwittingly since to properly erase files from a disk is extremely difficult.

This really comes down to what's the use case and how many people are going to want this? Aside from storing different keyfiles on different memory sticks, which would frankly be overkill for most people, I don't see much use for this. Using a keyfile alongside a password is already arguably overkill if the password is strong and you're storing the password appropriately.

[dillfrescott]

Gotcha. My most overkill encryption method is using a veracrypt container that uses serpent encryption inside of twofish inside of AES256 with an extra high personal iteration multiplier, meaning that either you brute force the password which takes about a minute or two per try on a high end computer, or you have to break the AES key > Twofish key > and then the Serpent key. lol

[samuel-lucas6]

I think that's above and beyond the definition of overkill. Whilst cascade encryption is a cool concept, it's solving a problem that doesn't really exist unless the goal is to store data far beyond your lifetime or something. The speed decrease makes that sort of setup impractical to the point that you might engage in worse security practices because you get fed up of the hassle.

[hakavlad]

handling keyfiles doesn't work with multiple keyfiles because they'd have to be specified in the same order

they'd have to be specified in the same order

The keyfiles can be specified in any order, then digests can be added to the list, then the digests can be sorted, and then a digest of the sorted digests can be obtained. What do you think of this scheme? With this scheme, you can enter keyfiles in any order.

keyfile_digest_list.sort()

h = blake2b()

for i in keyfile_digest_list:
    h.update(i)

final_keyfile_key = h.digest()

[samuel-lucas6]

I see what you're saying. Another approach is to XOR to get one value. However, I'm not convinced adding support for multiple keyfiles is worth the complexity. Part of the problem now is that pre-shared keys are specified using the same option as keyfiles.

[hakavlad]

Another approach is to XOR to get one value

The disadvantage of this approach: XORing of identical digests gives zeroes. In my proposed scheme, identical files can appear several times. This is a more universal approach.

[hakavlad]

What about adding entire directories as keyfiles?

[hakavlad]

if any file is modified, you won't be able to decrypt.

The use case also lies in this: to be able to invalidate a key by damaging 1 byte, or in negation schemes to say: this is a real key file. Is it not suitable? Strange, maybe it was damaged!

[samuel-lucas6]

I'm not quite sure what you mean.

[hakavlad]

The ability to use multiple files and directories as keys makes it possible to plausibly deny the possibility of decryption: you can tell the attacker that if the specified set of key files and directories does not pass authentication, then at least one of the key files has been changed or damaged, and it is impossible to decrypt the ciphertext (this is useful to prevent the possibility of decryption when it is better to lose data than to reveal it).

Also, support for multiple key files/directories makes it easier to make encrypted files undecryptable.

The ability to have many key files means the ability to damage the keys without an attacker noticing, or to claim that the keys were damaged by accident.

Support for multiple key files and directories is +1 to plausible deniability (if the attacker is sure that your random data contains a message).

[samuel-lucas6]

The ability to have many key files means the ability to damage the keys without an attacker noticing, or to claim that the keys were damaged by accident.

I suppose, but it's likely still possible to detect via forensics. Modifying one keyfile makes encrypted files just as undecryptable.

[hakavlad]

possible to detect via forensics

But the attacker is not always the state.

Modifying one keyfile makes encrypted files just as undecryptable.

This is exactly what we need: ease of destroying keys.