GPG: Encryption and digital signature for the masses

Disclaimer: This is a very serious topic. The observations made here are for a starter. Kindly refer to the man pages and other text books which specialize in guiding for advanced and high stake uses. I am not responsible for any unwanted results by following the notes below. Understand the seriousness of the job on hand and read enough. 

     The notes below are culled from the public network from various sources. Thanks to the free software foundation for the fantastic gpg tool and all the original authors of the pgp standard. GPG is really "encryption" for the masses. Kindly refer to directions from master users for creation and usage of GPG. The recommended way of creating a key pair is on a computer with

1. The operating system to be installed with images downloaded and checked for the integrity of the OS image on another computer connected to the internet.
2. Install the downloaded operating system on new vanilla hardware and the computer should not be connected to the internet even while installing the OS.
3. After installing the OS generate the keypair ensuring that the computer is in now way connected to the public network.

Even if you dont want to create the keys in the way mentioned above. It is required to know the above information.

--------------------------------

    Private key cryptography and symmetric cryptography are the same phrases. They are just a complicated way of telling that the cipher and key used for encrypting a message is the same that has to be used to decrypt the message. That is, the cipher and the key is first shipped to the recipient. Then the actual encrypted message is sent.

Public key cryptography/asymmetric cryptography:

    A mathematical process generates a pair of keys. A message encrypted by one key of this pair, can be decrypted by the other key of this pair. One key is called the public key(can be shared with the whole world) and the other is called the private key or the secret key(Not to be shared with "anybody").

How asymmetric cryptography works:

 
    Let us assume the data of individuals in the whole world is maintained in a database with their respective public key. So we pickup the name and the corresponding public key on this database(provided we know this is the person whom we want to communicate). Now

1. we create a message which is to be sent to "only" this individual.
2. we encrypt this message with the public key available in the database.
3. send the message to the individual through the public network, by means like email ....
4. The recipient will then decrypt this message with his private key
5. No individual in the world will be able to decrypt this since the message can be decrypted with its pair which was generated by the mathematical process which produced the public/private key pair

-------------------------------

Creating and managing gpg keypairs

Let us now get down to "actually" creating the key pairs. We will be using GPG(GNU Privacy Guard). Kindly refer to the man pages for further information and the public network for deeper insights. GPG is a common on all the *nix operating systems and is available for the proprietary operating systems also.

The first step is to generate a key pair. Run the following command

gpg --full-generate-key

On running the above command in a terminal you will be asked the following queries. Answer accordingly.

a. Choose the type of key: We will choose the default RSA
b. choose the bits for your key: Let us choose the longest option(We are in modern times)
c. Expiry date: I would go for an yearly update
d. Real name: Here you have an option of putting your real name(You can ofcourse not tell your real name. But, to use it in place like github etc, it is better to have your real name)
e. Email address: The same logic as above is applicable here also
f. There is a comment field: You may fill it up or recommended by many people to leave it empty

After the above step gpg asks to enter your passphrase. 

This is a very "important" step. The passphrase is intentionally called a "phrase" it is not called a password. This has to be as long as possible. It is better if it has a mixture of alphanumeric characters interspersed with special characters like @%(%$) etc. It has to be sufficiently long. This is what protects your private key. Please use a long phrase, which you can remember very easily and quickly. In fact you should be flamboyant when your are typing out your phrase. At the same time that phrase should be alien to anybody else on the planet.

Once you enter the passphrase, gpg starts the mathematical part required to generate the key pairs. Help out with sufficient entropy(randomness) by opening lot of firefox tabs, plenty of word processors and go ahead and do whatever work you want to do with your computer. This improves the entropy required to ensure the randomness of the digits generated for your key.

Once you generate the keys, the keys are stored in what is called a "keyring" Just know that the keys are safe in a box and locked by your passphrase

To print out the public key which was generated

gpg --list-key

To get the public key in a format which is accepted worldwide

gpg --export --armor dfdf@fdfd.com > dfdf_pubkey.asc

To display your public key
 

cat dfdf_pubkey.asc

Once this is generated, you can share it with the world. If your friend wants to add your public key to his keyring, then he would

gpg --import dfdf_pubkey.asc

There, now he has your public key in his keyring.


To list the private keys

gpg --list-secret-keys   

Now it is required to generate a revocation certificate. Why are we in such a hurry in creating one. Well, we should have the revocation certificate handy, if the keys have been compromised and you think that the keys can be used by others to gain access or sign documents with your keys and send it to inappropriate places. With revocation certificate you can revoke the key pairs and also tell the whole world about it so that the whole world knows that there is no relationship with your previous sets of keys. The latest version of gpg creates a revocation certificate during the key pair creation process itself, fantastic.

gpg --gen-revoke fdfd@dfdf.com > fdfd_revoke.asc

Now you will be asked for the reason. Choose the appropriate reason.

The file you created is called the ASCII armor file.

So, we have created the revocation certificate. This certificate will be used to revoke our key pairs.

gpg --import revoke.asc

Now if you run

gpg --list-key

You will get your public key information with "revoked" added

Now you can really delete your key pairs

gpg --delete-secret-keys fdfd@dfdf.com

gpg --delete-keys fdfd@dfdf.com

Now if your list your keys

gpg --list-key

The output will be empty

Let us now remove the revocation certificate also

rm fdfd_revoke.asc

-------------------------------
 

Encryption

Let us now encrypt and share some secret documents with friends on the public network

To start with you should have

1. Got the public key of your friend.
2. Import the public key into your keyring.
3. Did your homework to ensure that the public key does indeed belong to your friend.

We have done the homework and are sure thatthe public key shared by your friend is genuine. Let us now go ahead and trust the public key by signing your friends public key with your private key

gpg --sign-key friend@friendship.com

Now, to encrypt the document and ensure that the only recipient who can decrypt the document is your friend,

gpg --encrypt -r friend@friendship.com secret_document.txt

The command will output secret_document.txt.gpg which is a binary file

If you prefer the ascii armor format

gpg --encrypt --armor -r friend@friendship.com secret_document.txt

which would output secret_document.txt.asc again a binary file.

You can now send this document through any channel available on the public network and are assured that your friend with whose public key the file was encrypted can only decrypt it with his private key. From now on, if you, the author have deleted the original secret_document.txt also cannot decrypt the resultant file secret_document.txt.gpg.

To avoid this you can add yourself also as a recipient

gpg --encrypt -r friend@friendship.com -r fdfd@dfdf.com

Now, you the author with email id fdfd@dfdf.com can also decrypt the file as and when required and can safely now delete the original file

-------------------------------

Digital signature

We have all the way been talking about encrypting a document. We want to ensure that the document reaches and is ready only by the individual(s) to which it was intended. This is fine. Let us forget encryption for a moment and think of a public document. Anyone reading a public document should be ensured that this particular document is an un-altered copy authored by a particular person. The document should be able to speak about the author. That is, the document should be signed by the original author. This ensures the reader that the document is an un-altered document and is as was imagined by the author. We are talking a synonymous situation of physically signing a document. We are talking about an electronically signed document.

gpg allows us to do this. When we are signing a file we are not encrypting the file, we are just creating a binary file with contents of the signed file as well as information about our signature. The signing and verifying methodology described below makes use of the fact that the signed file has the contents of the signed file as well as the signature in one single file.

 When gpg signs a document there are two things which are ensured

1. Integrity: When the recipient checks for the signature authenticity and it matches, it also means that the signed document received is not altered in any manner

2. Authentication: Again, when the recipient checks for the signature authenticity and it matches, it also means that the document is indeed from the person who really sent the message by signing with his private key

gpg --sign document.txt

This will create document.txt.gpg, a binary file which includes the content of document.txt and the signature.

Before creating the .gpg file, you will be asked to enter the passphrase, Now, you have affixed your signature on the document. This process makes use of your private key. So, as per the pgp convention, if you encrypt with one part of the key pair, the other key pair is used to decrypt the document. Now, since you have added your signature to the document with your private key, the confirmation of ownership can be done with your public key. Since your public key is supposed to be public, anybody, with access to your public key will be able to ensure that document is created by you. However, the world can view the document by using gpg --decrypt as discussed below and view it but not ensure that the document was really signed by you and you are the creator of the document 

Now, on receipt of the file, the recipient to start with, will first check for the authenticity of the signature. This is done by

gpg --verify document.txt.gpg

The output will show the signature and will term the signature as good, if you have the public key of the sender in your keyring. So we now have attested that the file infact, is created by the creator we were expecting.

Now to proceed to view the contents of the document, let us decrypt it, ie, let us bring it back to viewable state.

gpg --decrypt document.txt.gpg >> document.txt

The above step will still re-create the original file though the authors public key is not present in the keyring. gpg will just tell that the signature cannot be verified.

I think you are used to seeing signed documents with an armor ascii format. To achieve this

gpg --sign --armor document.txt

This will generate document.txt.asc, a binary file which includes the signature in armor ascii format with the contents of the file

To verify the file and as well as decrypt

gpg --verify document.txt.asc >> document.txt

Once you trust the public key and are sure that the public key indeed belongs to the individual you know, that trust can be extended into your keyring by signing the author's public key with your private key. This can be checked in various ways. If we know the author and his online activities, we could go to the place he is most active and check for his email credentials with his pgp fingerprint on that website. Or we could go to the many pgp key servers over the public network and search for the fingerprint or the email id in the fingerprint. It should match with the copy of the public key we have. Once you are content that this is the person associated with the key, then and only then change his public key in your keyring to trusted. This will remove some warnings when you check the signature of the files from the author which talks about "...Not certified with a trusted signature...". To do that

gpg --sign-key author@creator.com

After this when you verify the signed files received from the author by

gpg --verify document.txt.gpg

you will not find any warnings

Down the line, by some means you start doubting the public key and the associated individual it is time to revoke the "trusted key" status in your keyring. Now the thing is once you create add a key in the keyring, any further edits are possible only from within the gpg command. Here we are interested in removing the trust from the public key. So you would start the gpg editor like

gpg --edit-key author@creator.com

Now you will get the gpg> prompt
Enter "help" to get all the options. Here we are interested in revoking the trust we put in the above public key
type revsig at the gpg prompt
You will be prompted for the reason, answer accordingly. Exit and save when prompted. Now, you have successfully removed/revoked the "trusted" badge from author@creator.com
 

----------------------------------

Digital signature for special case involving pure text files

 
If you are dealing only with text files. It will better if the text and the sign appear in the same file as a regular document. It is like you have a text document and you affix your signature to the end of the document. gpg provides this facility through

gpg --clearsign document.txt

will create a document.txt.asc

Now the recipient can open the file with

cat document.txt.asc

which will have the content of the document as well as the signature at the end of the document. Now, to verify the signature, the recipient would

gpg --verify document.txt.asc

Now, to get back the original document only, without the signature then the recipient would

gpg --decrypt document.txt.asc > document.txt

--------------------------------

Digital signatures for huge binary files

 
All this time we have been using gpg such that the contents of the signed file and the signature are available in the output file of the gpg command. This might not be conducive as the file sizes grow. It is better off to have the signature separate from the signed file. With this, the file and the signature are two different files. Just remember that to check the signature with the associated file both have to be in the same directory and the file names cannot be changed.

To create a signature separate from the signed document

gpg --detach-sign --armor document.txt

This will output a file document.txt.asc. (You still have your original document.txt unchanged). This file contains only the signature but is associated with the original file document.txt. This is the methodology used to share binary files and packages on the public network. You will have the package/software you would like to download and adjacent to that you will have

1. The signature (normally it will be labelled the pgp file)
2. The public key of the author

You download the above two along with the software package

1. Put all the three files in a single directory
2. Import the public key of the author
3. Sign the public key of the author with your private key after doing your homework about the authenticity of the public key
4. check the signature
5. On no warnings proceed with the installation of the package