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:
- a node that stores an alternative ID must not change its value, only refresh it. Nodes that try to store a different alternative ID must be blacklisted
- a query for an alternative ID should query several nodes (like a lookup), not just the first one that returns a value. If different alternative IDs are found then a warning should be displayed.
- a new alternative ID cannot be used during the 5 days from the date of first publication: a node should not respond to request for alternative IDs that have been published for less than 5 days
- clients should try to load the alternative ID for their contacts as soon as possible, and then they shouldn’t modify it
- warnings should be issued if a contact starts using an alternative ID
UPDATE
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….