gdpr encryption
What to answer to a GDPR-related user request about his data if it is fully encryped and only the user has the private key for decryption
<p>We wrote an App where private data can be sent from one phone to another phone one by temporarily storing the encrypted data file on our database server. The data file will sit there for less than a few hours, maybe just a few seconds, and will then be deleted. We do not log this. All data (but the usernames) is encrypted (asymmetric cryptography, RSA) and can only be decrypted by the receiving user's private key which never leaves his phone. Therefore, we cannot decrypt it. The users also need to publish their public keys in our database to make this technically work.</p>
<p>We think this is GDPR relevant, since we still can theoretically see on our server who (theoretically identifyableby IP number) is sending data to whom (theoretically identifyable by IP number). We are not sure if the public key is 'private data', since it is technically 'public' per definition.</p>
<p><strong>My question is</strong> what to answer to a user request about his data (which is an important point for GDPR). Are we just providing a print out of the file in its encrypted state? And only in case there is one there at the time of the request? The print out is anyway only readable for this user since the private key never left his phone, and, therefore, we cannot decrypt it. If there are no files, do we just tell so?</p>

<p>A public key is private data - the fact that its a <em>public</em> key is neither here nor there, its data owned by the user and not necessarily in the public domain (I have keypairs for which the public key is only known by myself, for example).</p>
<p>For a subject access request, you must give the user all data you hold about them, subject to certain restrictions laid out in the GDPR - in your case, this would be the IP addresses, public keys, encrypted data and anything else involved in identifying their devices for transferring the files.</p>
<p>You dont need to decrypt the encrypted data if that is something you cannot do or would not normally do in the course of holding it during a transfer - to you, the encrypted data is what you hold.  If you hold the means to decrypt the data, that means (private key for example) would also be included in the subject access requests response, but in your case you say you dont hold that, so there you go.</p>
<p>Remember to include information from things like logs etc in your response.</p>
