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...
-
@hazelnoot further cursed facts:
1. The AP specs have extremely little to say about handling signing keys as it is
2. Different URIs can point to the same resource. A universal shared key pair can still have unique-per-actor IDsAnyway, I hate this idea. It makes the already dubious actor blocking mechanisms completely broken. I mean, it's already broken, but it's worse if this behavior actually gets implemented in practice
-
Jenniferplusplusreplied to Jenniferplusplus on last edited by
@hazelnoot the closest we come to a federated authentication mechanism is to prove we have access to specific private keys. That means enforcing a block in any meaningful way requires deny listing that key.
-
@jenniferplusplus @hazelnoot funnily enough, Gleason already does / is doing exactly this, because he complains that storing a public/private keypair per known account uses too much storage.
He had this blog post complaining about key storage that I saw a little while ago via someone.
-
@thisismissem @hazelnoot yeah, I saw that. It's why I had this response ready to go. I didn't particularly want to index and map public keys to blocks, but here we are
-
Jenniferplusplusreplied to Jenniferplusplus on last edited by
@thisismissem @hazelnoot also I did some math and it's likely that every non-threads fediverse account's private keys totals less than 50gb of disk. Much less if we can get mastodon to support elliptic curve algorithms
-
Hrefna (DHC)replied to Jenniferplusplus on last edited by
That matches my fermi estimate as well (I came in at 32 GiB, but in the same neighborhood).
Given that my cellphone is capable of hosting that with good performance, I am dubious of the value of losing that granularity in order to save tens of gigabytes.
-
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.
