End-to-End Encryption GDPR Problems

[deleted]

tankerkiller125 that's correct. If they do not hold the keys to decrypt, then it's not possible. AWS for example of one such vendor who takes this approach. You lose the key, you lost access to your machines.

Taking this route allows the host to exonerate themselves in the sense that they cannot be considered in scope when they possess no means of decrypting the content and can demonstrate that as part of their controls. This world also be covered by SOC 2

luceos

Yalfoosh To clarify, it's a combination of Article 12 and 15. 15 gives users the right to ask for their data. 12 forces you to provide that data,

With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?

PS. I have no idea whether data storage was previously discussed 🙈

[deleted]

luceos With this kind of e2e isn't data then stored only at the client level and thus you as a forum owner are not the data processor of this PII and user data to begin with?

Yes. You can't be a custodian of data you do not control

[deleted]

Just to throw this in here, this is how political the GDPR can be as soon as you make personalised data from a home environment and then make it available to a wider audience via social media without consent

BBC News - Grandmother ordered to delete Facebook photos under GDPR
https://www.bbc.co.uk/news/technology-52758787

Kyrne

Might help to chime in on some of the specifics of the encryption implementation.

At the current state, admins will be completely unable to decrypt messages. The private keys for each user will be stored on the server but will be AES-256-GCM encrypted with the user's password ran through PBKDF2 with 12800 iterations to stretch it to 256 bits. The actual keys to decrypt messages are double ratchet keys, meaning they change after each use. If a hacker or admin managed to get ahold of one of these keys, they'd only be able to decrypt 1 message.

Double ratchet creates a problem with reading old messages however. Once a message is read, it is simply encrypted with that same stretched password. If a user loses access to their password, he will lose access to previous messages as well.

Any admin of Flarum or any other website could conceivably steal any of their user's passwords by using bad JS code. This could be mitigated in a few ways but makes the user experience significantly worse (having to export and manually keep track of keys).

JS is at the moment is an inherently insecure programming language, I am taking as many steps as possible in the extension to prevent tampering by any party (including the admin) and I will make these steps clear in the final version. But once the code leaves my computer there isn't a lot I can do to JS to secure it from a bad admin.

[deleted]

Kyrne there's a couple of questions that arise from this methodology. JS isn't secure enough to guarantee maximum protection possible without the risk of tamper via inject and this creates an immediate security issue which on the face of it is likely insurmountable.

If you consider how WordPress handles this from a plugin perspective, it is not encrypted. My question here would be why we need to encrypt messages in the first place in a forum. Based on the above, there should be an option to enable or disable depending on your preference. The messages are still private, but not encrypted and controlled by permissions instead.

Yalfoosh

Kyrne But the user could hypothetically read their old messages if they reverted to an old password, right?

Kyrne

[deleted] the JS code of the ext is verified using Subresource integrity which is a feature in JS. This means that as long as you are using https, the implementation is secure, no one but the site admin can tamper with the js code.

It's important to think about how apple could totally read your iMessages if they want, they just need to get your password which again is very possible.

The only way in the world to have 100% secure true end to end encryption is decentralized peer to peer messaging (the platform doesn't have control of the client). This is something no popular encrypted messaging service can provide

[deleted]

Kyrne that's correct of course in the sense of decentralised messaging, but what about the ability to disable or enable the encryption ? Requesting users to control their own keys is asking for it.

Kyrne

[deleted] The current system doesn't require users to manage their keys. My current plan is to release the ext as is, encryption required with little to no settings. After that, I will incrementally add features in order of popularity.

Kyrne

Yalfoosh that's correct. This scenario is only if they forget their old password, if they change it while logged in the messages and keys and theoretically be decrypted and then re encrypted. This won't be a feature at launch.

Yalfoosh

Kyrne Oooof, this could potentially be a DDoS gateway. I guess when the feature comes we should limit the frequency of password changes, then.

Kyrne

Yalfoosh not really, since the client only knows the password (in theory) all the encryption and changes are done on client side then sent to the server. The only thing the server would do on password change is update 2 or 3 rows on the MySQL table.

Yalfoosh

Kyrne Ahh, I was under the impression that you decrypt and encrypt all the messages, my bad.

« Previous Page