Hybrid keysigning party, your opinion?
Peter Lebbing
peter at digitalbrains.com
Sun Dec 4 14:33:47 CET 2016
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
<alice at example.org>, but once you download the key with fingerprint X,
there's instead an UID <mallory at example.org>? 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
<gyro at example.org>
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 <scrooge at example.org>
_______________________________________________________________________________
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 <donald at example.org>
_______________________________________________________________________________
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 <daisy at example.org>
_______________________________________________________________________________
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 <peter at digitalbrains.com>
_______________________________________________________________________________
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 <167-671 at example.org>
_______________________________________________________________________________
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 <magica at example.org>
_______________________________________________________________________________
-----------------------------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
<gyro at example.org>
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 <scrooge at example.org>
_______________________________________________________________________________
002 [ ] Fingerprint OK [ ] ID OK
( ) Donald Duck <donald at example.org>
_______________________________________________________________________________
003 [ ] Fingerprint OK [ ] ID OK
( ) Daisy Duck <daisy at example.org>
_______________________________________________________________________________
004 [ ] Fingerprint OK [ ] ID OK
( ) Peter Lebbing <peter at digitalbrains.com>
_______________________________________________________________________________
005 [ ] Fingerprint OK [ ] ID OK
( ) 167-671 <167-671 at example.org>
_______________________________________________________________________________
006 [ ] Fingerprint OK [ ] ID OK
( ) Magica De Spell <magica at example.org>
-----------------------------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>
More information about the Gnupg-users
mailing list