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
-
-
@gumnos that's a beautiful post. Thank you for sharing it
-
Have you ever wanted to have Theo de Raadt give you his fortune in your GNU Emacs session? I made a package some time ago which serves exactly this purpose. You can find the package, as well as it's history on Codeberg with the following link. It is currently my only Emacs package, but I plan to make more when it becomes useful to.
https://codeberg.org/amadaluzia/theo.el
Appending to the history after the package was published onto Codeberg, I ended up in a call where me and @izder456 were talking about theo.el. I believe in that call, it was also reposted in the OpenBSD room on Matrix. I also remember being suggested to put it on MELPA, so that is exactly what I did.
After creating the pull request and fixing all of the issues that stopped it from being pushed into MELPA, it couldn't make it on as it was a pretty repetitive package, and there were about 5 other `fortune`-esque packages with much more customisability. However, I now have a better package because of MELPA's guidelines, and I believe that I can still give attention to the package, even if not through MELPA.
That's why I wanted to talk about it here, because maybe you are interested in having a fortune package for your GNU Emacs. If so, and assuming you have straight.el, you can simply copy the following snippet into your init.el. After that, you should have it installed.
https://gist.github.com/amadaluzia/be96e325326a9d66619543af410e4bf4
Let me know how the package goes for you. I would love to improve the GNU Emacs ecosystem further, as a GNU Emacs user.
-
And here we are
Ho cmq già vinto il rigatino alla lotteria.
Si sbanca.
-
I am seeding the original Unix tape with a 40Gbit/s connection. If you want it fast, grab the torrent at archive.org.
-
@marxistvegan Does the fact that the Wikipedia article for competition was linked in the poll suggest that the emphasis was more on competition than on markets?
-
you ever have one of those moments where a taste or smell brings back memories?
Today I made coffee that brought of a flood of memories from my teen years, of sitting in my Opa & Oma's kitchen, the smell of bacon & scrambled eggs in cast iron on the stove, freshly buttered toast, and an old-school percolator of coffee brewing that he'd share with my dad and me. Opa & Oma & Dad are no longer with us and that house has long been razed, but they all live on in this mug of coffee.
-
@evan I think a lot more depends on how one interprets this question... "Does the open web require competitive markets?"
and I see how one can interpret that to mean monopolistic from a 'no' answer, but i think of this more as the internet to not be a place to buy and sell stuff. In fact to be a place for information and exchange of communication, in that sense then market is not needed for an open web.
