Proposal: Make primary user identity a public/private keypair

[ghost]

I'll just leave this here. There are some notes I quickly jotted into my phone. Let me know if there is interest in this, and I'll type something up that more closely resembles actual prose.

Related-To: #203 #63 #65

---

• Replace user/pass with public key identity.

• Every user is their key fingerprint.

• Key is optionally and by default kept on the server, passphrased.

• Client keeps a local copy of the key, if possible, allowing for account recovery in case server loses the key blob.

• Server never sees the passphrase - private key is downloaded from the server by the client, decrypted with the passphrase, and used to sign in. (*Need some mechanism that prevents downloading all key blobs from HS, possibly use an alternative s2k algorithm on the passphrase to unlock download.)

• Also clears the way for true account migration. (Link in spec leading nowhere #712)

• On joining a room, send a BIND_HS message to bind the decentralized ID to the homeserver and local identity.

• On migrating an account, the same BIND_HS can be sent to change the homeserver.

• A given decentralized ID can only exist on one HS at a time (per room).

• The e2e keys could be signed with the account key, providing a single identity for all a user's devices, including future devices.

[aerusso]

I'm extremely new to the Matrix community, but I am very excited by how promising it looks. As I was trying to get signed up, I was rather surprised that the primary identifier for an individual was not a public/private keypair. I've thought about this a bit---and looked at many of the other referenced discussions. There seems to be momentum in at least changing some elements of how identifiers work (e.g., element-hq/element-web/issues/5336). I think it'd be a real shame to follow through on these proposals without baking public key cryptography into Matrix identities. I think a chain-of-trust model should at least be considered.

@Matrixcoffee's suggestion seems to be the right idea in spirit, but I'd also like to suggest a slight modification that should provide for significant additional security:

1. As above, the public key is the ultimate identity. A given HS will provide a map from @user_ids to ^public-key (or ~public_key).
2. Clients will trust on first sight a presented mapping to public key. This makes explicit the role of the Matrix network as public key repository. It also makes the protocol resistant to future compromise of any HS. [Furthermore, these preferences could be kept stored on your own HS, signed by the device key that first saw it. You could transfer these among devices, and verify that your HS was not tampering with these settings.]
3. To allow users to keep complete control over the very sensitive private key, one could generate the private key locally, and submit the public key to your HS. Each device key would then have to be submitted to the machine with the private key to be signed, creating a chain of trust to your ultimate identity, just like PGP identities. To make this process less painful, a time-limited intermediate key could be issued to the HS to allow for signing of new devices---this could be kept encrypted with your password, as @Matrixcoffee suggests. Alternatively, for people who really trust their HS, the private key itself could be left on the server. (This would be mostly equivalent to what is done now).

This approach provides the flexibility for users to decide how much security they want, the amount of convenience they are willing to sacrifice for it, and whom precisely they trust. The level of authentication provided in any e2e encrypted conversation could be presented in clients (e.g., was an intermediate key used to authenticate this e2e conversation). Then, people could then still use ephemeral sign-in techniques (like web-clients) without having to compromise security when they are using more well-trusted devices. It also opens the door for single-use passwords for time-limited conversations on poorly-trusted devices without permanently compromising one's Matrix identity.

[ara4n]

@aerusso we're experimenting with this right now as part of GDPR work (matrix-org/synapse#1941 (comment)). Amusingly we're even looking at introducing the same sigils - (~ for user IDs, and ^ for per-user-per-room IDs). The spec proposal is still a bit up in the air; we're trying to work out if we really need to do this as part of mxid anonymisation for GDPR first, but expect it to be shared shortly.

[ara4n]

gory details: https://docs.google.com/document/d/1ni4LnC_vafX4h4K4sYNpmccS7QeHEFpAcYcbLS-J21Q/edit

[ara4n]

i think this has basically been superceded by matrix-org/matrix-spec-proposals#1228 and matrix-org/matrix-spec-proposals#3793. huge thanks to @Matrixcoffee for kicking off the discussion and being prescient by a few years tho :D Unsure whether to keep this open until matrix-org/matrix-spec-proposals#1228 and matrix-org/matrix-spec-proposals#3793 land or close as a dup...

[ptman]

IIRC SILC used keypairs for identity as well

[richvdh]

I'm closing this as a dup. It's certainly a direction we want to go in, but hammering out the details is going to take a while.