reunicorn icon indicating copy to clipboard operation
reunicorn copied to clipboard

Key rotation

Open LGro opened this issue 6 months ago • 0 comments

To react to compromised keys or just in the spirit of forward secrecy, devise a scheme to migrate to a new public key with a contact in the same way that we allow initial migration from a shared secret to asymmetric crypto.

Include a list of past public keys to help with shared contacts detection and introduction proposals. They should all be paired with a signature using the currently used key material.

Shared information, encrypted with the last acknowledged key:

{
  "current_key": "acknowledged-pubkey-or-initial-psk",
  "next_key": "next-pubkey",
  "identity": "identity-pubkey",
  "outdated_identities": {
    "old-identity-pubkey": "old-identity-signed-old-pubkey",
  },
  "signature": "signature-of-the-rest-of-this-object"
}

Local information per contact:

  • in flight keypairs (from the most recently acknowledged one onwards the newly proposed keypairs)

Local information across contacts:

  • per "account" (could be globally and per isolated circle): list of keypairs (some of which may be in use; or current keypair + list of deprecated keypairs, some of which may be in use)

When receiving information, current and next keypair are tried and if next succeeded, it's move to current and the current to previous; updating shared profile info as well.

We can probably always keep rotating those keys, or at least whenever the shared profile / locations change.

To achieve deniability we could also share the private keys for outdated keypairs, but would need to take care that the current keypair is signed by the identity, but then the current keypair (not the identity) is used to sign the shared details and locations.

LGro avatar Jun 06 '25 11:06 LGro