I don't believe that's a part of the current spec (https://swicg.github.io/activitypub-e2ee/mls)
Uncategorized
14
Posts
3
Posters
0
Views
-
@benpate @risottobias @bonfire Ah, I guess that means I should dust off my original draft from 2022
Yes please. Could you post a link to what you've done so far?
-
Yes please. Could you post a link to what you've done so far?
@benpate @risottobias @bonfire I think you misunderstood.
I'm suggesting that the decision to not include secure public key management will tie your hands to support whatever insecure thing you're doing now for the sake of backwards compatibility, so I'm probably better off working on my own thing than trying to participate.
-
@benpate @risottobias @bonfire I think you misunderstood.
I'm suggesting that the decision to not include secure public key management will tie your hands to support whatever insecure thing you're doing now for the sake of backwards compatibility, so I'm probably better off working on my own thing than trying to participate.
@benpate @risottobias @bonfire But for posterity:
https://github.com/soatok/mastodon-e2ee-specification
I started this in 2022 and then shifted gears to Key Transparency with the intent to switch back once that problem was solved. KT slots neatly into the "Federated PKI" vacancy on the 2022 repo
-
@benpate @risottobias @bonfire I think you misunderstood.
I'm suggesting that the decision to not include secure public key management will tie your hands to support whatever insecure thing you're doing now for the sake of backwards compatibility, so I'm probably better off working on my own thing than trying to participate.
@soatok @benpate @risottobias @bonfire how about we all work together to make everything better?
-
@benpate @risottobias @bonfire But for posterity:
https://github.com/soatok/mastodon-e2ee-specification
I started this in 2022 and then shifted gears to Key Transparency with the intent to switch back once that problem was solved. KT slots neatly into the "Federated PKI" vacancy on the 2022 repo
(Dropping Risotto Bias who got in the middle of a conversation they didn't actually want to be in)
-
The spec that we have makes the client key packages available as a property of the ActivityPub actor. This is very convenient in the AP ecosystem, since they can be managed (created, added, removed, deleted) with the ActivityPub API. MLS grinds through key packages pretty frequently, so it's good to have this easy to do.
-
The spec that we have makes the client key packages available as a property of the ActivityPub actor. This is very convenient in the AP ecosystem, since they can be managed (created, added, removed, deleted) with the ActivityPub API. MLS grinds through key packages pretty frequently, so it's good to have this easy to do.
This structure has the downside that intervening entities can insert their own key packages into the collection -- so that remote clients encrypt to all the actor's keys, as well as to the interloper's keys.
For example, if Actor A's server adds its own key to the collection, any messages sent to Actor A will also be encrypted to the server. Exactly what we are trying to avoid!
-
This structure has the downside that intervening entities can insert their own key packages into the collection -- so that remote clients encrypt to all the actor's keys, as well as to the interloper's keys.
For example, if Actor A's server adds its own key to the collection, any messages sent to Actor A will also be encrypted to the server. Exactly what we are trying to avoid!
There are other entities in the ecosystem that could also add keys. For example, if Actor B uses their server's proxyUri to fetch Actor A's key package collection, B's server could also add in a separate key package.
-
@soatok @benpate @bonfire one way to mitigate this kind of attack is key verification. This is simply having Actor A and Actor B set up communications out of band, like on a phone call, and list out the key packages they see for each other. It's crude, and nobody ever wants to do it, but theoretically the possibility that this could happen keeps attackers from using this technique.
-
@soatok @benpate @bonfire one way to mitigate this kind of attack is key verification. This is simply having Actor A and Actor B set up communications out of band, like on a phone call, and list out the key packages they see for each other. It's crude, and nobody ever wants to do it, but theoretically the possibility that this could happen keeps attackers from using this technique.
@soatok @benpate @bonfire Soatok's work provides another mechanism. It is an out-of-band server that e2ee clients submit their keys to. Actor B's client can compare the keys that it gets from Actor A's server with the keys it gets from the Key Transparency server to make sure they are all listed. If it finds keys that aren't listed, it can warn the user, or just drop the key.
-
@soatok @benpate @bonfire one way to mitigate this kind of attack is key verification. This is simply having Actor A and Actor B set up communications out of band, like on a phone call, and list out the key packages they see for each other. It's crude, and nobody ever wants to do it, but theoretically the possibility that this could happen keeps attackers from using this technique.
@evan @benpate @bonfire Such attacks are rare to begin with, so I don't know how well their behavior maps to game theory, but if I were prone to gamble, I would bet on "they found an easier attack" sooner than "the possibility that someone might compare fingerprints is enough to dissuade the tactic". Social engineering is unreasonably effective on most people.
-
@evan @benpate @bonfire Such attacks are rare to begin with, so I don't know how well their behavior maps to game theory, but if I were prone to gamble, I would bet on "they found an easier attack" sooner than "the possibility that someone might compare fingerprints is enough to dissuade the tactic". Social engineering is unreasonably effective on most people.
@soatok @benpate @bonfire yeah. The fact that the verification UIs are often closed source clients published by the same corporation that makes the server software makes them kind of security theater. The software maker could just hide the secret server keys from the verification UI. I think it's a more robust protection in a multiplayer ecosystem, where clients and servers are written and operated by different entities.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@robotti92 non credo che sia possibile utilizzare i servizi cloud e 6TB di spazio senza pagare.
Ma, anche nel caso, non è etico.
Io credo che se una cosa è sbagliata, è sbagliata anche se è il "nemico" a subirla.
-
@woozle I personally am much more interested in the "competitive" part rather than the "market" part, which is why I linked the Wikipedia article on competition.
-
@woozle it's always acceptable to answer as you wish!
I really regret using the term "market" instead of "technology sector" or something similar. The technical definitions of "market" seem to encompass tech sectors where many of the products, including labour, are available gratis, but I think a lot of people got hung up on the idea of commercial exchange.
-
@simonperry Puoi anche usarlo senza dare una lira a Microsoft, grazie a https://massgrave.dev/
-
@fucinafibonacci @marcell_o ci credo che ai sovranisti occidentali Putin piace tanto, quando fa le conferenze stampa gli chiedono se crede nell'amore. Tipo come se ti chiedono delle pastarelle. Matti che comandano e fanno guerre come fossero inviti a cena, e il massimo delle interviste sono cuoricini! Ma almeno lì sono sotto regime. Chi governa l'Occidente, li prende come esempio, e questo spaventa. Aiuto.
-
Roarrrr!
Happy #Caturday
#Photography #CatsOfMastodon #Cat #Cats #PetPhotography #Pets #Yawn #CatsOfFedi #CatosOfFediverse
-
@clf I think many are bots/spam ones
-
@dvl I agree - that would be interesting
