Hi all, In just a few weeks, the 33C3 will be held in Hamburg, the 33th Chaos Communication Congress organized by the Chaos Computer Club. I intend to organize a keysigning party, just because they are fun.
I am asking for your thoughts on a variant of the organization of the keysigning party. I'll explain my reasoning and intentions, and I would like to know if you think I forgot to think of something important. Is there a way a malicious party could get people to sign the wrong UID, because I didn't think of that way? I'm not interested in ways people could cheat at the usual "informal" keysigning party model, with exchanging paper keyslips. This is because this would be my fallback model, if the proposed model doesn't work out. So I'm only interested in cases where the proposed model introduces extra issues compared to the informal exchanging keyslips model. There are several methods to do a keysigning party. One of them is the "Sassaman efficient" version. It requires preparation, and this preparation must be done in time that everybody can print out their copy of the list. With a congress spanning several days, this means the preparation should probably be done before the congress, since in general you shouldn't print your list on a printer you don't completely trust, and most people don't bring a printer (I did! :). Now Sassaman efficient has a very big issue. There will always be people who also wish to attend the keysigning party who did not participate in the preparations. As far as I can see, these people could just participate as equals with printed out keyslips to hand out to the other people. However, I've seen multiple times that these late guests were treated as second-class participants. I've actually seen them delegated to the corridor outside the room where the party was held, told to wait until the others were done! I never got a chance to exchange fingerprints with these people because of course they left a long time before the party inside was done. I can't imagine this was a very pleasant experience for them. The common denominator of the Sassaman efficient and the informal method is that you form a line of people that folds in on itself. Now, as I see it, you can just form a line beginning with the people on the list and ending with the people who joined late.[1] With the people on the list, you only check ID's and place a checkmark on your list when satisfied. Once you get to the part with the late attendants[2], you instead exchange key slips. I don't see why the people who are not on the list should not be allowed to be in the same line, yet it is what I've seen happening. Anyway, so, Sassaman efficient has a major problem. It also has advantages. At the bottom line, there is only one advantage I find relevant. With Sassaman efficient, you actually only have to check one SHA256 hash and your own fingerprint. No matter how many attendees, you don't have to check anyone else's fingerprint manually. Just the two! This is because you have a SHA256-protected list of fingerprints already in digital form; no need to compare to printed out digits on paper. All attendees who participated in the preparation have gotten a text file which contains all fingerprints of the participants, and they print out this list as well as compute its checksum. Additionally, they check that their *own* fingerprint in this list is correct. At the event, the SHA256 checksum of the text file is read aloud and everybody compares it to the checksum on their piece of paper. Next, each participant on the list is asked in turn whether their fingerprint checked out.[3] After the event, you'll go home and sign keys, using the verified text file that has the correct SHA256 checksum. Now when you use CA - Fire and Forget, caff, all you have to check are the UID's you are signing. The SHA256 checksum has already ascertained that the fingerprints in the text file are correct; anyone altering a fingerprint will necessarily alter the checksum of the file. And caff checks the fingerprint for you from the known-correct file! As long as all participants verified that their own fingerprint is correct in the file with the correct SHA256 hash, all fingerprints have been verified already. It will still be *very* important to verify the UID's manually. What if the official list had a key with fingerprint X and UID <[email protected]>, but once you download the key with fingerprint X, there's instead an UID <[email protected]>? You need to check that you only sign UID's carrying Alice's name that you verified from her passport or similar thing. I quite like it that I don't have to verify dozens of fingerprints manually; I'd like to keep the list if possible. So can we improve on the party where there is a line of both people on the list and people with keyslips? I think we can. I think ideally, the participants who only joined after the preparations should also be able to use the list for the people that are on it, to put checkmarks and be able to sign without manual fingerprint verification. But you can't /just/ give them a copy of the list on paper to trust on, because that printout could have been altered. If they have a printout with an altered fingerprint, this will confuse them and lead them down a bad road. But they don't actually need to check the fingerprint, right? Why print it out then? First, let me show you a possible participant list for Sassaman efficient, as produced by gpgparticipants (signing-party package of Debian). Then let me show what I'd like to alter. CUT HERE -----------------------------8<------------------>8----------------------------- Sunday, December 4, 2016; 12:00 Gyro Gearloose <[email protected]> T E S T H Y B R I D P A R T Y List of Participants (v 1.0) Here's what you have to do with this file: (1) Print this UTF-8 encoded file to paper. (2) Compute this file's SHA256 checksum. gpg2 --print-md SHA256 ksp-test.txt (3) Fill in the hash values on the printout. (4) Bring the printout, a pen, and proof of identity to the key signing party (and be on time!). SHA256 Checksum: ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ ____ [ ] 001 [ ] Fingerprint OK [ ] ID OK pub rsa2048/35FEAAB2 2011-03-18 [SC] [expired: 2014-08-15] Key fingerprint = 7AA6 6193 3AFB F009 D3FF 931D 5A48 8393 35FE AAB2 uid Scrooge McDuck <[email protected]> _______________________________________________________________________________ 002 [ ] Fingerprint OK [ ] ID OK pub rsa2048/17C05EBD 2014-08-13 [SC] [expired: 2015-05-29] Key fingerprint = 9BF2 FC98 F2C5 8E7C 2F1A BBB1 9D39 0555 17C0 5EBD uid Donald Duck <[email protected]> _______________________________________________________________________________ 003 [ ] Fingerprint OK [ ] ID OK pub rsa1024/503560C4 2014-08-14 [SC] [expired: 2014-08-21] Key fingerprint = C956 4F26 D57B 160F 7258 7865 6CBD 1E35 5035 60C4 uid Daisy Duck <[email protected]> _______________________________________________________________________________ 004 [ ] Fingerprint OK [ ] ID OK pub rsa2048/DE500B3E 2009-11-12 [C] [expires: 2017-10-19] Key fingerprint = 8FA9 4E79 AD6A B56E E38C E5CB AC46 EFE6 DE50 0B3E uid Peter Lebbing <[email protected]> _______________________________________________________________________________ 005 [ ] Fingerprint OK [ ] ID OK pub rsa1024/DCDFDFA4 2012-03-17 [SC] [expires: 2016-12-10] Key fingerprint = 8254 72F3 7172 B95A DC73 49BE 98B6 7DE4 DCDF DFA4 uid 167-671 <[email protected]> _______________________________________________________________________________ 006 [ ] Fingerprint OK [ ] ID OK pub rsa1024/0E675C27 2016-12-03 [SC] [expires: 2016-12-10] Key fingerprint = 9995 E685 2227 CB3F A7D0 D426 B0D4 EDBE 0E67 5C27 uid Magica De Spell <[email protected]> _______________________________________________________________________________ -----------------------------8<------------------>8----------------------------- CUT HERE You can further process this list before printing with gpgsigs, which will annotate the list with both the checksum and an indication when you have already signed an UID (this changes the "uid" lines above to the format as seen in the next bit). Now I'm proposing to remove all information that does not need to be manually checked, and give all participants who didn't do the preparation this scrubbed list. It would look like this: CUT HERE -----------------------------8<------------------>8----------------------------- Sunday, December 4, 2016; 12:00 Gyro Gearloose <[email protected]> T E S T H Y B R I D P A R T Y List of Participants (v 1.0) Here's what you have to do with this file: (1) Print this UTF-8 encoded file to paper. (2) Compute this file's SHA256 checksum. gpg2 --print-md SHA256 ksp-test.txt (3) Fill in the hash values on the printout. (4) Bring the printout, a pen, and proof of identity to the key signing party (and be on time!). SHA256 Checksum: CEA0 9114 F8AD 5FDD A0F4 7984 47C8 D1C1 3B1F B76B 68AC 3B12 78FE C3EC E95B 73D8 [ ] 001 [ ] Fingerprint OK [ ] ID OK ( ) Scrooge McDuck <[email protected]> _______________________________________________________________________________ 002 [ ] Fingerprint OK [ ] ID OK ( ) Donald Duck <[email protected]> _______________________________________________________________________________ 003 [ ] Fingerprint OK [ ] ID OK ( ) Daisy Duck <[email protected]> _______________________________________________________________________________ 004 [ ] Fingerprint OK [ ] ID OK ( ) Peter Lebbing <[email protected]> _______________________________________________________________________________ 005 [ ] Fingerprint OK [ ] ID OK ( ) 167-671 <[email protected]> _______________________________________________________________________________ 006 [ ] Fingerprint OK [ ] ID OK ( ) Magica De Spell <[email protected]> -----------------------------8<------------------>8----------------------------- CUT HERE Now once these people get home, they get the original text file from the organizer, and verify its checksum using their paper copy. Additionally, they need to check that the UID's on their paper copy have the same serial number as the ones in their digital copy. This is an additional task compared to what the other participants need to do; since the others printed their own version they *know* the only way UID's could have been swapped or added is if they did it themselves before printing. After the late participants have verified the checksum and the serial<->UID mapping, they can continue as the other people, not verifying fingerprints because they already verified the SHA256 sum. The reason for wiping out the parts that aren't checked is so people will not get confused should they mismatch. If the one doing the printing was malicious, they could alter fingerprints on the list. This would entice people to sign the key with that fingerprint, even though it is the wrong one. You could tell people that they need to ignore this unverified information and use the official, SHA256-verified digital list only, but that is asking for trouble. Just remove this unverified information and be done with it! So, thank you for reaching the bottom of my mail. What do you think? Does it work? If not, I'm falling back to the informal model, to remove the perverse incentive that arises from using Sassaman efficient, the incentive to treat latecomers as second-class (since my proposal includes them explicitly in the process, they won't be left out). Thanks, Peter. [1] The only reason I group the list people and the keyslip people is so you only have to switch exchange method twice; you start out with one group, halfway switch to the other group, and then later switch back to the first group. The people at the very beginning and end of the line only switch once. [2] Well, late as in not early. Let's hope they're not deceased by then ;-P. [3] There will be an issue here if the checksum did not check out for someone; the organizer should make clear that once your checksum is wrong, you should stop using that mangled version at once. -- I use the GNU Privacy Guard (GnuPG) in combination with Enigmail. You can send me encrypted mail if you want some privacy. My key is available at <http://digitalbrains.com/2012/openpgp-key-peter> _______________________________________________ Gnupg-users mailing list [email protected] http://lists.gnupg.org/mailman/listinfo/gnupg-users
