Skip to content

Instantly share code, notes, and snippets.

Last active May 26, 2019
What would you like to do?
A protocol for efficient key signing party

Effiecient key signing party protocol

Disclaimer: this is a proof of concept, the protocol hasn't been reviewed yet! There might be undiscovered vulnerabilities!

However I tried hard to find any vulnerabilities and I don't know of any. I'm fairly confident the protocol is secure.


This protocol allows many participants to verify fingerprints of each other while minimizing the number of operation each participant needs to perform.

It should be well suited for key signing parties and similar events.

The protocol

  1. Participants choose a coordinator - e.g. the organizer of the event.
  2. Each participants sends their fingerprint with name or other identifying data to the coordinator. This can be done before the participants are physically present.
  3. The coordinator creates a simple text file containing provided information for each participant. It is recommended to use exactly one line for each participant.
  4. The coordinator calculates secure hash of the file (e.g. SHA256 as of 2019)
  5. The coordinator provides the file to every participant
  6. The coordinator shows the calculated hash in a way that it's obvious the hash is same for every participant. It can be displayed on big screen or using projector. Ideally printed on the paper. (to avoid changes)
  7. The participants are publicly counted so that everyone knows the number of participants and knows it's correct.
  8. Each participant counts the number of entries in the file (using wc -l)
  9. Each participants checks they are included in the file and their data matches
  10. Each participant calculates the hash of the file and compares it against common shared hash.
  11. Each participant publicly confirms that the hash matches and his entry is correct. He should also prove his identity (full name) to the others and others should chcek he's included in the file.
  12. Once every participant confirmed correctness of the information, the whole file is considered correct.

Explanation of correctness

Because of commonly shared hash, it's obvious that each participant has the same file. If any entry is corrupted or missing, the affected participant notices and notifies the others. In case there's extra entry, the count won't match. The check of identity in step #10 prevents participants from replacing their name with someone elses name and claiming it's correct. It can be skipped if it's assumed that everyone is honest and not compromised.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment