#GoodNight 🌙✨
Uncategorized
2
Posts
2
Posters
12
Views
-
-
This post is deleted!
-
undefined lasolitalaura_@sociale.network shared this topic on
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@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.
-
@MajDen
Marco te la può fare come vuoi.
A me l'ha fatta "su misura"
Scrivigli
-
There are other entities in the ecosystem that could also add keys. For example, 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.
-
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!
-
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.
-
(Dropping Risotto Bias who got in the middle of a conversation they didn't actually want to be in)
-
@ferrante @giornalismo meloni incapace libera solo Chico Forti
-
@phillycodehound thank you! She's been resting for some days and she's definitely in a better shape.
