Gregory's ServerThere are some strange, strange things about did:plc that heightens the centralization concerns and, well
I'm not a cryptographer, but some of my good friends are cryptographers, etc etc. I got some... reactions to what is to follow
|
204 comments
 The next concerning thing is that did:plc truncates the hash to just *15 bytes* of entropy. I'm... again I'm not a cryptographer, but why throw away all that delicious entropy? So the did fits in 32 characters? Weird choice, and it means collisions are cheaper  @cwebber is trashing some entropy useful to provide some of the properties @soatok mentions in his post from yesterday? https://soatok.blog/2024/11/21/key-transparency-and-the-right-to-be-forgotten/  This is public information, I don't need to file a CVE to tell you about the truncation of entropy. I am, again, not a cryptographer. Maybe it's fine? I do remember the Debian short IDs fiasco tho https://gwolf.org/2016/06/stop-it-with-those-short-pgp-key-ids.html Why not hold onto all the entropy you can get? DIDs weren't meant to be seen by the user; cryptographic identifiers in general *shouldn't be*, they should be encapsulated in the UI. We'll get to UI stuff in a bit. I just don't understand this decision though, it just seems weird to me but maybe a cryptographer will tell me it's fine, actually At any rate, I continue to not understand it, maybe it's fine, but it did play a part in that "Hijacking Bluesky Identities with a Malleable Deputy" blogpost, which is fascinating and, unlike me, is written by a Real Cryptographer (TM) https://www.da.vidbuchanan.co.uk/blog/hacking-bluesky.html Good post btw One way in which the truncation shows up in that blogpost which I thought was curious is that the attack involved generating a *longer* truncated hash The fix ended up resulting in codifying the hash length: 24 characters, and no longer https://github.com/did-method-plc/did-method-plc/pull/31 There's another thing about that blogpost that caught my attention. I will just quote it: > However, there's one other factor that raises this from "a curiosity" to "a big problem": bsky.social uses the same rotationKeys for every account. > This is an eyebrow-raising decision on its own; apparently the cloud HSM product they use does billing per key, so it would be prohibitively expensive to give each user their own. (I hear they're planning on transitioning from "cloud" to on-premise hosting, so maybe they'll get the chance to give each user their own keypair then?)  Anyway that's the quote and presumably this must be changed. I haven't looked, but I can't imagine they're still doing this today (are they?) but the fact that only one key was ever used in production for expense purposes is a strange decision At any rate, that decision was used to create a kinda confused deputy-ish attack, which is why it came up in the blogpost, and anyway, hi, I'm not a cryptographer, momentary reminder that I am not a cryptographer, but I have designed cryptographic certificate chains and I was pretty shocked by that At any rate, one way or another, you can presumably use did:plc to move yourself from one server to another so in the interest of "credible exit" this is a good choice Though, one might take a moment to ask: who controls the keys if you *do* want to move? Bluesky has identified, I'd say correctly even, that key management for users is an *incredibly* hard thing to do. But the solution, once again, ends up pretty centralized: for all users on Bluesky's main servers at least, Bluesky generates and manages the keys for them. I am, once again, kinda sympathetic and kinda unsettled simultaneously. - Sympathetic: key management *is* hard and we just don't have the UX answers to solve that, and Bluesky is once again trying to deliver to Twitter refugees The big promise here, the "credible exit" side of things is that for most users, the vision they have is that if Bluesky gets bought by a big evil company, no problem, move somewhere else But for those same users, Bluesky still *controls their keys* and thus *controls their destiny* Regardless, Bluesky has this "your domain is your id!" thing, and that's pretty cool, the domain maps to your DID and your DID maps to your domain Well, I'm not gonna get into this in detail here, I do on the blogpost if you wanna read it but, the cyclic dependency might be an actual cycle tl;dr on that UX part: - users only know domains, they don't know the DIDs in addition to this long-ass thread there is a long-ass article and if you care about things like "zooko's triangle" maybe read that version, the rest of y'all can move on we've got other stuff to cover here It is time for TEA BREAK 2: THE REHEATENING I will also go to the bathroom TMI? If you've read this far into this weird thread I am already giving you too much info === TEA BREAK 2 === @cwebber I'mo reply-guy you here: "Well, actually, tho I didn't understand everything, I got new bits and pieces I hadn't understood before, and I'm glad you wrote it." Enjoy "The Reheatening". I heard the special effects were *wild*.  @cwebber Enjoying this thread, although afterwards it would be amazing if you'd roll it into a blog post.   @fuzzychef @cwebber amazing troll, or did you miss the opening that says the thread is a summary of this post? ;D https://dustycloud.org/blog/how-decentralized-is-bluesky/  @cwebber I think it's great that you're modeling for people that they should take breaks and take care of their bodies. I have returned, with tea I am still not reading notifications. Well, I have seen a few fly by on the fediverse which is blipping and blooping nonstop in the Mastodon UI so people are clearly reading it there Bluesky says "30+". How big is the +?? I will resist temptation to look and assume "31" "Where are we going with this Christine?" Well you could have just read the blogpost but 3 more sections remain, we are approximately 2/3 there I know, bear with me, what is left is: - What should the fediverse do? Yes, I changed the order of the remaining sections, not from the blogpost but from the last time I said what was left on this thread pray I do not reorder them again Before we get into the next section, earlier I left an easter egg, which you could reply to and say "I found the easter egg" or something Now you can put 2 eggs I 2 was once an egg (Look I specifically transitioned so I could never be accused of making dad jokes again so that does not qualify) Alright you've heard enough critiques of Bluesky for a bit and I SAID I was gonna critique the fediverse and I am a WOMAN OF MY WORD So let's get into it!  @cwebber <grabs popcorn> :) No but seriously this thread is great, thank you so much for writing this! I'm learning a lot I have actually critiqued ActivityPub and the fediverse a lot! I have kind of never stopped critiquing it, ever since the spec was released. There's a lot that can be improved! I have even gotten criticism from AT LEAST ONE ActivityPub spec author for critiquing AP-as-deployed but I do anyway Actually something that is funny about ActivityPub is that there's "ActivityPub the spec", which I think is pretty solid for the most part, and "ActivityPub-as-deployed" Many of the critiques I'm about to lay out we left holes in the spec for which I hoped would be filled with the right answers One thing we have already discussed so, before I will say anything else, I will repeat: content addressing is really good, and I'd like to see it happen in ActivityPub, and it's *possible to do*, I even wrote a demo of it https://gitlab.com/spritely/golem/blob/master/README.org Bluesky does the right thing here, AP should too Content addressing is important. It should not matter where content "lives". It should be able to live anywhere. A server should be able to go down, and content should survive. Go content addressing! Actually with this and several other things I am going to bring up, I actually made sure there was space to do things right: there was a push to make ActivityPub "https-only" I pushed back on that, I didn't want that requirement, and it was exactly for this reason: enabling content addressing This isn't the only time I left a critique of ActivityPub-as-Deployed as opposed to ActivityPub-as-it-could-be: see also OCapPub, which critiques the anti-abuse tools of AP as inadequate and leading to "the nation-state'ification of the fediverse" https://gitlab.com/spritely/ocappub/blob/master/README.org Oh, and ocaps!!! ActivityPub left giant holes in the spec around two things which sound the same but which are not the same: Authentication and Authorization Trying to mix these two, you accidentally get ACLs, and then you get confused deputies and ambient authority, plagues of the security world Anyway, if you know *anything* about me, you know I am a big fan of capability security (ocaps) and that's the foundation of our work over at @spritely But we will come back to ocaps in a second because it turns out OCapPub is not the only time I proposed AP + ocaps!   Shouldn't this be 20 bytes? There are 32 characters, and each character is base32, or 5 bits. So 160 bits? Edit: nope, wrong. I don't *think* there's a huge concern over this, because while maybe you could do a birthday collision attack in 80 bits, this wouldn't really get you much and wouldn't let you take over someone else's account. For that you'd need a pre-image attack on the whole 160 bits. Edit: 120 bits pre-image, but I think the point stands? *Also not a cryptographer!!* @fontenot no because the 32 characters includes the "did:plc:" @cwebber I'm not a cryptographer. Some of my best friends are cryptographic systems! |
The first strange thing to me is that did:plc uses sha256 and, AFAICT, not sha256d (which is really just running sha256 again over the hash). Unless I am missing something? Am I wrong?
Maybe it's not a concern because of doc parsing but it's best practice to protect against length extension attacks