1.1 What exactly is a key signing party?
A key signing party is a get-together of people who use the PGP encryption system with the purpose of allowing those people to sign each others keys. Key signing parties serve to extend the web of trust to a great degree. Key signing parties also serve as great opportunities to discuss the political and social issues surrounding strong cryptography, individual liberties, individual sovereignty, and even implementing encryption technologies or perhaps future work on free encryption software.
Key signing is act of digitally signing a public key and a userid packet which is attached to that key. Key signing is done to verify that a given user id and public key really do belong to the entity that appears to own the key and who is represented by the user id packet.
You can digitally sign your own public key and an associated id on that key, or another entity's public key and associated public key packet.
In a sense, key signatures validate public keys. They are an endorsement of validity of a public key and associated id by a third party. This is the way in which key signing builds the web of trust.
A web of trust is a term used to describe the trust relationships between a group of keys. A key signature is a link, or strand if you will, in the web of trust. These links are called Trust Paths. Trust paths can be bidirectional or only one way. The ideal web of trust is one in which everyone is connected bidirectionally to everyone else. In effect, everyone trusts that every key does in fact belong to its owner. The web of trust can be thought of as the sum of all the trust paths, or links, between all key holding parties. As a visual example, here is a graph of a web of trust that I belong to.
1.4 Can you give me an example of the application of key signatures?
As an example, let's say that Alice and Bob generate PGP Keys with GPG and hold a PGP key signing party. At the party Alice and Bob go verify each others' key information and later sign each others' keys. GPG by default automatically signs the public key of every pair it generates with the associated private key. So, Alice and Bob both now have at least two signatures validating that their keys belong to them. Alice's key was signed by Alice herself and Bob and Bob's key was signed by Bob himself and Alice. In the future Alice and Bob meet Cathy. Cathy generates a key pair and tells Alice and Bob that she will send them her key. Alice doesn't like Cathy and doesn't want Bob to exchange encrypted communications with her. Both Alice and Cathy generate PGP keys which they claim belong to Cathy. They both send them to Bob. Both keys have one signature, the signature of the associated private key. Bob does not know which key is really Cathy's. Cathy hears that Bob got two keys, and suspects Alice. Cathy, now angry, wishes to gain information that she can use against Alice. In order to acquire this information Cathy must compromise the encrypted communications between Alice and Bob. In order to do this, Cathy decides to forge an email to Bob from Alice telling him that Alice has generated new keys. In the forged email, Cathy includes Alice's "new" public key (which is in fact a fake key generated by Cathy). However, Bob knows for sure this is a trick because even though Bob now has two keys for Alice, one of the keys has been signed by multiple people (himself and Alice) verifying that it does indeed belong to Alice, while the other key - Cathy's fake key - only has its own signature.
The above example is very simplified and things can get a lot more complicated than that. You can read through the PGP FAQs or a good book on PKI for more information and a more detailed explanation. The above example does clearly explain the basics of key signing and its value. Cathy was not able to introduce a fake key pair for Alice because of the web of trust interconnections between Bob and Alice.
However, signatures and webs of trust do not guarantee trustable keys. For example, when Bob and Alice first met Cathy, lets say that a friend of Cathy's, Donald, had been with Cathy. Donald could have generated fake key pairs for Alice and Bob, signed them with his key and signed both pairs of keys with the other pairs resulting in three signatures on each key and sent them to Cathy. Cathy would be facing a series of bad keys and signatures. How could key signing help Cathy resist such an attack? Well, let's say that all the people involved were exchanging keys through a key server. If Cathy searched the key server for Alice and Bob's keys, she'd find two sets for both Alice and Bob. If Alice and Bob collected twenty key signatures at the keysigning party, it's obvious that Cathy can better trust the public keys signed twenty times than the ones signed only three times. Cathy should know something's up from the existence of the extra public keys - so she can look for closely at the generation dates and the trust web behind the public keys. The twenty keys from the party signatures should all be signed twenty or more times and have widely varying generation times, most likely all the keys which signed Alice and Bob's keys were also signed by other keys. That would not be the case if Donald had generated twenty faked key pairs and generated a faked web of trust.
1.5 Why should I hold my own key signing parties?
There are three primary reasons to hold as many key signing parties as you possibly can.
First, and perhaps most importantly, you should hold as many key signing parties as possible in order to expand the web of trust. The more deep and tightly inter-linked the web of trust is, the more difficult it is to defeat. This is of special significance to the Free Software Community, both developers and users alike. Members of the community rely upon PGP technology to cryptographically protect the integrity of their software packages, security advisories, and announcements. The strength and robustness of the web of trust is directly proportional to the strength of the protection PGP provides the community.
Second, key signing parties help others get integrated into the security culture and encourage them to gain an understanding of PGP and related strong cryptography technologies. In order to get the benefits of strong cryptography, people must use strong cryptography, and use it properly.
Finally, key signing parties help build communities. They help techies get together to get to know each other, network, and discuss important issues like civil liberties, cryptorights, and internet regulation. Discussion is important because discussion is not only the first step, but also the step before action. At the time I'm authoring this document there are not very many complex webs of trust in the world. If you work to build a web of trust in your local area, it is very likely that the first participants in that web will be the leaders and policy setters of the internet community in your area. They are the individuals who can choose to build secure strong cryptographic technology and protocols into the local infrastructure if they so choose. The integration of such technology and protocols could make issues like the FBI's carnivore system technologically infeasible and therefore moot.
It's not very difficult to organize and coordinate a key signing party. However, aside from the regular tasks of inviting people, picking a location and setting a time, the Coordinator does have some other key signing specific responsibilities. Those usually include providing a key list for each participant and determining the structure of the party.
2.2 How should the party be structured?
There are two primary ways that a PGP key signing party can be structured -- in a centralized way or in a decentralized way. The best approach to the key signing can be determined by the number of people that will be attending and the atmosphere of the location where you're holding your party. The basic requirements of the party are that the participants are able to verify each others' keys and that the the participants are able to verify each others' identities. Given that those basic requirements are met, the coordinator can come up with some variation of the two types.
A centralized party would be a more organized affair which would work well with small to medium numbers of people. The participants would send their key information to the coordinator who would compile it into a list. Each participant, upon arriving at the party, would be given a copy of the key list. Each participant would then be called on by the coordinator. The participant would then check their key fingerprint against the fingerprint on the sheet that the coordinator gave them. If the participant is sure that their key is the same as the key on the sheet then the participant would read their fingerprint aloud so that the other party participants can make sure they also have the correct matching fingerprint. If they do in fact have the correct matching fingerprint, they check it off on their sheet. This is necessary to make sure that the coordinator has not made a mistake in the generation of the sheet or has not slipped a sheet with faked key information to one or more of the participants. After everyone has checked off the participant's key, the coordinator then calls on the next participant, and so on. After all of the keys have been verified, the participants and coordinator are asked to form a long single file line while holding their IDs in front of them. The person at the head of the line walks down the line and checks each person's ID. If their ID is correct and the person walking down the line has a check next to the individual in the line's key verifying that they had said it was their key at the beginning of the party, he places a second check mark on his list. Once a key has two check marks it can be signed.
A decentralized party would basically be every man for himself. Participants are expected to mingle informally and find other participants who's keys they have not signed yet. Upon meeting they verify their keys on each other's lists and validate each other's ID. Decentralized parties allow many more people to be easily included but also have the down side of making it easy for some participants not to validate each other's keys for future signing. At a decentralized party, it is important for the coordinator to encourage everyone to make sure that they do meet with everyone else for key validation. While a list of keys and fingerprints does not necessary need to be produced for a decentralized party, it is still good practice.
Centralized parties are great for key signing parties at conferences during lunch, informal quiet meetings at some one's home or a restaurant etc. Decentralized key signing parties are much more practical for parties that will include a very large number of people, take place in a bar or other noisy area, or parties including particularly rowdy and difficult to control geeks.
The larger the party the better. You can announce your party to your local LUG email list, other computer related lists you're on in the area, even place an ad in the news paper or issue a press release.
If you're just starting to build the web of trust in your area, it's a good idea to try and get other active PGP users involved because they are the ones who are most likely to hold key signing parties of their own in the future. Good ways find such people are to talk with others who've sent email to lists you're on with PGP signatures, or by searching the keyserver networks for keys with email addresses specific to your local area. For example, email addresses that end in the domains of a university or large company which are located in your area often yield very high numbers of interested parties.
Here are some sample announcements:
If you're going to use a party structure that calls for the participants to have lists of the keys of everyone attending the party, the coordinator needs to generate such a list. This list should be compiled in a format similar to this:
| Key ID | Key Owner | Key Fingerprint | Key Size | Key Type | Key Info Matches? | Owner ID Matches? |
|---|---|---|---|---|---|---|
| 992A4B3F | V. Alex Brennen <vab@cryptnet.net> | 0EC8 B0E3 052D FC4C 208F 76EB FA92 0973 992A 4B3F | 1024 | DSA |
I wrote a perl script to generate an HTML document in the style of the above table from a gpg keyring. The perl script to generate a key signing party key list is available under the terms of the GNU General Public License (GPL).
A copy of the key list should then be printed out for each of the people who will be attending the key signing party. The coordinator can print the copies of the list himself, or he can email the list or place it on the web for the attendees to print.
2.5 Graphing the resulting web of trust
Nothing gets people's interest peaked like colorful graphics. Therefor, graphing the web of trust in your local area as you build it can help motivate people to participate as well as giving everyone a clear sense of what's being accomplished as things progress.
You can very easily create a graph of all of the keys and signatures in your web of trust by converting that information into a dot file which can be fed into a graphing program like dot or neato. A perl script which converts the keys and signatures in a keyring to a file in the dot format was written by Darxus and is also available under the terms of the GPL. In order to graph the web of trust you'll need to download Darxus' sig2dot.pl script and the graphviz package from AT&T Research. You may not be able to graph a web of trust with more than a few hundred nodes due to the amount of memory needed to perform such an operation.
Instructions for graphing the web of trust in a gpg keyring are included in the sig2dot.pl script, or can be found on the Debian keyring graphing page. Again, here is a link to view a graph of a web of trust which was produced with the sig2dot.pl script and the neato graphing program. More information is available from the Debian keyring graphing page.
3.1 The participant's role summarized
3.2 What participants should bring to the party
3.3 What Participants Should Not Bring to the Party
3.4 Why you should not bring a computer to the party
You should not bring a computer to the party because binary replacement or system modifications are very easy ways to compromise PGP systems.
If someone were to bring a portable computer and everyone used that computer to sign the other keys at the party, no one would know if the machine had been running a key stroke logging utility, a modified version of GPG,a modified version of the Linux kernel, or a specially modified keyboard, any of which could be used to capture the secret keys of those who used the computer.
The use of a computer at the party would also leave you open to more simple attacks like shoulder-surfing, or more complex attacks like weak secret key generation, secret key modification, or even infection with virii that modify your GPG binaries to leak future secret keys discretely.
3.5 How to generate your key pair
The process of generating a key pair is rather simple. Basically,
you just need to run gpg --gen-key. However, I recommend
that you also generate a revocation certificate for your key in case
you ever loose access to your secret key (i.e. loose your passphrase
or loose your secret key). The instructions for generating a revocation
certificate can be found in section 3.7 of this
document.
The step-by-step instructions below were written with practical usage and sufficient security in mind. For example:
Some people may be comfortable with out taking all of these security precautions. For example, if you have a portable computer or a home computer which you read all of your email from, you may feel comfortable enough to store your key on the hard drive of that computer. You may also feel comfortable generating a key pair which never expires which you can use for identification and most communications - then generating additional key pairs for extremely sensitive communications (should you have any). Again, the step by step instructions below were written with best practice security in mind. You don't necessarily need to follow them, you just need to generate a keypair. On the other hand, if you are an extremely paranoid security freak like me following the directions below will temporarily provide you with that swiftly fleeting sense of calm that you so need to feel right now.
The step-by-step instructions below were written with best practice security (severe paranoia) in mind. For example:
1) Go to www.gnupg.org and download the latest version of gnupg: gnupg-x.x.x.tar.gz
Warning: Make sure you're running at least version 1.0.6 of GnuPG. Versions prior to 1.0.6 had at least one significant security weakness in them.
2) Check the PGP signature and the MD5 Checksum on the GnuPG archive:
bash$ gpg --verify gnupg-x.x.x.tar.gz.sig gnupg-x.x.x.tar.gz
bash$ md5sum gnupg-x.x.x.tar.gz
3) Extract the archive, configure, compile and install it:
bash$ tar xvzf gnupg-x.x.x.tar.gz
bash$ cd gnupg-x.x.x
bash$ ./configure
bash$ make
bash$ su
bash# make install
bash# exit
bash$ cd
If you share the system you're install GnuPG on with others, you may also want to make gpg setuid root so that it can use secured memory. If you do choose to do this, you should take precautions such as checking your archive with the md5 signature and the pgp signature to make sure you're not installing a trojan horse.
4) Get a floppy to store your keys on and format it.
bash$ /sbin/mkfs.ext2 /dev/fd0
4a) Mount the floppy and make a directory on it owned by you for your keys:
bash$ mount /mnt/floppy
bash$ mkdir /mnt/floppy/.gnupg
and if necessary (depending on fd0 access on your system):
bash$ chown <your_uid>:<your_gid> /mnt/floppy/.gnupg
4b) Make a symlink from your home dir to the floppy
bash$ ln -s /mnt/floppy/.gnupg .gnupg
5) Generate your gnupg keys
bash$ gpg --gen-key
5a) Select the key types you want - The default is good.
Please select what kind of key you want:
(1) DSA and ElGamal (default)
(2) DSA (sign only)
(4) ElGamal (sign and encrypt)
Your selection? <return>
5b) Select your key size: 2048
DSA keypair will have 1024 bits.
About to generate a new ELG-E keypair.
minimum keysize is 768 bits
default keysize is 1024 bits
highest suggested keysize is 2048 bits
What keysize do you want? (1024) 2048<return>
Do you really need such a large keysize? yes<return>
5c) Set the lifetime of this key: 5 years is good
Requested keysize is 2048 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 5y<return>
Key expires at Sun Sep 21 16:17:15 2005 EDT
Is this correct (y/n)? y<return>
5d) Enter your name and email address(es)...
Real name: Demo User<return>
Email address: demo@nonexistent.nowhere<return>
Comment:
You selected this USER-ID:
"Demo User <demo@nonexistent.nowhere>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O<return>
5e) Choose a pass phrase. You need to pick a good one. It should be long and very difficult to guess. It should be something you won't forget. If you forget your pass phrase, you cannot recover your key.
5f) Move the mouse and hit some keys maybe update locate in the background or run a big find. GPG is reading from /dev/random to get some randomness for your key generation. /dev/random is populated in part by interrupts.
6) Modify your key if you want. For example if you have multiple email addresses and you want to list them as valid on your key:
bash$ gpg --list-secret-keys
/home/demo/.gnupg/secring.gpg
----------------------------
sec 1024D/C01BAFC3 2000-09-21 Demo User <demo@nonexistent.nowhere>
ssb 2048g/7A4087F3 2000-09-21
bash$ gpg --edit-key C01BAFC3
Command> help
Command> adduid
[...]
Command> save
7) Send your key to the keyserver:
bash$ gpg --keyserver <keyserver> --send-key <Your_Key_ID>
You should see a success message like this:
gpg: success sending to `<keyserver>' (status=200)
3.6 Sending your public key to a keyserver
It's important to note here that some people believe that keeping their public key secret adds an extra degree of security to their encrypted communications. This is true, because a keyserver could be broken or compromised and return the incorrect public key when queried. Further, the key on a given public keyserver may not be the most up to date version of the key. For example, additional signatures may have been added to the key which have not been propagated or uploaded to the keyserver. It is also true because the public key of a key pair is needed to carry out certain types of attacks against the public key cryptosystems which pgp uses. While many people expect, with reasonably large keysizes, that these attacks are so extremely unlikely to be successful that is does not matter if the public key is broadcast, keeping the public key secret does in fact strengthen the key pair.
I don't recommend that you keep your public key secret as it will discourage others from using PGP in their communications with you. To address the issue of the possibility of a compromised or broken keyserver returning an invalid key you can take steps to protect yourself from having messages sent to you encrypted with invalid keys, such as publishing your key's fingerprint in your .signature file or on your web page. To address the concern about the attacking of your key pair though your publicly available public key, I would say that if you are very concerned about the strength of your keypair or truly paranoid about the secrecy of your communications, you could generate additional keypairs (which expire in a matter of hours or days) for each communication and exchange the public keys of those keypairs though encrypted communications with the individual you'll be communicating with.
If you don't wish to have your key on a public keyserver, you should skip this step and instead email your public key to the keysigning party coordinator with a message stating that you don't want your key on a public keyserver. The coordinator can then extract your public key information and forward your key on to the other participants via encrypted e-mail, or some other method, along with a note stating that the key should be returned to its owner after signature rather than uploaded to a keyserver.
3.7 Generating a revocation certificate
This is an optional step.
The generation and storage of a revocation certificate will allow you to revoke your public key even in the event that you loose access to your private key due to compromise, seizure, forgotten passphrase, or media failure. If you want to have the ability to revoke your public key when you do not have access to your private key, you should generate a revocation certificate and store it a secure and safe place. You should also print out a copy of your revocation certificate so that it can be entered and used in the event of the failure of the media it is stored on.
If you revocation certificate is compromised, the individual who compromises your revocation certificate will be able to circulate the certificate thereby disabling your key. However, the individual will not be able to compromise your secret key through his access to your revocation certificate. Therefor, they will not be able to generate fake signatures, decrypt messages encrypted with your keypair, or otherwise misrepresent themselves as the owner of your keypair. Since the only negative outcome possible from the compromise of a revocation certificate is the disabling of your keypair, it is a generally safe and good thing to do.
Section 3.9 contains more information about key revocation.
The GnuPG command to generate a revocation certification is:
bash$ gpg --output revcert.asc --gen-revoke <key_id>
9) Email your info to the Coordinator telling him that you're coming to the key signing party. The command below will print out the information that you want to need to send to the coordinator if you're using a keyserver. You can then send that information in an encrypted email message to the coordinator.
bash$ gpg --fingerprint <Your_Key_ID>
10) Unmount the floppy and eject it:
bash$ umount /mnt/floppy
Note: You can carry the floppy around with you for additional security, or you can just leave it in a safe, locked desk drawer etc. You DO NOT want to have your .gnupg directory containing your keys in a location accessible over the internet.
11) Show up at the party.
Step 1: Get a copy of the key
Normally, you'll be working from a keyserver. However if
you are signing the key that is not available on a keyserver,
you can use simply import the key with gpg --import.
If you are working with a keyserver, the following command will
download the key from the keyserver into your public keyring.
bash$ gpg --keyserver <keyserver> --recv-keys <Key_ID>
If you get a read error, it means the keyserver is overloaded. Please, try again in a few seconds.
Step 2: Fingerprint and Verify the key
bash$ gpg --fingerprint <Key_ID>
GPG will print out the fingerprint of the Key with <Key_ID > (the key you just downloaded). Check the fingerprint against the checklist that you were given at the party. Note: Don't check the fingerprint on your checklist against the fingerprint on the web page as the server may not send you the same key it displays on the web page.
Step 3: Sign the key
bash$ gpg --sign-key <Key_ID>
If you have multiple private keys, you can specify which of your private keys to sign the other persons public key with like this:
bash$ gpg --default-key <Key_to_use> --sign-key <Key_ID>
If you have trouble dealing with RSA keys, you're probably using an old version of gnupg. Versions of GnuPG older that 1.0.3 do not include RSA support. Note: You may have to uninstall an older version if your distribution installed it with package management software. You can check the version you're executing like this:
bash$ gpg --version
Step 4: Return or Upload the signed key
If you are working with an entity which does not want their key on a public keyserver, you should at this point you should return their signed key back to them by their method of choice - normally encrypted email. You should not send a public key to a keyserver with out the permission of the key's owner. Publicizing a public key slightly reduces the security of a key pair, therefor it is considered rude to make a key more public than its owner desires.
Most likely you are working with a keyserver. If that is the case, you can send the signed key back to the keyserver like this:
bash$ gpg --keyserver <keyserver> --send-key <Key_ID>
You should see a success message like this:
gpg: success sending to `<keyserver>' (status=200)
Congratulations, the signature of the other entity's key is now complete and your signature has been incorporated into their public key. A trust path has been established.
In the event that you suspect that your secret key has been compromised, you should revoke your public key immediately. Key revocation takes place by the addition of a Revocation Signature to a public key. The revocation of a key suggests that a key is no longer valid (secure) and should not be used. Once a revocation certificate is issued, it cannot be withdrawn.
Since your PGP key is distributed (read circulated) to people rather than distributed from a central point every time it is accessed, you must circulate or distribute your revocation certificate in the same manner that you distributed your public key. The circulation of the revocation certificate in the same manner as the distribution of your public key would usually mean uploading the revocation certificate to the keyserver networks. If you had not uploaded your public key due to security considerations, you may still want to upload your revocation certificate to the keyserver. In this case you would be making a trade off between the slight reduction in security which results from having your public key publicly available, and the reduction in security which could occur from having someone potentially not realize that your key has been revoked.
In review, the gpg command to generate a revocation certificate is:
bash$ gpg --output revcert.asc --gen-revoke <key_id>
If you have an idea about how or when you key was compromised and you generated a revocation certificate during key generation, you will still likely want to generate a new revocation certificate to revoke your keypair. This is the case because the openPGP standard will allow you to specify the reason why you are revoking your keypair and even provide some free text comments about the reason for revocation. The circulation of a revocation certificate with this type of information is likely advantageous and preferable to the circulation of a generic certificate created during key generation.
Key - One or more bits of data used in the encryption or decryption process.
Key Fingerprint - In PGP, a value used to identify a key which is generated by performing a hash of key material.
Key Pair - In public key cryptography, a pair of keys consisting of a public and private, or secret, key which interrelate.
Keyring - A collection of keys. Most often this term is used in relation to PGP, where a keyring consits of a collection of one or more key packets.
Key Server - A system which stores key material in a database. These servers may be queried by users who wish to acquire the public key of a recipient they have not had prior contact with.
Keysigning Party - A get-together of people who use the PGP encryption system with the purpose of allowing those people to sign each others public keys. Keysigning parties serve to extend the web of trust.
openPGP - An open standard which defines a version of the PGP security system.
Pretty Good Privacy [PGP] - Privacy software developed by Phil Zimmermann, which includes public key cryptography, a standard packet and key format, and symmetric encryption as well.
Public Key - In public key cryptography, the key of a key pair which is shared.
Public Keyring - A keyring consisting of Public Keys. This term is most often used in relation to PGP.
Radix - A method of encoding data so that it may be transmitted over a channel which only support 8 bit characters. For example, such a channel could be email or the Usenet.
Secret Key - In public key cryptography, the key of a key pair which is kept secure.
Secret Keyring - A collection of secret keys. Most often this term is used in relation to PGP where it defines a collection of secret key packets.
Trust Path - A route by which trust is extended from one entity to another. In PGP, this is a link of trust between two public keys.
Web of Trust - The collection of signatures upon keys and resultant trust paths in a user centric trust model which provide for authentication. Collectively, the trust relationships between a group of keys.
5.1 List of public key servers
5.2 Links to related documents
5.6 Pictures from keysinging parties
Copyright (c) 2000 - 2003 V. Alex Brennen.
Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.1 or any later version published by the Free Software Foundation.
This document lives at http://www.cryptnet.net/fdp/crypto/gpg-party.html
Version 1.0.0, 2000.10.01 Initial Release.
Version 1.0.1, 2000.10.03 Format/Writing changes, private public keys info.
Version 1.0.2, 2000.12.07 HTML (Bad Link) Fix.
Version 1.0.3, 2001.01.14 Simplification revisions, graphing, keyserver security/etiquette information, perl code, announcement examples, additional material, and general fixes.
Version 1.0.4, 2001.06.21 Revocation information added: 3.5, 3.7. RFC info added: 4.4. Keyserver list and web site links updated.
Version 1.0.5, 2003.03.24 Glossary Added: 4. Pictures Added: 5.5. Minor corrections, additional material, and formatting changes.
Version 1.0.6, 2003.03.24 New Content: Zimmermann-Sassaman Method, Brennen Method. General document clean-up.
Version 1.0.7, 2003.05.07 Added German Translation
Version 1.0.8, 2003.05.09 Added Section 5.3 Related Programs
Version 1.0.9, 2003.11.20 Added Spanish and Italian Translations
Version 1.1.0, 2003.11.26 Added Traditional Chinese Translation
This document is currently only available in the following languages:
[en] English (Local Mirror)
[de] German (Local Mirror)
[es] Spanish (Local Mirror)
[it] Italian (Local Mirror)
[zh-TW] Traditional Chinese (Local Mirror)
[si] Slovenian (Local Mirror)
If you know of a translation or would like to translate it to another language please let me know so that I can distribute or link to the translated versions.
V. Alex Brennen (Principal Author)
Darxus (Graphing Code (sig2dot.pl & sigtrace.pl))
Bostjan Muller (Slovenian Translation)
Gerfried Fuchs (German Translation)
Alex Bergonzini (Spanish Translation)
Cristian Rigamonti (Italian Translation)
chihchun clotho fetag Jedi kcwu pwchi winfred (Traditional Chinese Translation)
