› Articles › Contact › Download › Misc › Home

Median Key-signing Protocol

E-mail: thomas[at]northernsecurity.net
Url: www.northernsecurity.net

1. Purpose

The Median Key-signing Protocol is a protocol trying to achive two things; be reasonable effective, time wise, when used at a big key-signing party compared to the Manoj's Key-Signing Protocol and more secure than the photo-id and key fingerprint checking used by the Efficient Group Key Signing Method. It transforms the usual photo-id and key fingerprint (id+fp) identification procedure to a procedure that involves both the id+fp check and adds an uniqe identifier, the verification code.

2. Pros and cons

+ not as complicated as the Manoj's Key-Signing Protocol.
+ more secure than the usual photo-id and key fingerprint checking.
+ can be combined with the Efficient Group Key Signing Method without much hassle.
- bit more complicated than the Efficient Group Key Signing Method.
- involves a third-party (the organizer) which need to be trusted.
- more work for the organizer, since the Manoj's Key-Signing Protocol and Efficient Group Key Signing Method largely depends on the participants.

3. Protocol

1. the organiser announces time/place of keysigning, deadline for participation and verification of the verification codes
2. each user submits their keys to the organizer
3. the organizer generates a verification code for each email address on the keys submitted
4. the organizer saves the verification codes
5. the verification codes are sent encrypted and signed to the email addresses on the submitted keys
6. each user turn up at the keysigning with key fingerprint, photo-id and personal verifications codes
7. each user checks the photo-id and key fingerprint, receives the verifications codes from other participants
8. each user sends her own verification codes and the other participants verification codes to the organizer
9. the organiser checks the verification codes
10. the user receives a signed and encrypted mail stating that verification code belonging to email address X is valid or invalid

4. Representation of verification sent in 3.5

<key id>: <v1>,<v2>, ... <vn>
where v1, v2 to vn are the secrets in the same order as the emails presented in the output of the key submitted.
For example, if the key output is:

		   pub  xxxx/DEADBEEF  xxxxxxxx   Alice <alice@wonderland.net>
		   uid                            Alice <alice@company.com>

v1 would belong to alice@wonderland.net and v2 to alice@company.com and so on until all email addresses got their own verification code.

5. Definition of "organizer"

The term organizer is used pretty loosely in this document, even though the protocol is a basic one and a person can handle all steps easily, it is recommended that as many of the protocol steps are automated to prevent the verification codes to be viewable by the human organizer. One option is to store the verification codes as H(u||e||c), where u is the keyuid, e email and c verification code.

6. Description of verification code

The verification code consists of at least five alpha-numerical characters used to create uniq identifiers of the email addresses belonging to a submitted key.

7. Verifying verification codes

Each user sends a list to the organizer with her keyid and verification codes first.
If the users verification codes are valid, the email addresses presented in her key will be used for return addresses, or else it should be dropped.
After the user's personal key-id and verification codes a list of key-ids and verification codes will follow (as described in 4), this should be the key-ids and verification codes given to the user after she has verified the photo-id and key fingerprint of the participants of the keysigning party.

This document is publish under a Creative Commons License.