Facebook/Google OAuth - need a constant string for E2EE

• The clients can use Google and Facebook OAuth for authentication
• I need to implement a chat application where the messages are end-to-end encrypted
• When the user changes device, the client should be able to decrypt the messages downloaded from the server

---

Roughly the end-to-end encryption works like this:

1. Client generates an asymmetric key pair
2. Client uploads the public key to the server
3. Client using a KDF derives the Y key from a string X
4. Client encrypts the private key with the key Y
5. Client uploads the encrypted private key to the server
6. If Alice and Bob wants to communicate, they request the respective
   public key from the server and validates manually each other on the client side
7. Alice generates a random string and encrypts it with Bob’s public key
   then sends it to Bob through the server
8. Bob doing the same
9. Now Alice and Bob creates the shared key from the two random strings
10. Alice and Bob encrypts the shared key with the personal Y and uploads it to the server
11. Alice and Bob now can start the communication using the shared key

---

If a user wants to change device

1. User enters the string X on the client
2. Client creates Y and Z where Y=KDF(X, salt1) and Z=hash1(X, salt2)
3. Client sends Z, salt1, salt2 and the user identifier to the server
4. Server creates H where H=encrypt(hash2(Z, salt3), pepper)
5. Server authenticates the user if H is valid
6. The authenticated user downloads all of the encrypted messages, encrypted shared keys and the encrypted private key from the server
7. Client decrypts the messages using Y

---

Problem: If a user login via OAuth I have no X to use in the KDF to get the Y, because the token I get from OAuth isn’t constant like a password

Possible solutions I found:

• Generate a random password on client side and send it to the user in email or any other communication channel. I think this is pretty bad because the users are probably not using OAuth to receive additional emails about passwords and stuffs
• Just ignore the fact that the users can change devices

---

Both of these approaches are bad so I’m kinda stuck at this point