Alternative identity

This page is no longer valid. Revocation IDs will be implemented instead.

We are thinking about implementing Alternative Identities into FlowingMail. This is a small description on how it should work.

As soon as your FlowingMail client will create your new public/private keys and ID, it will also create an alternative set of keys (and therefore also a different ID) to be used only in the case that the original one gets compromised.

The alternative ID (signed) will be published in the DHT together with the original public keys, but the alternative keys will be kept hidden. Ideally you will have to keep the alternative keys separate from your PC (ideally in a CD or other medium like USB key in a different location).

When a client adds your ID to its own contacts, it will add immediately also the alternative ID and just store it. As soon as the keys for the alternative ID are published on the DHT, then the clients that have your ID in their contacts will delete the original ID and start using the alternative ID. A new alternative ID will have to be signed and published.

This should mitigate the problems that arise when the original private key is lost or leaked to third parties. As soon as you discover the leakage of your private key you should communicate your new ID to your new contacts, because the thief could try to publish its own alternative ID. Old contacts should be on the safe side having downloaded the original alternative ID.

To mitigate the release of a fake alternative ID by the thief of the private key:


Using also the alternative ID to hash the original ID is also an option, but in this case a longer sequence of alternative IDs must be generated at once.
This would prevent the thief of the original ID to generate its own alternative one.

Just thinking loudly….