Public Key without its Private Key ?

[kidehen]

In looking at the ActivityStream rendition of my profile page (i.e., "application/activity+json" content-type), I noticed a PEM representation of a Public Key.

-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxZR7AKCk3hQbeyQju/bN t+U1oTQdW66B2R8XFNWmUk3HAHWFEbGd/M1YgukY4xyA5kkqJ5xlS1NIpA4sWtnw csT2vDWoettbIcr3oNFhJS4yGCO4tXawYp1k6paYUMB9r4Aabz7gcifh+6dnKxqq ZIdb7cTR9PRt6JwNPih/tgVrItnrahce5IH9Za/DLOb6KWn7n2qjrjgJJ/f+oI1x SNZHTP8h5y4Y8XJEXflGIw6UdwaD28RRHaAqMLv6z1k9pYGsMtSqcdgZhldFbId2 8+553pcAvKXVHARfkoOm5d2C7AngPpguT0nDnvNENOXvLc5dShOjFk2eKXzHOaQc rQIDAQAB
-----END PUBLIC KEY-----

I assume Mastodon currently takes custody of the matching Private Key, and if so, why?

[trwnh]

the private key is used by the mastodon server to sign http requests on your behalf

[kidehen]

Okay, but I am not the owner of the keypair which is confusing based on how its presented in my ActivityStream data.

Has anyone considered the following regarding the private key?

1. Making it optionally available to users
2. Allowing users provider their own keys via secure PEM or PKCS#12 files
3. Use of HTTPS as another option for Identity Authenticity alongside the current <link rel="me" ../> approach

Putting items 1&2 aside, item 3 is a low cost high value enhancement re identity authenticity that uses existing open standards for PKI.

[nightpool]

No, Mastodon cannot currently provide private keys to users for security reasons. While each private key can only be used to sign posts for a single account, there are ID namespace concerns and DOS attacks that are currently insurmountable.

[melvincarvalho]

The security weakness is, in fact, that the server or anyone with access to the server, has access to all the user's private keys

This would allow any employee, or hacker, to impersonate any user forever, and read direct or encrypted messages

I very much appreciate that mastodon is a system that works. But in future, it could be a goal to allow users to take ownership of their private keys, in some way

I started building something in this vein here:

https://microfed.org/

It's just a stub, but maybe provides some food for thought, for a pattern of server controlled identity alongside sovereign identity

[kidehen]

Yes, a single point of vulnerability never works -- period.

It would be prudent for this system to provide users with full control over their keys. Or at the very least, provide that as an option.

[nightpool]

It is not possible for any ActivityPub instance to currently provide users with the private keys used to sign server-to-server posts securely, because all major implementations currently only use a same-origin check to validate IDs created by those keys. This creates several novel vulnerabilities where User A on mastodon.social could use a private key hosted on mastodon.social to e.g. block or suppress the activities from User B on mastodon.social (these are not trivial vulnerabilities, due to the precise timing required, but they're possible)

Obviously, this is not an issue if you run your own instance, since there's no other user B to attack. If you're worried about "single points of failure", I would recommend going that route, where all of your private keys are securely yours and you can use them for whatever you want.

If your goal is to allow users to communicate securely, then I wouldn't suggest reusing the private keys used for communicating between servers, and I would suggest instead having a separate set of keys specifically intended for e2e encryption that the server doesn't even have access to (as implemented in the Mastodon backend, but not yet implemented in the client apps)