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

Arch GNU/Linux and OpenBSD on mac mini 2018, 2019, 2020(Intel processors)

     The laptop is not an ideal computer when you are sitting at the same desk and especially when you are at home. At home, the best computer would be a desktop. For the past 5 - 10 years I have been using laptop at home, but desktops at work. I observed that I have been killing the battery. I have my laptop always connected to the power supply and that is not good. Draining your battery just because you should drain it, though you are near to a power supply is not something which I can digest. For nearly an year used the raspberry pi 4 as a desktop and tried the frugal method of using a computer. I have been mighty happy with the direction the raspberry pi is headed. I loved what the rpi foundation is doing. It is the apple philosophy of making the hardware and software together but with freedom software ethics in place. Yes, there are still blobs being used, but the foundation is putting enough efforts to tend towards an open ecosystem of software and hardware. 

     Now, the thing with the rpi ecosystem is that you have to be abreast of the developments. If you use the bleeding edge software, you should be ready for the occasional glitches. Now, this is a problem, if you want to just start the computer and do an immediate task. Yes, if you run the debian stable, ie, the official rpi os, you are better off. But, the software is outdated for somebody who has been spoilt for using arch Gnu/Linux or Debian testing. Yes there are plenty other options for Operating systems. But, they all have something lacking. I have tried one and all. I have tried the ubuntu dev version, which I used for a long time. But, it was borked many a times during a upgrade. So, it is back to reading the forums and clearing up stuff. Plenty of experiments were carried out. I live a couple of months on the command line "only". It was very interesting and I liked the challenges that were presented. After an year, something happened and the pi 4 started acting strange. It was time to move on. The first rpi 4 had a damaged sd card slot before the usb booting came out. So, as for now, the rpi efforts are shelved.

    As is the norm for a lull after the storm, I decided to take it a little easy this time and decided to have a cheap desktop solution for my daily use at home and keep the laptop for mobile purposes. Started searching the used computer market for a sleek desktop. Plenty of Intel nuc's came along. Every single model has a lacuna on some issues. Marketing and the modelling of these systems is a total failure by Intel. The number of variants is mind boggling and utterly confusing. Searched for mini pcs from other brands like HP and Dell. Nothing interesting came up. This is the time, Apple came out with its M1 processor. I was surprised that Apple released a Mac Mini with its inhouse processor. Started knowing about the Mac mini and at the same time started looking up the used pc market. There was no way, I would be buying any device from Apple on which I cannot install GNU/Linux. I have a mac book pro 2015 which runs Arch Gnu/Linux and OpenBSD like a dream. In summary, I like apple hardware and hate their software and the lockups they try to force people to stay on macos. Until, I can install Gnu/Linux or BSDs, I dont have any gripe with apple. I love the way they make their hardware. If customization is allowed, the choices are easily laid out and of course can be very very very costly.

    Since Gnu/Linux on a mac mini M1 is still a very looooong shot, I started looking at the older versions. I liked the form factor of the mac mini. There was one more surprise, the extensibility of the mac minis. This was a complete shocker. Four thunderbolt 3 ports, two usb 3 ports, Gigabit ethernet ports, 3.5mm jack. It is like the voltage of the shocks went on increasing. Settled to buy a mac mini 2018. Waited and searched for a month and I got my hand on a "very" affordable mac mini. The build quality is excellent. The option of upgrading ram upto 64GB of DDR4 was un-believable. Postponed the upgrade for a later date. Already had a 32" LG 4k monitor, a mechanical keyboard and a M501 logitech mouse. Had an external ssd which I was using to boot up the raspberry pi. Everything just fell in place. The onboard storage is only 128GB. But I am OK with it.

    Searched the public network for installing Gnu/Linux on a mac mini. The literature is very limited. But, could put together a collection of information necessary. Infact, the installation of Gnu/Linux or a BSD on a mac mini is much simpler than that of installing windows through Bootcamp, which was a breeze when I bought the macbook pro 2015. Installation of Gnu/Linux or BSD is mighty straight forward and can be summed up as

1. Disable the secure boot and file system protection(csrutil disable) on the mac mini

2. Partition the external ssd hard drive(Dont forget to create a FAT32 partition with type set to EFI as the first partition on the external SSD, a 512MB partition will do) for Gnu/Linux and OpenBSD(I prefer OpenBSD to Freebsd just for the fact that the graphics stack is "owned" by the core devs of the project and all other security related "firsts". Again a "sensible" default) 

3. If you want to install OpenBSD do not forget to create a partition of type OpenBSD before starting the installation on any other GNU/Linux box. This will provide you and option during installation to chose that particular partition. This just makes the job easy for installing OpenBSD in multiple boot machines.

4. Download and install the refind boot manager from macos(You can install this in the macos recovery which you have entered to disable the file system protection). I just love this application. My gratitude to all the devs and users of this excellent tool.

5. Install Arch Gnu/Linux. I chose to install arco Gnu/Linux for a change and I loved the installer. Be wary of choosing other software options provided during the setup process. It struggled to download and install these. It is better to install these extra options doled out to you after the base arco install. The installation was flawless. Again dont forget to choose the EFI partition created in step two and set the boot flag. This option will be thrown to you when you select the EFI partition to be mounted as /boot/efi

6. Install OpenBSD. I love the installer. I have expressed my awe at the defaults the installer puts up. Installation process was flawless. It trumped the arco install process. Kudos to the OpenBSD team. Here again, OpenBSD expects an EFI partition on the first partition of the external SSD, which we have already met.
7. Wifi and sound through the 3.5mm jack does not work. This is the same for Arco Gnu/Linux and OpenBSD.

8. Resolved Wifi by using an USB adapter and resolved the sound issued by taking the output from my monitor.

9. At some occasions, refind is unable to boot up macos. The work around as of now is to shutdown the mini and restart. At the chime press the alt key. This will bring up the apple boot loader. If you are lucky you will see the options for choosing the apple drive and the EFI partition on the external ssd. If you are unlucky, you will definitely get to boot the macos partition. To boot the FLOSS operating systems, just reboot and you will be presented with the refind menu.

10. Dont forget to enable the file system protection again by entering the recovery menu(csrutil enable).

11. Arch Gnu/Linux and OpenBSD run flawlessly and the availability of 4 thunderbolt 3 ports is freaking amazing.

12. The form factor is just perfect for putting it in a compartment in my table without clogging the surface of the table for space. Resulting in one of the neatest desks I have maintained.

PS: All of a sudden, my arch gnu/linux installation was not detecting the Ethernet connection. Ran 

lspci

After searching the public network for the Ethernet hardware detected, tried

# modprobe tg3

reboot, and Ethernet started working.