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

Long live the freedom software movement

There have been many examples of organizations taking up GPLd code and trying to spin a business model around it(Let us call it organization A). The catch here is that the code is available in the public under GPL. If an individual or another corporation(Let us call it organization B) sees that the offering is costly and the terms offered are too stifling they still have the access to the same code. Let us say that that A has now sweetened the deal with improvements and additions to the code base and offers that as the premium to B. Now, B has the option of taking the improved deal form A or asking for A to give out the improvements to the original code base since the original code base was GPLd. This is where A loses its head. This is where A drops its towel. This is where many organizations understand that it is not a viable model.

But there have been examples of organizations making money out of GPLd software. The important ones coming to the mind is Redhat and Suse. At a time when even redhat didnt have a commercial offering, suse had only the commercial offering. All these people started working "around" GPLd software. They did not work much "on" the GPLd software. Whatever utilities they developed to wrap around the GPLd software making the users adopt GPLd software was aimed with ease of use and technical support and customization for the clients. This worked and companies were successful with this. The object of business is profit maximization. There are plenty of strategies to do it. The problems while doing business with GPLd software is the ethical dilemmas. You want to be true to the GNU philosophy and you have to maximize shareholders profits. As you start wanting more returns from GPLd software that is where you start spiraling down. That is where you are extracting blood instead of milk from the cow's udder. Now, the money you are making is blood money.

Now comes a biggie who thinks that he knows how to make more money from GPLd software and buys the smaller and a better ethical vendor. Without even having a plan to integrate the ethics and the working of this company. The integration plan is one of the most vital thing for a successful takeover. You decide whether you want the smaller firm to continue with its ethics or completely break it down and merge with your profit making culture. There is no road in between. Many mergers and acquisitions have failed because of this. For big corporations it is better you kill it totally like google or microsoft. Take out whatever assets that can be proprietarized and throw out the GPLd ones. The problem arises when you think of proprietarizing GPLd code. There might be plenty of code written by the acquired company under GPL. But just because you wrote it, you dont own it. It is in the GNU world.

Efforts are on to kill the free software movement. Efforts are on to destroy the free software foundation. Efforts are on to kill the GPL. And this time it is a totally co-ordinated effort from all the bigs. We dont know how it is going to end. But we know for sure that the GPL document has stood its test of time. It has been framed with the core human societal values at its core. It has not been framed for profiteering. It has been framed with the basic human ethic of "sharing". They all thought that they bring down RMS they bring down GPL. They are wrong. They should have done it the other way round, then it might have worked. But, now it is not working. People are sratching their heads. All their lawyers and PRs are working overtime to malign the GPL.

So, clearly now is the time to advertise freedom software. Now is the time for all the individuals and ethical groups to spread the word of freedom software. Now is the time to share. Now is the time to side with the free software foundation and identify the blobs in the free software foundation and replace them with GPLd code since we have already lost the Linux foundation for the blobs. Now is the time to start GPLd software. Yes they are not flashy, Yes they are not easy to use. Now is the time to make them flashy. Make them more usable. Make them more known to the public. Now is the time to celebrate the contributions of one and all made to the freedom software world. Now is the time to provide due recognition to all the developers who work both for earning and for human ethics. Now is the time to spread the names across the public network. Now is the time to dig out the the name sof the contributors on which all the proprietary world of software is standing. Now is the time to tell that Macos and ios are visual shells on BSD code. Now is the time to shout that the flashy PS4s are just an interface to the awesome BSD code. Above all now is the time I request all developers developing for fun for serious ethics to please release their code under GPL and not under any other permissive licenses.

As a long time GPLd software user, I salute all the freedom software developers and thank them from the bottom of my heart for providing the world an ethical alternative.

Long live GPL. Long live RMS. Long live the sharing ethos.

Meeting RMS at Mandya(Once in a lifetime opportunity), Karnataka, India

As I have written in many of my blog posts regarding my introduction to computing in 2002. No event affected me more than the reading of RMS's escapades with the printer at the AI laboratory. There was something about the philosophy being churned out in the help file withing the church of emacs. Now, maybe if i had tried editing my configuration files in vi I wouldnt have come across this philosophy of sharing. I still am not sure what prompted me to fire up emacs from my RH 6 machine. I finished the tutor and the was looking for further directions. It was at that time I read the about page on emacs. From that day I have been an ardent fan of RMS and his strict idealistic ideologies which is a mouthful for many an individuals who take sharing as sharing and nothing else. It is very difficult to understand him. He is egoistic. He is very strict on his beliefs and ideologies. I still remember when he last visited India and was interviewed by swapnil bhartiya. He did not drink bottled water until he got a bottled water not manufactured by coca cola. The reason being that he was against some un-ethical practises by the said company in some part of the world.


Let me come back to the present. I was damn lucky to meet him in person at Mandya, Karnataka, India. The event was organized by FSMK(Free software movement, Karnataka). I did not know that such a group existed and am indebted to their efforts in organizing this event. Now, how did I know about it. I am not on any proprietary social networks. I got the information on Mastodon. This makes my decision to stay on Non-proprietary online information sharing tools more interesting. This place, Mandya, is around 100Kms from my place. It was a 2 hour journey. I was present in the auditorium an hour before the stipulated time. There were announcements made to the attendees regarding the mentioning of Linux and GNU/Linux. He was on time and he walked in to a rousing standing reception. And the first one liner was shot. "Dont stand for me, stand for free software" He removed his shoes and started his presentation almost immediately. He did not want to waste a minute. He wanted to get right to the point almost immediately. The organizers were shocked at his speed. It took some time to get their bearings. After 10 minutes or so into his talk, The Indian way of welcoming the guest with a Mysore peta(Traditional cap of Mysore made with silk thread and a sandal wood garland) was done.


His homework regarding the local issues were excellent. He asked for "Mandya Gowdara Tea". Since there was a delay he was given tea made from Tea bags he had brought all along. He spelt the name of the language spoken in our parts perfectly i,e, Kannada(Majority of the Indians who dont stay in our parts spell it Kannad, which is wrong). The most striking was the parallel he drew of our freedom struggle with the present software freedom struggle. His say was that to gain freedom we have to embrace things which we are not comfortable. Freedom is not free. We have to work for it. In the Indian freedom struggle though the British flooded the Indian market with ready to wear clothes from Great Britain(Of course the raw material was from India). We as Indians fought against it by announcing swaraj, wherein we starting spinning our own textile raw material and stitching our own clothes from raw cotton. This was definitely not comfortable at all. But that is a cost we paid for gaining the freedom we cherish(or taken for granted) today. Excellent point. He used the word "Svatantra", the kannada word for "libre" instead of "Uchita" for "Free". RMS, I love you.


The talk and the content was standard. The freedoms associated with the software licensed with GNU GPL v3 and above and why all the developers should use this version particularly and also mention "GNU GPL v3 and higher" which would make the job of the FSF easy when faced with issues regarding copyright.


As usual, the Q&A is where he succeeds or fails miserably


There were questions regarding privacy, china government's mode of working etc which received long and boring answers. Let us cut back to the little interesting ones.


Q. I wanted to contribute to the FSF. When I opened the contribution page I saw that the amount of information I have to give before even entering the payment details was more than that required for opening an amazon account. The contribution process should be simple and as easy as clicking a button
A. Oh. I dont know about this. e-mail me the web page you are talking about. The payment cannot be as simple as a single click(It is for the reader to decide what is right or wrong about his answer)
Q. Wil the development of GNU os continue
A. No. It will not be developed. We had all the userland utilities and were lacking a kernel. Now we have the Linux kernel.
Q. What are the future projects of fsf
A. Oh, you can see our website regarding where the money comes and goes. librejs is being developed to remove the proprietary JS being used.
Q. What about building social networks. Like GNU social
A. Muffled answer.(I dont remember much)
Q. Free software conservancy hosted few videos on its website requiring proprietary JS implementation which if not enabled is not allowing to be viewed and fsf is one of the sponsor of the event of the video. Isnt it ethically wrong
A. I cannot keep track off each and every activity of the FSF.(summary I dont know and I am not going to anything about it)
Q. As a first time developer I am very interested in making money. How am I going to make money by giving my code away
A. (Unclear points) followed by You can work as a waiter for a living and then you can code in your spare time for the public good. If I did not have this job then I would have been a waiter to support what I am doing now.


Thank you,RMS, for everything you have done and will do in your endeavor towards pushing freedom software. Yes there will be fallacies, there will be pitfalls. But walking the talk is what matters. In a world where ethics are washed out at the drop of a hat, we have you, as a benchmark for the philosophic side of freedom software. I wish you would live for eternity, negating all the naysayers.