Ignoring what the specification recommends, could you build a fedi server that uses a single, shared keypair for all actors? Would that even be able to federate, or are there systems out there using key ID as a unique identifier?#ActivityPub #ActivityS...
-
Jenniferplusplusreplied to Hrefna (DHC) on last edited by
@hrefna @thisismissem @hazelnoot for most instances we're talking about 10s of megabytes or less
-
Hrefna (DHC)replied to Jenniferplusplus on last edited by
ja, as you said: For _every_ non-threads fediverse account's private keys. My estimate on hachyderm came out to under 200 MiB, and for your median server it would be like… under a megabyte.
"I can fit this entire problem on my phone. No not an individual server's problem, that I could fit on my computer from college, _every_ server's problem simultaneously with good performance."
-
@[email protected] could you not implement a denylist based on domain + username?
1. A raw, unverified message comes in.
2. You grab the ID and look up the associated key.
3. The actor key (which is actually the shared key) successfully verifies the object.
4. You introspect the object to get the domain + username pair.
5. You check that against the blocklist.
In fact, I'm like 90% sure this is how Misskey implements blocks. -
@[email protected] @[email protected] to be fair, that's an absolutely absurd amount of space to waste on key management.
-
@hazelnoot But if a set of actors are sharing the same key, the only thing you can know with confidence is that a message came from one of those actors. It can claim to be a specific member of that set all they like, but that's not a claim anyone can trust.
-
@hazelnoot @thisismissem for ~11 million accounts? Seems fine to me. The fediverse is kind of a distributed, primitive key management service when you think about it in these terms.
-
@[email protected] true, but that's the case either way. When the server is responsible for key management, it can also decide which actor gets which key. As long as you let the remote servers tell you which key goes with which actor, then you have to assume that the actors don't actually hold their own keys.
-
@hazelnoot That's true as far as it goes. I would point out that nothing anywhere suggests the server should be in control of the keys. In fact, a lot of the protocol designers really dislike that it shaped up that way in practice. And, I can't imagine a good faith reason for a peer to do that.
-
@[email protected] yeah, that's all fair. No good-faith instance should be messing with keys like that. But it is possible with the Fediverse as it currently functions.
-
@hazelnoot Yeah. My most charitable read of a server doing that is that it's block evasion. And protecting against that block evasion will likely necessarily also prohibit servers that share a private key with all actors.
-
sex in the zitireplied to Jenniferplusplus on last edited by
@jenniferplusplus @hazelnoot I think we currently have to trust the admin doesn't take over accounts currently.
-
@risottobias @jenniferplusplus @hazelnoot The server chooses who gets which key already, and you check by asking it for it via webfinger, so separate keys per actor is relying on trusting the server anyway.
-
@[email protected] @[email protected] @[email protected] exactly. Even if an actor was using C2S with cliient-side keys, the server could still MITM by stripping the signatures and re-signing with its own keys. Fedi has no root-of-trust so it's impossible for a remote server to ever know if this happened.
-
@hazelnoot @KevinMarks @risottobias
That's not necessarily true.Anyway, the question was why shouldn't a server do this. The answer is because it makes many problems worse, and the benefits are tiny.
