Encrypting data with two separate keys
I would say that all of them are valid options, with the security differences they might have negligible. So I focused on other properties of the approaches:
Option 1: XOR
I think the most interesting property here is the malleability that gives us the XOR function. If I'm a keyholder under this chema, I could give n keys which XOR to my half to my n children, and their keys combined will be as good as mine.
Similarly, it the requisites went from 2-people to 3-people (such as including a new partner in the business), they could each provide a random half-key to combine with their now-new-half.
It also has the property of being commutative. This is silly from a cryptographic and technological point of view, but if you are giving two keys to two people, one might think to be more important to have the &quot;first&quot; key, or feel hurted on their big ego for only being given the &quot;second&quot; key. Here, both keys are equal rank, their order doesn't matter at all.
Option 2: KDF
This woud be similar to the above, but not allowing you such malleability (which you may consider good or bad).
You may want to combine them in lexicographical order, so that it doesn't matter the order in which they are provided. For the reasons provided above and less user errors by not being possible to provide them in an order it doesn't work.
Option 3: Encrypt twice
This option would be slower, although just doing two layers of encryption would not be a noticeable hit. You should perhaps be careful to do both things &quot;at once&quot; or with pipes, not using intermediate temporary files that might end up recovered. Although you would still have the same concern with the final decrypted item.
This solution would be subject to a Meet-in-the-middle attack. I don't think this would actually be a realistic concern, since you would still need to break AES.
A new keyholder could be added by encrypting the existing ciphertext with the new key.
Same comment as above about setting an order would be applicable.
Option 4: Split the key in two
Just for completeness, I'm adding the trivial solution of, instead of giving 128 or 256 bit keys to each of them, directly providing half the key (64/128 bit keys) to each one. This means each key is half the size, with no benefit over the other solutions, so I wouldn't recommend it.