User:Wugapodes/Committed identity

Committed identity: d30661676f0d81866404a7e4c6ac2145b6036ba078db0c29c45ed698327d25b638c4a964543256f68d320c9c2fa3e7cfe1d11474bc2a89b21cb77fb8db8e0f33 is a SHA-512 commitment to this user's real-life identity.

This page describes a method of creating a {{committed identity}} that uses public-key cryptography to verify identity. It does this by using the CI hash as a public key checksum to verify that the provided public key is valid. If the alleged account holder can provide the correct public key, it can be used to verify that the claimant currently has access to the associated private key. This gives greater protection against brute force attacks and makes it possible for multiple verifications without requiring a change to the CI hash after every one.

Steps to create

1. Create a new PGP key pair following the instructions at debian:Keysigning#Step 1: Create a RSA keypair. Even if you already have a key pair, it is safer to create a pair specifically for this purpose. This method provides two ways to challenge identity claims, and the first challenge is providing the string that produces the hash. If your public key is widely known or on a keyserver, that challenge is easier to defeat than if the string (i.e., public key) was kept relatively secret.
2. (optional) Sign this new key with one of your existing keys. If you already have a widely shared public key, use it to sign this new key. This shows that the person who created the key pair has access to your default private key and so provides some security against adding a key pair you didn't create or don't control.
3. Export the public key and obtain its hash using gpg --armor --export key id | sha512sum where key id is your key's fingerprint.
4. Post the output of the hash somewhere on Wikipedia, preferably on your user page using {{Committed identity}}

Steps to verify

1. Ask the alleged account owner to provide the public key by providing the output of gpg --armor --export key id. Run the provided key through sha512sum and check that the result is identical to the hash posted on-wiki. If they do not match, the challenge is failed.
2. If the alleged account owner has provided the correct public key, issue them a verification challenge. Some possible challenges include:
   1. Ask the claimant to send an email signed with their private key. If the signature cannot be verified with the provided public key, then the challenge is failed.
   2. Use the provided public key to encrypt a document, phrase, or random string and ask the claimant to decrypt it. If they cannot provide you with the text you encrypted, then the challenge is failed
   3. If the key was signed by another key, then the challenge can be issued on the basis of those keys as well, either as substitute or supplement.
3. If the claimant has not failed the challenges, the connection between the account and claimant is verified.

What verification guarantees

While verifying the connection between an account and a claimed owner provides strong evidence that the claimant is the real owner, it is not necessarily a guarantee. This method only guarantees that the person you are communicating with has access to the same private key that the account holder also had access to at the time of posting their CI hash. It is possible that the private key was compromised and a bad actor is now using it to impersonate the original key holder. It is always safer to use multiple verification methods, especially when resetting passwords or emails.