Why is Encryption and Signing So Important?

Make sure that you and your codebases are protected

Ever since I took the “Networks and Communication” module at university, I have found myself dealing with GPG keys daily. Six months ago, I can bet that I wouldn’t have been able to publish a package onto mavenCentral and understand the entire process of what is happening.

Photo by FlyD on Unsplash

What is Encryption?

I am sure this is not a topic that you are unfamiliar with. However, allow me to brush up on this for those who are not exactly sure what this means:

Encryption is a way of scrambling data so that only authorized parties can understand the information. — Cloudflare

To exchange some confidential information over the internet, you do not want to send that in plain text. Any basic hacking techniques like packet sniffing can easily extract the information and use it maliciously. There are mainly two types of encryption:

Symmetrical encryption

This is where there is a single key which can be used to encrypt and decrypt the file. Consider that you have a file secret.txt and you encrypt this with a key, a50af1 (obviously simplified). Now the contents of secret.txt are bizarre and unreadable for any human.

When the receiver gets this file, they use the same key a50af1 to decrypt the file to get back the readable contents of secret.txt.

This is one of the simplest ways of encryption. A major drawback is that the agreed key must also be exchanged somehow. This could be via the courier mail, meeting in the park, or sending it through your pigeon!

Asymmetrical encryption

To solve the underlying issue of having to exchange a key verbally or physically, you use asymmetrical encryption. This involves having a secure private key and no one should have access to this key. This private key has a subkey called a public key which is openly distributed.

1. If some contents are encrypted by the private key, only the public key can decrypt it.
2. Similarly, If some contents are encrypted by the public key, only the private key can decrypt it.

Since the public key is known to all, and the private key is only known to a person, that person does not need to go out to secretly give it to another person. This invention is used in multiple case scenarios important in secure transactions of confidential data.

Signing files and maintaining data integrity

Data integrity refers to ensuring the public that the information released is accurate. A great example in a common developer’s daily life is signing your git commits.

I set up my private key on 24th May and signed my commit for the first time.

We have Bob; Bob didn’t set up his private key with GitHub and all his commits are unverified. One day, a malicious hacker was acting as Bob and spammed useless commits in his organisation. There was no way to verify if those commits were really by Bob. Don’t be like Bob.

When you sign your commit, you encrypt it with your private key. You also tell GitHub about your public key. When you push your files to the remote, GitHub can verify with your public key that the data was indeed sent by you.

Since you are the only person in possession of your private key, if the file is successfully decrypted with the public key, it is implied that it is you who indeed sent this commit.

Important: Keep your private key a secret. It is wise to maintain multiple private-public key pairs. In the unfortunate case one of your private keys being compromised, they can only affect one system.

Encryption with Data Confidentiality

“Okay, but you have your public key distributed so anyone can view your file you send over the internet”

Yes, that’s true! To send confidential data to someone, you must first encrypt the file with their public key. Since this file can only be decrypted by the associated private key (which is secret to the receiver), no one else can see the contents.

Integrity + Confidentiality

If you only encrypt it with your private key, it implies integrity. Otherwise, if you encrypt it with the receiver’s public key, it implies confidentiality. Therefore, for a message to be confidential and also prove that the message is sent by you (not someone acting as you), you encrypt the file twice.

1. The first lock would be with your (sender) private key.
2. Then you lock the resultant again with the receiver’s public key.

The receiver will then:

1. Decrypt the file with their private key.
2. Decrypt the resultant with your (sender) public key.

See how both parties agree with their data being confidential and knowing that it is only the trusted party that sent a message.

Conclusion

One must sign and encrypt sensitive files over the internet.

The only system which is truly secure is one which is switched off and unplugged locked in a titanium lined safe, buried in a concrete bunker, and is surrounded by nerve gas and very highly paid armed guards. Even then, I wouldn’t stake my life on it. — Gene Spafford, Purdue University

Also consider reading the following related articles:

How to deal with GPG Keys

To learn how to sign your Git commits, follow this guide. Note that you’d have to setup your GPG keys when signing your git commits.

In due time, I will publish a related article explaining how to publish your Java/Kotlin libraries to mavenCentral.

Thank you if you made it this far. If you liked my content, consider following and applauding my article.

Want to connect?

GitHub profile
Portfolio website