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
