Distribute

Problem with Trust

Across internet, when we say "we genuinely trust this information", exactly based on that do we measure or proof our claim? That's the problem. There isn't a solid way to prove an information is genuine. Service access is easily obtainable via various hacking techniques like phishing, social engineering etc. You might be surprised, even the technical experts can't 100% guarantee a system is safe and secure. Check this comic out from XKCD:

So, in situation says, your Twitter, was illegally accessed by your nemesis and he/she posted hate speeches in it and went up to news channel. Luring everyone's attentions, you tried to explain you got hack but you have 2 problems:

• How to proof you got hacked?
• How to proof those hate speeches weren't yours?

and the doubts goes on between your unintended audiences and you.

Current Trust Process

So how do we formalize and unify them? In our physical world without computers, to keep things simple:

1. We write formal documents
2. Have both parties sign them
3. Have the signed document legally bind through government entities
4. Store them in your own safety box (be it your house or bank)

In case #2, when a dispute occurs, we hire lawyers to do:

1. Obtain warrant (or access document) to get and to read the signed document from the safety box.
2. Verify the signature integrity (usually via government bodies like Department of Statistics/Registrations/Immigration)
3. Testify owner's statement (for recognizing the legal binding)
4. Proceed with discussion.

In case #3, when a document is lost from one side, we do:

1. Acknowledge and declare the loss via recognizable channel (e.g. Police Department / Mass Media)
2. Request counterpart for a duplicate copy.
3. Obtain warrant (or access document) to get and to duplicate the signed document from the safety box.
4. Verify the signature integrity (usually via government bodies like Department of Statistics/Registrations/Immigration)
5. Duplicate the document and certify the copy.
6. Store them back to safety box.

Now, if you notice, in every cases, we relies on a minimum of 5 things to manage a genuine trust:

1. Both parties must sign the document with their respective signature.
2. Relies on a 3rd party to perform legal binding onto the document (and acts as a witness)
3. Testify and recognize the binding.
4. Signature is recognizable across various entities (both parties, government's departments, anyone (lawyers)
5. Ideally, re-create the signature is uniquely known to an individual only.

Even it is imperfect, it does keeps the world going till today.

Digitizing Trust Management

Hence, a group of tech talents digitized the trust management processes using the existing symmetric encryption technologies. This is where the Pretty Good Privacy (PGP) technology is born. Later on, it inspired the open-source version, GnuPG. PGP uses the same process but works in the digital world:

1. Your signature public key is your signature
   • You need to get is recognized across various entities.
   • You need to declare and testify that it is the only one signature key.
   • Only you know how to re-create the public key.
   • Relies on either a centralized or decentralized 3rd parties (key servers) to hold and perform "legal" binding.
2. Your secret key is your way to recreate your signature
   • You don't teach others to sign your physical signature. You keep it secret to only yourself.
   • For obvious reason, just like how to sign your own physical signature, you should keep the secret key with highest level of secrecy.

Keep in mind that, not all government recognize PGP signatures. I'm not a lawyer so be warned: you should always check with your lawyers related to proper legal binding in your country before using it on your official document. Remember, the current primary goal is to inspect information genuineness, not for our day-to-day official document use....yet.

Since we can use the existing tools to recreate the trust management process, we need to ensure the keys we created serve their functionalities. In this case, since we need to get our public key recognized by various entities as easily as possible, as many as possible. Hence, in this section, we learn how to distribute the public key.

Distribute through Decentralized Channel

This is where you publish your public key via your own website or send via email. It does not depend on any 3rd party entity (example, government department) to share your public key with your recipient.

How to Do It

1. Export the public key of your primary key into a keyfile
   • If you're sending via text-only channel, like email, you would want to use --armor argument.
2. Send the key file through a trusted channel between you and your recipient
   • When I say trusted, it means something as similar as:
     • face-to-face exchange
     • a secured communication system like Signal, etc.
3. Import the certified keyfile
   • This is where you import each other's public key, sign them (formal recognition step), and return a copy back to the owner.

The Pros

1. Convenient.
2. You have full control.
3. No dependencies.

The Cons

1. It can be technically struggling to merge multiple signed keys without understanding how the technology works.
2. You need to verify your channel is secure for key transmission.
3. Manual efforts to merge all the signed public keys.

Distribute through Centralized Channel

Another publish your public key via recognizable key servers between you, your recipient, and the world. It manages the signature recognition at one place. This makes it easy for anyone to obtain your public key, sign on it and return back to the key server without depending on you.

HOWEVER, there is a problem: there is no centralized "government" in the internet. Therefore, anyone can host his/her own PGP key server. There is a huge list of key servers made available by internet bodies. All you need to do is to choose the most used version and publish your key there.

These servers are smart enough to organize your public keys. Upon receiving the signed key from various entities, it knows how to merge them so you don't have to do it manually.

How to Do It

1. Get a key server URI
   • You can get one from the list. The commonly used servers are:
     • hkp://p80.pool.sks-keyservers.net:80
     • hkp://pgp.mit.edu:80
     • hkp://keyring.debian.org:80
     • hkp://keyserver.ubuntu.com:80
2. Use the --send-keys <key-ID> and --keyserver <URI> arguments together to send your key. Keep in mind that --keyserver <URI> argument comes first.
   • Command: $ gpg --keyserver <URI> --send-key <key-ID>
   • Example: $ gpg --keyserver hkp://pgp.mit.edu:80 --send-key 1F6E1C8C1F1A3458A267EEFD445AC05FC0F56EA9

The Pros

1. Centralized trusted body.
2. Easy to exchange signed public keys.
3. The key-servers smartly merge all the signature for the received public key.

The Cons

1. The server are occasionally unavailable due to high traffic.
2. You have partial control over your public key (no delete, but revoke).
3. Exactly which server is commonly used?
4. How many server do we push to? [1 is usually enough]

That's all about distributing your GnuPG keys. Remember, ONLY distribute your PUBLIC key, regardless whichever channels you're distributing through.