Is throw-away-the-key-encryption allowed under GDPR?

Question

Article 15 of the GDPR says:

The data subject shall have the right to obtain [...] personal data [if it is being "processed"]

Article 4 says that "processing" includes storage.

Therefore, all stored personal data should be available upon request.

Then does GDPR disallow the following scenario?

1. You give me your personal data.
2. I encrypt your personal data using a random encryption key.
3. I store the encrypted data and assign it a random ID for reference.
4. I give you copies of the encryption key and the ID and throw away my copies.
5. You later provide the ID and encryption key to me and ask me to decrypt your data and perform some work with it.

Note a few things:

• Nothing about the encrypted data, encryption keys, IDs, work performed, logs, etc leaves any information which correlates to you. Only your unencrypted personal data does.
• Your personal data still exists the whole time--I'm storing it in encrypted form (has it been anonymized?).
• Your personal data is readily available, if you give me the correct ID and encryption key.

Importantly, I'll never be able to satisfy your request for all your stored personal data. It's technically impossible since I lack anything which correlates it to you, and I don't have any encryption keys. I would only be able to satisfy the request if you gave me all encryption keys and IDs that I have ever sent you.

---

A concrete example:

In order to sign into a website you must have a trusted email address. Email addresses take the form of [email protected], thus they are personal data. You sign in by providing this personal data and clicking a button. Clicking the button stores your encrypted personal data according to the scheme above and then emails you a link containing the reference ID and encryption key. You establish trust by clicking the link, sending the website everything it needs to find and decrypt your personal data. Then the website takes action on your personal data, signing you in. Incidentally, the encrypted personal data is single-use and expires, so it gets deleted after you are signed in or if it gets too old.

I realize the goals of this example could be accomplished a different way. But I hope it helps make the scenario clear.

Answer 1

TL;DR

In theory there's nothing wrong with your method, it's just a way to authenticate the user, and without authentication a user has no right to request anything anyway. But in practice it looks like your method doesn't have a way to deal with situations where users lose or forget their authentication data and want to be able to recover their account. Failing to deal with that in a modern system might be considered an unacceptable bad practice and so be against the GDPR principles of security and privacy by design.

EXTENDED VERSION

I might be wrong or not understand the question correctly, but I don't see how this is different from many other common cases where encryption is not involved. Think about it, you aren't able to give the user their own personal data unless they provide the ID and encryption keys. How is this significantly different from the fact you aren't able to (or rather you should not) show a user their own data unless they provide their own username and password, or they convincingly authenticate themselves in any way?

Just like you can't ask Facebook to show you all the data collected about Donald Trump only by claiming you are Donald Trump, you can't be required to give a user their own data unless they provide the encryption key. It can be seen as your way to authenticate users (among other things).

Edited: multiple IDs/keys

I didn't understand your method involved multiple IDs and keys. In theory, the situation is still the same, only with multiple pieces of data for authentication, like the user had to remember multiple usernames and passwords. Failing to provide all IDs and all keys will result in a partial authentication.

But with such an approach a potential problem becomes more evident: your authentication scheme might be against the GDPR principles of "security and privacy by design and by default". Basically, your methods might be considered bad practice because they fail to deal with the common issue of lost or forgotten passwords. If a user tells you they have lost a USB drive containing all their IDs and keys and they don't have them anymore, what do you do? You can't delete their data because you aren't able to know what their data is, without another way of authenticating. And their data is now at risk, because somebody else might have their IDs and keys. If you had an email address associated with all the user's IDs and data, then you might be able to confirm their identity (for example sending an email with a link) and delete all their data. As you see, things can get pretty complicated, it all depends on the details of your implementation, and just adding or removing one detail might change the whole scenario.