The thing that is telling to me about DMs is that we *have* federated direct message protocols like XMPP which have been around for ages; if Bluesky wanted to they could have tacked that on pretty quickly, E2EE or not.

[cwebber@social.coop]

There 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

[cwebber@social.coop]

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

[cwebber@social.coop]

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@social.coop]

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?

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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.

[cwebber@social.coop]

> 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?)

[cwebber@social.coop]

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

[cwebber@social.coop]

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

[cwebber@social.coop]

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?

[cwebber@social.coop]

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.

[cwebber@social.coop]

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
- Unsettled: it's centralized, but... there's something *more* troubling

[cwebber@social.coop]

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*

[cwebber@social.coop]

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

[cwebber@social.coop]

tl;dr on that UX part:

- users only know domains, they don't know the DIDs
- turns out that's a phishing attack when those can change at any time
- if bsky.app ever goes down how do you actually know I *really* mapped to that name
- and a whole lot of "liveness" problems that enter there

[cwebber@social.coop]

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

[lutindiscret@mastodon.libre-entreprise.com]

@cwebber I don't get it. You are saying did:web is centralized because it relies upon DNS which is centralized. So Bluesky is centralized. Fair.

But, fediverse instances are hosted to a domain and my AP handle has a DNS too so ActivityPub is centralized too?