In this guide, I will explain the options at your disposal for encrypting files using open-source software on a Linux, Mac, or Windows computer. You can then transport this digital information across distance and time, to yourself or others.
The program “GNU Privacy Guard” (GPG) an open-source version of PGP (Pretty Good Privacy), allows:
- Encryption using a password.
- Secret messaging using public/private key cryptography
- Message/Data authentication (using digital signatures and verification)
- Private key authentication (used in Bitcoin)
Option One
Option one is what I’ll be demonstrating below. You can encrypt a file using any password you like. Any person with the password can then unlock (decrypt) the file to view it. The problem is, how do you send the password to someone in a secure way? We’re back to the original problem.
Option Two
Option two solves this dilemma (how-to here). Instead of locking the file with a password, we can lock it with someone’s public key — that “someone” is the intended recipient of the message. The public key comes from a corresponding private key, and the private key (which only the “someone” has) is used to unlock (decrypt) the message. With this method, no sensitive (unencrypted) information is ever sent. Very nice!
The public key is something that can be distributed over the internet safely. Mine is here, for example. They are usually sent to keyservers. Keyservers are like nodes that store public keys. They keep and synchronize copies of peoples’ public keys. Here’s one:
You can enter my email and find my public key in the result. I’ve also stored it here and you can compare what you found on the server.
Option Three
Option three is not about secret messages. It is about checking that a message has not been altered during its delivery. It works by having someone with a private key sign some digital data. The data can be a letter or even software. The process of signing creates a digital signature (a large number derived from the private key and the data that’s getting signed). Here’s what a digital signature looks like:
It’s a text file that begins with a “begin” signal, and ends with an “end” signal. In between is a bunch of text that actually encodes an enormous number. This number is derived from the private key (a giant number) and the data (which is actually always a number also; all data is zeros and ones to a computer).
Anyone can verify that the data has not been changed since the original author signed it by taking the:
- Public key
- Data
- Signature
The output to the query will be TRUE or FALSE. TRUE means that the file you downloaded (or message) has not been modified since the developer signed it. Very cool! FALSE means that the data has changed or the wrong signature is being applied.
Option Four
Option four is like option three, except that instead of checking if the data has not been modified, then TRUE will mean that the signature was produced by the private key associated with the public key offered. In other words, the person who signed has the private key to the public key that we have.
Interestingly, this is all that Craig Wright would have to do to prove he is Satoshi Nakamoto. He doesn’t have to actually spend any coins.
We already have the addresses (similar to public keys) that are owned by Satoshi. Craig can then produce a signature with his private key to those addresses, combined with any message such as “I really am Satoshi, haha!” and we can then combine the message, the signature, and the address, and get a TRUE result if he is Satoshi, and a CRAIG_WRIGHT_IS_A_LIAR_AND_A_FRAUD result if he isn’t.
Option Three And Four — The Difference.
It’s actually a matter of what you trust. If you trust that the sender owns the private key to the public key you have, then verification checks that the message has not changed.
If you don’t trust the private key / public key relationship, then verification is not about the message changing, but the key relationship.
It’s one or the other for a FALSE result.
If you get a TRUE result, then you know that BOTH the key relationship is valid, AND the message is unaltered since the signature was produced.
Get GPG For Your Computer
GPG already comes with Linux operating systems. If you are unfortunate enough to be using a Mac, or God forbid a Windows computer, then you’ll need to download software with GPG. Instructions to download and how to use it on those operating systems can be found here.
You don’t need to use any of the graphical components of the software, everything can be done from the command line.
Encrypting Files With A Password
Create the secret file. This can be a simple text file, or a zip file containing many files, or an archive file (tar). Depending on how sensitive the data is, you might consider creating the file on an air-gapped computer. Either a desktop computer built with no WiFi components, and never to be connected to the internet by cable, or you can build a Raspberry Pi Zero v1.3 very cheaply, with instructions here.
Using a terminal (Linux/Mac) or CMD.exe (Windows), change your working directory to wherever you put the file. If that makes no sense, search the internet and in five minutes you can learn how to navigate the file system specific to your operating system (search: “YouTube navigating file system command prompt” and include your operating system’s name).
From the correct directory, you can encrypt the file (“file.txt” for example) like this:
gpg -c file.txt
That’s “gpg”, a space, “-c”, a space, and then the name of the file.
You’ll then be prompted for a password. This will encrypt the new file. If you’re using GPG Suite on the Mac, notice the “Save in Keychain” is checked by default (see below). You might want to not save this password if it’s particularly sensitive.
Whichever OS you use, the password will be saved for 10 minutes to the memory. You can clear it like this:
gpg-connect-agent reloadagent /bye
Once your file is encrypted, the original file will remain (unencrypted), and a new file will be created. You must decide if you will delete the original or not. The new file’s name will be the same as the original but there’ll be a “.gpg” at the end. For example, “file.txt” will create a new file called “file.txt.gpg”. You can then rename the file if you wish, or you could have named the file by adding extra options in the command above, like this:
gpg -c –output MySecretFile.txt file.txt
Here, we have “gpg”, a space, “-c”, a space, “–output”, a space, the filename you want, a space, the name of the file you are encrypting.
It’s a good idea to practice decrypting the file. This is one way:
gpg file.txt.gpg
This is just “gpg”, a space, and the name of the encrypted file. You don’t need to put any options.
The GPG program will guess what you mean and will attempt to decrypt the file. If you do this immediately after encrypting the file, you may not be prompted for a password because the password is still in the computer’s memory (for 10 minutes). Otherwise, you’ll need to enter the password (GPG calls it a passphrase).
You will notice with the “ls” command (Mac/Linux) or “dir” command (Windows), that a new file has been created in your working directory, without the “.gpg” extension. You can read it from the command prompt with (Mac/Linux):
cat file.txt
Another way to decrypt the file is with this command:
gpg -d file.txt.gpg
This is the same as before but with a “-d” option as well. In this case, a new file is not created, but the contents of the file are printed to the screen.
You can also decrypt the file and specify the output file’s name like this:
gpg -d –output file.txt file.txt.gpg
Here we have “gpg”, a space, “-d” which is not strictly required, a space, “–output”, a space, the name of the new file we want, a space, and finally the name of the file we are decrypting.
Sending The Encrypted File
You can now copy this file to a USB drive, or email it. It is encrypted. Nobody can read it as long as the password is good (long and complicated enough) and can’t be cracked.
You could send this message to yourself in another country by storing it in email or the cloud.
Some silly people have stored their Bitcoin private keys to the cloud in an unencrypted state, which is ridiculously risky. But if the file containing Bitcoin private keys is encrypted with a strong password, it’s safer. This is especially true if it’s not called “Bitcoin_Private_Keys.txt.gpg” – Don’t do that!
WARNING: It’s important to understand that in no way am I encouraging you to put your Bitcoin private key information on a computer (hardware wallets were created to allow you to never need to do this). What I am explaining here is for special cases, under my guidance. My students in the mentorship program will know what they are doing and will only use an air-gapped computer, and know all the potential risks and problems, and ways to avoid them. Please don’t type seed phrases into a computer unless you are a security expert and know exactly what you are doing, and don’t blame me if your bitcoin is stolen!
The encrypted file can also be sent to another person, and the password can be sent separately, perhaps with a different communication device. This is the simpler, and less secure way, compared to option two explained at the beginning of this guide.
There are actually all sorts of ways you can construct the delivery of a secret message across distance and time. If you know these tools, think hard and carefully about all the risks and scenarios, a good plan can be made. Or, I am available to assist.
Good luck, and happy Bitcoining!
This is a guest post by Arman The Parman. Opinions expressed are entirely their own and do not necessarily reflect those of BTC Inc or Bitcoin Magazine.
Ecosystem
Research
News Network
About