Keysigning: Difference between revisions
From HacDC Wiki
No edit summary |
No edit summary |
||
| Line 4: | Line 4: | ||
* You have a private key and a public key, which you generate (your keypair). | * You have a private key and a public key, which you generate (your keypair). | ||
** gpg --gen-key | |||
* People use your public key to send you encrypted messages that only you can open via the magic of crypto! | * People use your public key to send you encrypted messages that only you can open via the magic of crypto! | ||
** gpg --output doc.gpg --encrypt --recipient [email protected] doc | |||
* You decrypt these messages with your private key, which only you have access to. | * You decrypt these messages with your private key, which only you have access to. | ||
** gpg --output doc --decrypt doc.gpg | |||
* But first, you must share your public key, either directly or by uploading it to a keyserver. | * But first, you must share your public key, either directly or by uploading it to a keyserver. | ||
** gpg --keyserver pgp.mit.edu --send-keys D34DB33F | |||
* If it's on a keyserver, they must download it from the keyserver. | * If it's on a keyserver, they must download it from the keyserver. | ||
* If it was a file, they can import it manually. | ** gpg --keyserver pgp.mit.edu --recv-key D34DB33F | ||
* If it was a file (called obscurite.gpg for example), they can import it manually. | |||
** gpg --import obscurite.gpg | |||
* Now they can sign the key and send the key back to the keyserver. | * Now they can sign the key and send the key back to the keyserver. | ||
** gpg --sign-key D34DB33F | |||
* But before anyone signs anyone elses key they have to make sure that person actually owns that key (checking physical ID). | * But before anyone signs anyone elses key they have to make sure that person actually owns that key (checking physical ID). | ||
* Now people can see that you believe that key to be valid, which improves the chances of it being a valid key! (web of trust) | * Now people can see that you believe that key to be valid, which improves the chances of it being a valid key! (web of trust) | ||
* Now you're all set, but you also want to... | * Now you're all set, but you also want to... | ||
Revision as of 20:16, 11 October 2009
This page is a resource for keysigning parties.
Intro
- You have a private key and a public key, which you generate (your keypair).
- gpg --gen-key
- People use your public key to send you encrypted messages that only you can open via the magic of crypto!
- gpg --output doc.gpg --encrypt --recipient [email protected] doc
- You decrypt these messages with your private key, which only you have access to.
- gpg --output doc --decrypt doc.gpg
- But first, you must share your public key, either directly or by uploading it to a keyserver.
- gpg --keyserver pgp.mit.edu --send-keys D34DB33F
- If it's on a keyserver, they must download it from the keyserver.
- gpg --keyserver pgp.mit.edu --recv-key D34DB33F
- If it was a file (called obscurite.gpg for example), they can import it manually.
- gpg --import obscurite.gpg
- Now they can sign the key and send the key back to the keyserver.
- gpg --sign-key D34DB33F
- But before anyone signs anyone elses key they have to make sure that person actually owns that key (checking physical ID).
- Now people can see that you believe that key to be valid, which improves the chances of it being a valid key! (web of trust)
- Now you're all set, but you also want to...
- Generate a revokation certificate in case you lose your passphrase or your key is comprimised!
DETAILS
- For the keysigning party on Thurs 9/10 we will use the pgp.mit.edu keyserver
- PGP KEYSERVER EXAMPLE: gpg --keyserver pgp.mit.edu --send-key KEYIDHERE
- I will pass around copies of signatures so you can check people off as you confirm their identity
- I recommend using a valid state photo ID as a minimum validation. It is up to your personal "keysigning policy."