Plume/Plume

Fork 24

Please implement support for Blind Key Rotation (privacy feature) #398

Nueva incidencia

Cerrada

abierta 2018-12-30 02:21:15 +00:00 por kaniini · 3 comentarios

kaniini comentado

2018-12-30 02:21:15 +00:00

(Migrado desde github.com)

Background

Blind Key Rotation is a mitigation for the problem that JSON-LD Linked Data Signatures are irrevocable. It is also useful (albeit less so) in the context of HTTP Signatures, since HTTP Signatures only sign headers and not the object itself, and are also detached from the object.

As Plume implements JSON-LD Linked Data Signatures, implementing Blind Key Rotation is important for resolving trust and safety issues with this signature scheme!

Implementation - receiving objects

Supporting Blind Key Rotation in the validation pipeline is simple enough: if a signature validation fails, refetch the remote actor and recheck the signature accordingly.

This would be done here: 80a4dae8bd/src/routes/instance.rs (L188-L193)

Implementation - deleting objects

Supporting Blind Key Rotation to enhance the deniability of deleted objects is also simple enough: send the Delete signed with the original key and then silently replace the keypair. The new keys will be fetched when the user publishes new content.

I'm not quite certain where to implement this part, but it is probably not that hard to implement.

Questions?

Contact me on fediverse: https://pleroma.site/kaniini

### Background Blind Key Rotation is a mitigation for the problem that JSON-LD Linked Data Signatures are irrevocable. It is also useful (albeit less so) in the context of HTTP Signatures, since HTTP Signatures only sign headers and not the object itself, and are also detached from the object. As Plume implements JSON-LD Linked Data Signatures, implementing Blind Key Rotation is important for resolving trust and safety issues with this signature scheme! ### Implementation - receiving objects Supporting Blind Key Rotation in the validation pipeline is simple enough: if a signature validation fails, refetch the remote actor and recheck the signature accordingly. This would be done here: https://github.com/Plume-org/Plume/blob/80a4dae8bda18139da71ff678a50d4cc6baa27b3/src/routes/instance.rs#L188-L193 ### Implementation - deleting objects Supporting Blind Key Rotation to enhance the deniability of deleted objects is also simple enough: send the `Delete` signed with the original key and then silently replace the keypair. The new keys will be fetched when the user publishes new content. I'm not quite certain where to implement this part, but it is probably not that hard to implement. ### Questions? Contact me on fediverse: https://pleroma.site/kaniini

👍 8

mcrosson comentado

2018-12-30 04:57:05 +00:00

(Migrado desde github.com)

An activity pub user has also opened a small bounty for this https://social.holdmybeer.solutions/objects/44515888-e4c2-4043-b0e8-96e15b7a254c

trinity-1686a comentado

2018-12-30 10:12:02 +00:00

Propietario

So if I understood well:

when receiving object: re-fetch the actor if signature validation fail
when sending Delete (do Undos count too?) : sign with the current key, then regenerate a new one
when sending other activities : work as before

Am I right?
I have a few more questions:

do the original key (in deleting Object) need to be the one which was used in the Create activity, or can it be an other key assuming something else was deleted between creation and deletion of this Object?
Keys have an id, with Plume it's currently https://<domain>/@/<user>/#main-key. Should this value be updated whenever a new key is issued, or not?
Should the new key be "advertised" as soon as the Delete activity is sent, or some time later (how much?) to make sure instances who did not know the key for this Delete can still fetch it to validate the deletion?

So if I understood well: - when receiving object: re-fetch the actor if signature validation fail - when sending `Delete` (do `Undo`s count too?) : sign with the current key, then regenerate a new one - when sending other activities : work as before Am I right? I have a few more questions: - do the `original key` (in deleting Object) need to be the one which was used in the `Create` activity, or can it be an other key assuming something else was deleted between creation and deletion of this Object? - Keys have an id, with Plume it's currently `https://<domain>/@/<user>/#main-key`. Should this value be updated whenever a new key is issued, or not? - Should the new key be "advertised" as soon as the `Delete` activity is sent, or some time later (how much?) to make sure instances who did not know the key for this `Delete` can still fetch it to validate the deletion?

kaniini comentado

2018-12-30 14:35:04 +00:00

(Migrado desde github.com)

@fdb-hiroshima

Your understanding is basically correct. I would suggest rotating the key a little while after the Delete so if there's multiple Delete activities you can batch them together.

The original key should be whatever key would normally sign the Delete.

The key ID should not ever be updated when rotated.

@fdb-hiroshima Your understanding is basically correct. I would suggest rotating the key a little while after the `Delete` so if there's multiple `Delete` activities you can batch them together. The original key should be whatever key would normally sign the Delete. The key ID should not ever be updated when rotated.

Inicie sesión para unirse a esta conversación.

Sin hito

Ningún proyecto

Sin encargados

2 participantes

Notificaciones

Fecha límite

La fecha límite es inválida o está fuera de rango. Por favor utiliza el formato "aaaa-mm-dd".

Fecha límite no definida.

Dependencias

No se han establecido dependencias.

Referencia: Plume/Plume#398

No se ha proporcionado una descripción.

Filas
Columnas