Ahh, where should we start? Okay, let's start with, I'm the relatively paranoid type.
And given the super ambitious nature of agencies like NSA and governments around the world, I didn't want to leave any blind spots. So, I decided, that it's about time we do this!
Throughout this blog I'm going to be using mostly layman terms, while citing the technical sources, which you can checkout if you want to.
Also this blog is not targetted at you if you are an ameture, because if you are one, you are probably already doing 10 things incorrectly, and this is the least of your worries. You can still have a good read though. The blog mostly targets intermediate developers and intends to be the single place you need to look for setting up a secure machine.
Alright so, being on a linux platform, there are going to be 2 types of Keys you ever need to be worried about.
You'll be using these keys as a sort of authentication mechanism, to prove your identity. Popular examples of using these keys is when you need passwordless access to servers or maybe to push commits to your git repository. It is not technically passwordless, since your Key act as your password. They are composed of 2 parts, the public key, and the private key. The public key, sits on the server which you want to access, you can openly disclose it to the world without fearing any compromises, whereas the private key is supposed to stay with you.
Next are the GPG Keys, now these are a little more complicated than SSH Keys. GPG Keys can be used for signing messages, or commits, or software, to provide authenticity, of your identity, to prove that you are indeed the one providing the information. They can also be used to encrypt messages, so that they can be read by only the person or organization it is intended for.
Seems like the modern version of Leo Tolstoy's story. Anyways jokes aside. With more number of keys comes more security, but also more complexity in handling the keys. To start off lets lay down some logical statements.
Based on the rules above, I think it is same to assume the following ground rules
Boy we've reached 9 rules. I was expecting 3 or 4 at max. Anyways, we gotta get rid of the paranoia.
The next problem arises of storing the keys, and having backups. You need to have backups, because it is a bad idea to put all your e̶g̶g̶s̶ keys in one b̵a̵s̵k̵t̵e̵t̵ device. Your PC may fatally crash, your phone may go dead, or you USB stick may just stop responding. Hence it is a bad idea to have everything at a single location.
Here we follow the 3-2-1 backup rule. It is a best practice to have 3 copies of the data. This way, even if you lose any 2 of them, which in itself is an unlikely occurence, you can still recover.
You may also use something like the physical prinout of you key on paper, using something like paperkey. Or maybe in the form of a QR code, maybe at the bottom of the ocean/ in someone's grave/ inside a nuclear reactor. Whatever, get creative with your ideas! Or maybe keep it simple, and have multiple plain old USB sticks in differnt locations, or a CD-ROM (if anyone even uses that nowadays). Or you could store it on Google Drive, defeating the entire purpose and effort. The cloud could also be considered an option, but then again, I won't necessarily trust the cloud provider to not access my data.
Now earlier I had suggested that it is a bad idea to store it on your device, However you may also store, inside a tomb. More on that later.
Before key creation you may want to install
rng-tools for entropy creation.
Alright now coming to the creation part. Finally comes the creation of the key part! The initial seed should be super random. Make sure you have OpenSSH installed on your system. Most systems have it, however in case it is not present, simply look it up on the internet, and install it using your package manager.
Creating the ED25519 Key:
ssh-keygen -a 100 -t ed25519 -f ~/.ssh/id_ed25519 -C "[email protected]"
Creating the RSA Key:
ssh-keygen -a 100 -b 4096 -f ~/.ssh/id_rsa -C "[email protected]"
In both the cases you'll have to enter your passphrase, while creating the key. Make sure you choose a secure passphrase, preferably 10 characters long, with a combination of symbols, number, capital and small lettes. Also make sure you don't forget it!
Make sure you're using
gpg2 instead of
The creation process for the 2 GPG keys is similar, except for some minor changes. To start the process you need to invoke the same command in both the cases.
gpg2 --verbose --full-gen-key
Let's create the signing key first.
You'll be presented with a few prompts. For the 1st prompt, select 4, i.e.
RSA (sign only). Next make sure your keys are
4096 bits long. As explained above, given this is a the signing key, the validity of the key should be
0, i.e. the key does not expire. Finally you'll need to confirm your inputs, enter your passphrase insert you name, email ID, and a comment. In the comment, you may mention
Signing Key. Note that, the last 3 fields, are inconssequential to the key generation, however they're important for identification purposes. Done, your signing key will be created.
For creation of the encryption key, invoke the same command as above.
Filling the prompts will be a little different this time around. For the 1st prompt, select 1, i.e.
RSA and RSA. Next make sure your keys are
4096 bits long. For key expiration period, you may select 1 year, i.e.
1y. Confirm everything and enter a passphrase like above, and your encryption keys are also ready!
Note again, I cannot emphasise enough the importance of using a strong passphrase! The passphase will be what protects your private key in case it is stolen.