Implement end-to-end auditable encryption and new user login methods. #147
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective.
Seamless and auditable E2E encryption using OpenPGP.
Users should only need to store one thing: the high entropy token. With it, users should be able to 1) generate an avatar or login into an existing one 2) encrypt/decrypt/sign/verify messages in the chat conversation in a fully transparent and auditable way using any third party OpenPGP implementation (the frontend component should facilitate the export of armored ASCII for messages and encrypted private key).
The SHA256 hash of the high entropy token (base62, 36 characteres long by default) is used to generate an avatar and for login. The hash of the hash of the token (second hash, computed in the server) is used to generate the Robot nickname and avatar image. Only the first hash of the token is ever sent to the server, yet the token itself should always remain on the client side (must never be share!). The highEntropyToken is used as passphrase of a PGP privateKey, the encrypted privKey is sent for storage to the server. This key will be needed to encrypt/decrypt the chat messages in a fully auditable manner by the user.
While by default the highEntropyToken is 36 characteres long and base62, the user can create it's token however they please. However, the frontend will submit 3 parameters about the token: length, number of unique characters, and count of characters. The token should satisfy >0.7 Shannon entropy and >128 bits of entropy. However, if the user prefers not to be checked for
stupiditylow entropy, the request for robot generation will go through for any token if the 3 parameters are not submitted.For retrocompatibility with existing accounts, although identity reuse is highly not recommended, the old way to login with tokens via GET will still work. But new robot avatars cannot be created this way. The frontend will not support login with the old method. So users will have to login by visiting
/api/user/?token=<token>
endpoint on their browsers.PGP setup:
sha256(highEntropyToken)
. The client sends in the same payload his pubKey and encryptedPrivKey.TODO:
messageId:int, messagePlainText:string, messageArmored:string, time:DateTIme, verified:boolean
messageArmored
in the array (the chat will be full with many "---- BEGIN PGP MESSAGE----(...)"). While the button is not pressed, users only see the list ofmessagePlainText
.