Computer industries have correlated psychometric selection effects with a bunch of subcultures. Many of these select for e.g. what is colloquially referred to as "autism", although that term refers to several probably-unrelated things in different contexts.
It might have something to do with the furry community being queer majority from early on, and starting in a time where information security was a personal matter of life and death.
For all that the author doesn’t like exotic crypto, this seems like the sort of problem that the sort of fancy cryptography that the Ethereum folks love would actually be appropriate for. The goals are, approximately:
1. There exists a log, and the log follows certain rules, and everyone agrees on a summary of the log from which log entries can be validated and from which the fact that the log follows the rules can be validated.
2. One can validate a record without retrieving the whole log.
3. Appends can be done, and new summaries generated, without access to some of the entries.
Cryptocurrency, as far as I know, does not care about #3, whereas this project does. But maybe similar sorts of exotic crypto could generate a stronger form of shredding: a scheme where deleted PII only persists in the form of a constant or logarithmic size ever changing summary. It’s a bit hard to argue that, say, 10kb of data contains PII from a million users.
> For all that the author doesn’t like exotic crypto
Hah, I think that's a little imprecise.
I actually love exotic crypto; it makes my life interesting, after all. But I will not rush to deploy it into production, and I'm not going to incorporate it into a project designed with such a humble purpose like making DMs encrypted on the Fediverse. The rules I laid out in this post were with that context in mind.
Honestly, I don't get it. Maybe I don't know enough about the fediverse?
Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change? Couldn't a parallel mechanism distribute public keys in a similar way?
What's the issue here - that the server where you have your account can replace your keys?
I know SSL's "certificate transparency" tries to detect replaced and mis-issued certificates after the fact, by putting them all into an immutable log that can be searched by domain name. It doesn't stop the attack, but it at least makes it detectable after the fact. Yet if the entries in the log can be deleted, so there's no longer a log that would prove an attack had happened, wouldn't that prevent the log fulfilling its sole purpose?
> Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change?
Your instance admin can change it. The goal of encrypting DMs is to protect against honest-but-curious instance admins, especially since often multiple have access to the stored DM contents on disk.
> Couldn't a parallel mechanism distribute public keys in a similar way?
How do you validate that the public key you're seeing is your friend's, and not a snooping administrator performing a MitM attack by substituting the public key with theirs?
> What's the issue here - that the server where you have your account can replace your keys?
Yes, partly.
> I know SSL's "certificate transparency" tries to detect replaced and mis-issued certificates after the fact, by putting them all into an immutable log that can be searched by domain name. But if the entries in the log can be deleted, so there's no longer a log that would prove the attack had happened, wouldn't that prevent the log fulfilling its sole purpose?
The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys. Additionally, the deletion of past log entries requires a legal takedown request. What this process actually looks like is out of scope for my specification, but I imagine it will usually involve lawyers.
> The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys.
But isn't the profile/bio already a mechanism that gives everyone the same view of some per-account details, set by the person who controls the account?
Alas I'm not smart enough to understand your threat model, as I'm just a simple small town software developer who don't even know what a Edwards25519 curve or a SUF-CMA is.
If an admin or hacker tampers with a user's bio - i.e. gains control of a user's account - isn't that essentially indistinguishable from a user who lost their phone/forgot their password?
Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?
Note that “PII” is American terminology, and it has a much more restricted meaning than the European term “personal data”. https://en.wikipedia.org/wiki/Personal_data
Ah, good point. I'll consider revising it later.
Very good, but needs more furry art.
I'm just thrilled to read something that's not peppered with the blandest AI art imaginable.
There is a huge overlap between the furry community and the infosec community. Furry art is very fitting for articles like this one.
Why is that? I have noticed that the deeper you get into infosec the furrier it gets. Has anyone studied that? I feel like there's something to that.
Computer industries have correlated psychometric selection effects with a bunch of subcultures. Many of these select for e.g. what is colloquially referred to as "autism", although that term refers to several probably-unrelated things in different contexts.
I wrote a blog post a few years ago that explores some hypotheses, but this is not a scientific paper by any means.
https://soatok.blog/2021/06/02/why-furries-make-excellent-ha...
It might have something to do with the furry community being queer majority from early on, and starting in a time where information security was a personal matter of life and death.
If actual research exists, Furscience might know: https://furscience.com/general-inquiries/
That and cultural specificities make furry costumes an intelligencia budget item
Agreed.
Much more furry art.
For all that the author doesn’t like exotic crypto, this seems like the sort of problem that the sort of fancy cryptography that the Ethereum folks love would actually be appropriate for. The goals are, approximately:
1. There exists a log, and the log follows certain rules, and everyone agrees on a summary of the log from which log entries can be validated and from which the fact that the log follows the rules can be validated.
2. One can validate a record without retrieving the whole log.
3. Appends can be done, and new summaries generated, without access to some of the entries.
Cryptocurrency, as far as I know, does not care about #3, whereas this project does. But maybe similar sorts of exotic crypto could generate a stronger form of shredding: a scheme where deleted PII only persists in the form of a constant or logarithmic size ever changing summary. It’s a bit hard to argue that, say, 10kb of data contains PII from a million users.
> For all that the author doesn’t like exotic crypto
Hah, I think that's a little imprecise.
I actually love exotic crypto; it makes my life interesting, after all. But I will not rush to deploy it into production, and I'm not going to incorporate it into a project designed with such a humble purpose like making DMs encrypted on the Fediverse. The rules I laid out in this post were with that context in mind.
Honestly, I don't get it. Maybe I don't know enough about the fediverse?
Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change? Couldn't a parallel mechanism distribute public keys in a similar way?
What's the issue here - that the server where you have your account can replace your keys?
I know SSL's "certificate transparency" tries to detect replaced and mis-issued certificates after the fact, by putting them all into an immutable log that can be searched by domain name. It doesn't stop the attack, but it at least makes it detectable after the fact. Yet if the entries in the log can be deleted, so there's no longer a log that would prove an attack had happened, wouldn't that prevent the log fulfilling its sole purpose?
> Doesn't the fediverse already have a mechanism where each user can set a profile, which everyone else has a common view of and other people can't change?
Your instance admin can change it. The goal of encrypting DMs is to protect against honest-but-curious instance admins, especially since often multiple have access to the stored DM contents on disk.
> Couldn't a parallel mechanism distribute public keys in a similar way?
How do you validate that the public key you're seeing is your friend's, and not a snooping administrator performing a MitM attack by substituting the public key with theirs?
> What's the issue here - that the server where you have your account can replace your keys?
Yes, partly.
> I know SSL's "certificate transparency" tries to detect replaced and mis-issued certificates after the fact, by putting them all into an immutable log that can be searched by domain name. But if the entries in the log can be deleted, so there's no longer a log that would prove the attack had happened, wouldn't that prevent the log fulfilling its sole purpose?
Consider https://defuse.ca/triangle-of-secure-code-delivery.htm#:~:te...
The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys. Additionally, the deletion of past log entries requires a legal takedown request. What this process actually looks like is out of scope for my specification, but I imagine it will usually involve lawyers.
> The goal is to ensure everyone has the same view of which actor has which currently-trusted public keys.
But isn't the profile/bio already a mechanism that gives everyone the same view of some per-account details, set by the person who controls the account?
Not if the admin tampers with your bio!
Not if the instance software itself gets hacked, either.
See https://github.com/fedi-e2ee/public-key-directory-specificat... for a detailed threat model.
Alas I'm not smart enough to understand your threat model, as I'm just a simple small town software developer who don't even know what a Edwards25519 curve or a SUF-CMA is.
If an admin or hacker tampers with a user's bio - i.e. gains control of a user's account - isn't that essentially indistinguishable from a user who lost their phone/forgot their password?
Is the intention that E2EE have a separate, parallel account recovery mechanism with more difficult requirements?