[GH-ISSUE #163] [Feature request] "E2E" encryption of key user data fields

kerem commented

2026-03-14 10:22:13 +03:00

Owner

Originally created by @xanoni on GitHub (Jun 1, 2021).
Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/163

It would be great if the user could define a symmetric, client-side encryption key that the browser would then use to en-/decrypt certain user-provided data fields. I'm thinking about data that the server never needs to see to operate, such as the user-provided alias descriptions.

Even more advanced would be an asymmetric encryption scheme, in which the server could persist certain analytical information after encrypting it with the user's public key. Things that are generated on the server, but that only the user/browser needs to be able to see. E.g., timestamp of last email received by alias.

The above would allow for more logging and potentially better user experience without sacrificing security and privacy. I'm aware that a full implementation of this would be a lot of effort (look at ProtonMail), but wanted to get the discussion started. I think a proof of concept (e.g., symmetric encryption of alias descriptions) could be relatively easy to do.

Originally created by @xanoni on GitHub (Jun 1, 2021). Original GitHub issue: https://github.com/anonaddy/anonaddy/issues/163 It would be great if the user could define a symmetric, client-side encryption key that the browser would then use to en-/decrypt certain user-provided data fields. I'm thinking about data that the server never needs to see to operate, such as the user-provided alias descriptions. Even more advanced would be an asymmetric encryption scheme, in which the server could persist certain analytical information after encrypting it with the user's public key. Things that are generated on the server, but that only the user/browser needs to be able to see. E.g., timestamp of last email received by alias. The above would allow for more logging and potentially better user experience without sacrificing security and privacy. I'm aware that a full implementation of this would be a lot of effort (look at ProtonMail), but wanted to get the discussion started. I think a proof of concept (e.g., symmetric encryption of alias descriptions) could be relatively easy to do.

kerem closed this issue

2026-03-14 10:22:18 +03:00

kerem commented

2026-03-14 10:22:24 +03:00

Author

Owner

@willbrowningme commented on GitHub (Jun 3, 2021):

This is a good idea and something that would be nice to add.

I think adding client-side encryption similar to what BitWarden uses - https://bitwarden.com/help/crypto.html might take a bit of work to integrate into the existing setup though.

Also with BitWarden the server receives the master password hash whereas with AnonAddy the password in hashed on the server and then compared to the database password hash. So in order for it to be fully "zero-knowledge" passwords would need to be salted and hashed on the client side instead which I think would be quite complicated to migrate to.

This is an interesting article going into more detail on BitWarden's crypto and how it could be improved - https://dchest.com/2020/05/25/improving-storage-of-password-encrypted-secrets-in-end-to-end-encrypted-apps/

@willbrowningme commented on GitHub (Jun 3, 2021): This is a good idea and something that would be nice to add. I think adding client-side encryption similar to what BitWarden uses - https://bitwarden.com/help/crypto.html might take a bit of work to integrate into the existing setup though. Also with BitWarden the server receives the master password hash whereas with AnonAddy the password in hashed on the server and then compared to the database password hash. So in order for it to be fully "zero-knowledge" passwords would need to be salted and hashed on the client side instead which I think would be quite complicated to migrate to. This is an interesting article going into more detail on BitWarden's crypto and how it could be improved - https://dchest.com/2020/05/25/improving-storage-of-password-encrypted-secrets-in-end-to-end-encrypted-apps/

kerem commented

2026-03-14 10:22:29 +03:00

Author

Owner

@xanoni commented on GitHub (Jun 3, 2021):

EDIT: Just looked at your link. Good points, but obviously it's still much better than no encryption, and you could always use a second password.

The complexity depends on the use case. If you find use cases where you can keep everything on the client side (and then just upload the encrypted content to the server), then you don't have much complexity. You could achieve the same with a browser extension that's totally independent of AnonAddy. (And indeed there are some that automatically encrypt strings in HTML forms when you hit submit and decrypt automatically when you come back to look at the content).

The question is, how do you avoid having 2 separate passwords for people who think that this is not good UX (I'd be fine with it). I remember that ProtonMail had 2 passwords in the past (one for login and one for local data decryption), but they designed an approach to hide the encryption key behind the login key.

In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password.

Source: https://protonmail.com/blog/encrypted_email_authentication/

Example use case:
Today:
User enters alias description ==> browser encrypts information with symmetric password known to user ==> browser sends encrypted data to server ==> server persists data

Later today:
User goes to AnonAddy website ==> server sends encrypted alias description to user ==> browser decrypts string with symmetric password and displays it

@xanoni commented on GitHub (Jun 3, 2021): EDIT: Just looked at your link. Good points, but obviously it's still much better than no encryption, and you could always use a second password. The complexity depends on the use case. If you find use cases where you can keep everything on the client side (and then just upload the encrypted content to the server), then you don't have much complexity. You could achieve the same with a browser extension that's totally independent of AnonAddy. (And indeed there are some that automatically encrypt strings in HTML forms when you hit submit and decrypt automatically when you come back to look at the content). The question is, how do you avoid having 2 separate passwords for people who think that this is not good UX (I'd be fine with it). I remember that ProtonMail had 2 passwords in the past (one for login and one for local data decryption), but they designed an approach to hide the encryption key behind the login key. > In ProtonMail’s one-password mode, the mailbox password is derived from the login password via a one-way cryptographic password hash. The input to this hash includes a salt provided by the server on login but not stored in the client. In this way, compromise of the mailbox password does not automatically lead to compromise of the login password. Source: https://protonmail.com/blog/encrypted_email_authentication/ **Example use case:** _Today:_ User enters alias description ==> browser encrypts information with symmetric password known to user ==> browser sends encrypted data to server ==> server persists data _Later today:_ User goes to AnonAddy website ==> server sends encrypted alias description to user ==> browser decrypts string with symmetric password and displays it

kerem commented

2026-03-14 10:22:34 +03:00

Author

Owner

@willbrowningme commented on GitHub (Jun 8, 2021):

Yes, I agree and understand your points. I'll have to do more digging to see if there would be an easy way to do this but can't promise I'll have time to work on it any time soon.

There is already encryption for recipient emails, descriptions etc. in the database but it is server-side encryption and not client-side. But it is still an extra layer of protection in the event of a database leak.

@willbrowningme commented on GitHub (Jun 8, 2021): Yes, I agree and understand your points. I'll have to do more digging to see if there would be an easy way to do this but can't promise I'll have time to work on it any time soon. There is already encryption for recipient emails, descriptions etc. in the database but it is server-side encryption and not client-side. But it is still an extra layer of protection in the event of a database leak.

kerem commented

2026-03-14 10:22:39 +03:00

Author

Owner

@xanoni commented on GitHub (Jun 8, 2021):

Yes, I agree and understand your points. I'll have to do more digging to see if there would be an easy way to do this but can't promise I'll have time to work on it any time soon.

I understand how much work this is and I don't think this is urgently needed, assuming AnonAddy doesn't start tracking more user data and storing it centrally. I just wanted to start a discussion thread, so people can get this into the backs of their minds for when the right time comes.

@xanoni commented on GitHub (Jun 8, 2021): > Yes, I agree and understand your points. I'll have to do more digging to see if there would be an easy way to do this but can't promise I'll have time to work on it any time soon. I understand how much work this is and I don't think this is urgently needed, assuming AnonAddy doesn't start tracking more user data and storing it centrally. I just wanted to start a discussion thread, so people can get this into the backs of their minds for when the right time comes.

kerem referenced this issue

2026-03-14 11:38:58 +03:00

[GH-ISSUE #727] HELP! I can't change my regular email address #1073

Rows
Columns

[GH-ISSUE #163] [Feature request] "E2E" encryption of key user data fields #727