User Encryption for LibreChat messages

[ogipogi]

Hi @danny-avila

We had exactly the same need in our company.
#3628

The main reason was to lower the barrier for users who didn't want their chat conversations to be readable by admins.

So we implemented it in our fork - if you want, I can create a PR - let me know.
https://youtu.be/VA8Ij811B6I

• Encryption key stored in local storage
• Encryption key derived from a pw
• Works on multiple browser/devices if the same encryption key is set
• Meili Search is deactivated if encryption is on
• All messages get en- or decrypted when toggling

You are doing a great job with LibreChat - thank you very much!

Merry Christmas :)

[ogipogi]

Update:
Hi @danny-avila, here the changes we did at our fork:
ogipogi@107a7b2

[SamirSaidani]

The messages must be decrypted before being sent to the AI models, which means an admin could ultimately see these messages, right?

[ogipogi]

Hi @SamirSaidani
The term "e2e" might have been a bit misleading. Our goal is to prevent messages from being stored in clear text in the database (MongoDB).

The encryption and decryption process occurs on the backend using a user-defined encryption key. This approach differs from true end-to-end encryption, where encryption takes place on the client side.

You asked if this means an admin could ultimately see these messages. In my opinion, it depends on how the deployment and logging are configured. In our setup, we don’t log any message content, so while we don’t have true client end-to-end encryption, our admin cannot read the logs without redeploying the app.

For our corporate deployment of LibreChat, this security model provides a satisfactory balance between usability and data protection, meeting our organization's requirements.

I removed the e2e part from the label
main...ogipogi:LibreChat:feature-e2e-messasge-encryption

[SamirSaidani]

My concern is that this PR could introduce attack vectors for the server.
Your contribution is very nice and we have to find a solution raised by users, but including this PR means taking into account hundreds of organizations and the consequences on them.

I reviewed the code and I think it can be improved to mitigate the attack :

• lack of salting, vulnerable to rainbow table attacks, just a pinch of salt would improve significantly the PR 😊
• key strengthening: key derivation functions like PBKDF2, Argon2, or bcrypt are designed to make brute-force attacks slower, sha256 does not provide this protection.

I also think there could be another approach to explore, which would involve using a TLS connection between the client and the OpenAI server, with LibreChat acting as a proxy between the two. It's just a rough idea to explore.

[SamirSaidani]

After some thought, achieving a true end-to-end encryption experience would require giving the client more responsibility in managing messages, meaning moving much of the current logic from the server to the client. This would involve a significant refactor of the current architecture. On the other hand, it could be beneficial for a more privacy-focused approach. Is this something you're interested in @danny-avila ?

[ogipogi]

Dear @SamirSaidani ,

I appreciate your security review, but I want to clarify the scope and intention of this implementation:

1. Corporate Use Case This feature was specifically developed for our corporate environment where:

• We need to lower the barrier for users concerned about admin access
• Full message encryption is sufficient for our security requirements
• We don't log message content in our deployment

2. Current Implementation
   User -> JWT authenticated API -> Server-side encryption -> Storage
   While not true E2E encryption, this approach:

• Meets our specific corporate needs
• Provides practical security for our use case
• Balances usability with security requirements

3. Regarding Your Concerns You raise valid technical points about potential improvements (salting, key strengthening). However, for our specific use case, the current implementation provides adequate security since:

• JWT authentication ensures only authorized access
• Each user controls their encryption key
• Admins cannot read user messages accessing to MongoDB

4. Implementation Status This PR is currently a proof of concept to gauge interest in message encryption features:

• Polish and unit tests are still pending
• We're evaluating whether to complete the implementation in our fork
• If message encryption becomes a planned LibreChat feature, we might wait and align with the official implementation
• Otherwise, we'll finish our implementation independently, which works well for our needs

This Implementation wasn't intended as a complete E2E encryption solution for LibreChat - it's a practical feature for corporate deployments with similar requirements to ours. The E2E encryption discussion would indeed be better suited for a separate thread, as it involves different architectural considerations and trade-offs.

@danny-avila might have additional concerns or considerations not mentioned here that could help improve this implementation. I'd be interested in hearing these perspectives to ensure we're not overlooking important aspects.