# Using XOR to derive a data key for ECIES

I have been thinking about a rather simple enhancement for (EC)IES / RSA-KEM. The scheme would allow you to encrypt data while the calculation of the session / data key can be performed afterwards or in parallel. It would also allow you to encrypt for multiple recipients.

Anyway, the scheme would simply be:

1. Generate a (random) symmetric key: $$K_d$$;
2. Encrypt data with key $$K_d$$ using a symmetric cipher, resulting in $$C$$;
3. Generate an ephemeral key pair with public key $$\widetilde{P}$$;
4. For each recipient enumerated by $$i$$:
1. Calculate a session key $$K_i$$ by performing key agreement with a static public key of the receiver (followed by a KDF);
2. Perform $$A_i = K_i \oplus K_d$$;
3. The messages consist of a quad $$(i, A_i, \widetilde{P}, C)$$ where the $$i$$ is just used to indicate the recipient.

To decrypt you would simply perform the key agreement again, followed by $$K_d = K_i \oplus A_i$$. For RSA-KEM the ephemeral key pair derivation is not required, and $$\widetilde{P}$$ is replaced by the result of the RSA-KEM operation with the public key of the receiver.

This seems to be a specific version of a simple Multi-Recipient Symmetric Encryption Scheme using Secret Sharing combined with (EC)IES or RSA-KEM. Obviously you'd have to store the $$A_i$$ values with the ciphertext, so that is a disadvantage compared with the normal ECIES approach.

Are there any particular problems with above approach? Are there more secure / flexible / efficient schemes to do the same?

• What bothers me intuitively with this scheme is that the symmetric key may no longer be random as it would be when it was a direct output of a KDF given the afterwards combination with an unauthenticated value. But I can't translate that into a an attack right now nor come up with reasoning why it won't potentially be a problem. – SEJPM Jul 24 '20 at 10:07
• On the other hand, ECIES or RSA-KEM based schemes are not authenticated anyway; if you want authenticated then it is possible to add a signature. I don't see anything that would make it less secure than unauthenticated ECIES - but I might be mistaken in that regard so please use this as attack vector! – Maarten Bodewes Jul 24 '20 at 10:09
• I have the exact same question. In SEC1 this is called "XOR encryption scheme", but the spec requires also using a MAC. Could you avoid this MAC is if you use authenticated encryption with the key being encrypted anyway? – Conrado Jul 24 '20 at 12:08
• I think my scheme is more XOR encryption (of a secret key, so key wrapping) combined with a symmetric cipher. As for the MAC, no indications are given why it is even needed in SEC1. Of course with ECB / CBC there are padding & plaintext oracle attacks to deal with. But remember: any attacker can encrypt any ciphertext with ECIES. So a MAC can certainly not be seen as a way to replace a signature. Once you have a signature, you certainly don't need a MAC anymore if you ask me. – Maarten Bodewes Jul 24 '20 at 12:56
• Heh, if I just see it as key wrapping I can probably prove that it is secure. And in that case I might as well use AES-SIV. Before that I looked at it as some kind of derivation. Funny what you get by just talking about a solution. – Maarten Bodewes Jul 24 '20 at 12:59

This is not difficult to fix; we don't select a random symmetric key $$K_d$$, instead, we generate a random value $$J$$, and set $$K_d = \text{Hash}(J)$$. Then, in step 4.2, we then instead set $$A_i = K_i \oplus J$$.
For this reason it is probably a good idea to either hash the output of the key so that bit flips will 50% of the output bits on average (poncho's solution). Another way would be to use e.g. AES-SIV instead of XOR to make sure that all the bits of the encrypted key are related. The wrapped key would then be the $$A_i$$ value.