Last modified: June 06, 2026
This article is written in: 🇺🇸
Encryption is one of the main tools used to protect digital information. It keeps data private by changing readable information into an unreadable form. The readable version is called plaintext, and the unreadable version is called ciphertext.
For example, the message:
Hello
might be transformed into something unreadable, such as:
6hj7!#f&
The unreadable version is only useful to someone who has the correct key or password needed to turn it back into the original message.
Encryption protects information when it is stored and when it is sent across a network.
It is used when logging into websites, sending private messages, storing passwords, protecting backups, securing disks, and sending sensitive files. Without encryption, anyone who intercepts or steals the data may be able to read it.
The main goals of encryption are:
Confidentiality -> Only authorized people can read the data.
Integrity -> The data has not been changed unexpectedly.
Authentication -> The sender or owner can be verified.
Compliance -> Legal or policy requirements can be met.
Encryption is especially important when information travels over insecure networks, such as the internet or public Wi-Fi.
The basic encryption process looks like this:
[ Plaintext ] +------------------+ [ Ciphertext ]
"Hello" -----> | Encryption | -----> "6hj7!#f&"
| Algorithm + Key |
+------------------+
The plaintext is the original readable data. The encryption algorithm is the mathematical process used to transform the data. The key controls how that transformation happens.
Without the correct key, the ciphertext should be extremely difficult to turn back into plaintext.
Decryption reverses the process.
[ Ciphertext ] +------------------+ [ Plaintext ]
"6hj7!#f&" -----> | Decryption | -----> "Hello"
| Algorithm + Key |
+------------------+
The encrypted data is given to the decryption algorithm along with the correct key. If the key is valid, the original plaintext is recovered.
There are two major types of encryption that are important to understand.
Symmetric encryption uses the same secret key for encryption and decryption.
Same Secret Key
|
v
[ Plaintext ] -> Encrypt -> [ Ciphertext ] -> Decrypt -> [ Plaintext ]
This is simple and fast, but both sides must already know the same secret key. If the key is shared insecurely, the encryption can be broken.
Asymmetric encryption uses a pair of related keys: a public key and a private key.
[ Public Key ] ---> encrypts data
[ Private Key ] ---> decrypts data
The public key can be shared with other people. The private key must be kept secret.
This makes asymmetric encryption useful for secure communication between people who have not already shared a secret password.
GPG stands for GNU Privacy Guard. It is a free and open-source tool that implements the OpenPGP standard.
GPG can be used to encrypt files, decrypt files, create digital signatures, verify signatures, manage cryptographic keys, and exchange public keys with other people.
GPG is commonly used for protecting files, sending secure messages, verifying software releases, and managing trusted identities.
GPG uses key pairs.
A key pair contains:
Public key -> shared with others
Private key -> kept secret
The public key can safely be shared. Other people use your public key to encrypt files or messages for you. Once something is encrypted with your public key, only your matching private key can decrypt it.
The private key must never be shared. It is used to decrypt data sent to you and to create digital signatures that prove something came from you.
The relationship looks like this:
Shared openly
<---------------->
[ Public Key ] [ Private Key ]
encrypts data decrypts data
verifies signatures creates signatures
Another way to visualize it:
Someone wants to send you a secret file
Their computer:
[ Plain File ] + [ Your Public Key ]
|
v
[ Encrypted File ]
Your computer:
[ Encrypted File ] + [ Your Private Key ]
|
v
[ Plain File ]
The important rule is:
Share your public key.
Protect your private key.
On Debian or Ubuntu-based systems, GPG can be installed with:
sudo apt update
sudo apt install gnupg2
On many Linux systems, GPG may already be installed.
To check whether it is available, run:
gpg --version
This prints the installed GPG version and supported algorithms.
To create a new GPG key pair, run:
gpg --gen-key
GPG will ask a series of questions.
A typical key generation process includes choosing the key type, key size, expiration date, name, email address, optional comment, and passphrase.
Example choices might be:
Key type: RSA and RSA
Key size: 4096 bits
Expiration: 1 year or no expiration
Name: John Doe
Email: john.doe@example.com
Comment: Work Key
The user ID might look like this:
John Doe (Work Key) <john.doe@example.com>
GPG will also ask for a passphrase. This passphrase protects the private key. Even if someone copies the private key file, they still need the passphrase to use it.
The process looks like this:
gpg --gen-key
|
v
Choose key type and size
|
v
Set expiration date
|
v
Enter name and email
|
v
Set passphrase
|
v
Public key + private key are created
A strong passphrase is important. It should be long, unique, and difficult to guess.
GPG stores keys in a keyring.
To list public keys in your keyring, run:
gpg --list-keys
Example output:
/home/user/.gnupg/pubring.kbx
-----------------------------
pub rsa4096 2022-01-01 [SC]
1A2B3C4D5E6F7G8H
uid [ultimate] John Doe (Work Key) <john.doe@example.com>
To list private keys, run:
gpg --list-secret-keys
Example output:
/home/user/.gnupg/pubring.kbx
-----------------------------
sec rsa4096 2022-01-01 [SC]
1A2B3C4D5E6F7G8H
uid [ultimate] John Doe (Work Key) <john.doe@example.com>
The public key list shows keys you can use to encrypt data or verify signatures.
The secret key list shows private keys that belong to you and can be used for decryption or signing.
GPG output often includes letters such as:
[S] signing
[C] certification
[E] encryption
[A] authentication
For example:
pub rsa4096 2022-01-01 [SC]
means the primary public key can be used for signing and certification.
A subkey might show:
sub rsa4096 2022-01-01 [E]
which means that subkey is used for encryption.
These flags help explain what each key is allowed to do.
To send encrypted data to someone, you need their public key.
If someone gives you a public key file, such as:
recipient_public_key.asc
you can import it with:
gpg --import recipient_public_key.asc
Example output:
gpg: key 9H8G7F6E5D4C3B2A: public key "Jane Smith <jane.smith@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
After importing the key, it becomes available in your keyring.
You can then use it to encrypt files for that person or verify signatures from that person.
Before trusting a public key, you should verify its fingerprint.
A fingerprint is a longer identifier for a key. It is more reliable than a short key ID.
To show a key fingerprint, run:
gpg --fingerprint jane.smith@example.com
You should compare the fingerprint with the owner through a trusted channel, such as in person, a verified website, a secure call, or another reliable method.
This matters because anyone can create a key with someone else’s name and email address. The fingerprint helps confirm that the key really belongs to the person you think it belongs to.
After importing someone’s public key, GPG may not automatically trust it.
To edit trust settings, run:
gpg --edit-key jane.smith@example.com
Inside the interactive GPG prompt, type:
trust
GPG will ask how much you trust the key owner to verify other keys.
Example options include:
1 = I do not know
2 = I do not trust
3 = I trust marginally
4 = I trust fully
5 = I trust ultimately
For example:
Your decision? 5
Ultimate trust should usually be used only for your own keys. For other people’s keys, choose a level that matches how carefully you verified the key.
After making changes, type:
save
or:
quit
depending on what you are doing.
To encrypt a file for a recipient, you need that recipient’s public key.
Use:
gpg -e -r jane.smith@example.com file.txt
Here:
-e means encrypt
-r means recipient
This creates an encrypted file, usually named:
file.txt.gpg
The process looks like this:
[ Original File ] +-------------+ [ Encrypted File ]
file.txt -----> | GPG Encrypt | -----> file.txt.gpg
+-------------+
Recipient: Jane
Only Jane’s private key can decrypt the file.
If the command succeeds, GPG may produce no output. In many Unix tools, no output often means success.
To decrypt an encrypted file, use:
gpg -d -o file.txt file.txt.gpg
Here:
-d decrypt
-o file.txt write output to file.txt
The process looks like this:
[ Encrypted File ] +-------------+ [ Original File ]
file.txt.gpg -----> | GPG Decrypt | -----> file.txt
+-------------+
If the file was encrypted with your public key, GPG uses your private key to decrypt it.
If your private key is protected by a passphrase, GPG will ask for that passphrase.
GPG can also use symmetric encryption.
Symmetric encryption uses one shared passphrase instead of a public/private key pair.
To encrypt a file symmetrically, run:
gpg --symmetric file.txt
GPG will ask for a passphrase:
Enter passphrase:
Repeat passphrase:
The output file is usually:
file.txt.gpg
The process looks like this:
[ file.txt ] + [ passphrase ]
|
v
[ file.txt.gpg ]
To decrypt it, the recipient must know the same passphrase.
Symmetric encryption is useful when you do not want to manage public keys, but it has one major challenge: the passphrase must be shared safely.
Asymmetric encryption is better when you want people to send encrypted data to each other without first sharing a password.
Symmetric encryption is simpler and often faster, but both sides must know the same secret.
A simple comparison:
| Asymmetric encryption | Symmetric encryption | |
| How it works | Uses public and private keys | Uses one shared password or key |
| Key sharing | Public key can be shared; private key must stay secret | Same secret encrypts and decrypts |
| Common uses | Secure communication between different people | Personal file encryption or shared secrets |
| Notes | Useful without needing a pre-shared secret | Requires a safe way to share the passphrase |
Encryption protects confidentiality. Digital signatures protect authenticity and integrity.
A digital signature proves two things:
1. The file was signed by someone who has the private key.
2. The file has not changed since it was signed.
To sign a file, run:
gpg --sign file.txt
This creates a signed file, usually:
file.txt.gpg
The signing process looks like this:
[ File ] + [ Your Private Key ]
|
v
[ Signed File ]
Anyone with your public key can verify the signature.
To verify a signed file, run:
gpg --verify file.txt.gpg
Example output:
gpg: Signature made Mon 03 Oct 2022 12:00:00 PM UTC
gpg: using RSA key 1A2B3C4D5E6F7G8H
gpg: Good signature from "John Doe (Work Key) <john.doe@example.com>"
A good signature means the file matches the signature and the signature was created by the private key matching the public key in your keyring.
However, a good signature does not automatically mean you trust the person. It only means the signature is mathematically valid for that key.
You still need to decide whether the key itself is trustworthy.
Sometimes you may want to keep the original file unchanged and create a separate signature file.
Use:
gpg --detach-sign file.txt
This creates a separate signature file, usually:
file.txt.sig
To verify it, use:
gpg --verify file.txt.sig file.txt
Detached signatures are common for software downloads. A project may provide a file and a separate signature so users can verify that the file was not modified.
Other people need your public key if they want to send you encrypted files or verify your signatures.
To export your public key in ASCII-armored format, run:
gpg --export -a john.doe@example.com > john_public_key.asc
The -a option means ASCII armor. This creates a text-based version of the key that is easier to share in email, websites, or messages.
The process looks like this:
[ Your Public Key in GPG Keyring ]
|
v
GPG export command
|
v
[ john_public_key.asc ]
The file may contain text like:
-----BEGIN PGP PUBLIC KEY BLOCK-----
mQENBF+...
...
-----END PGP PUBLIC KEY BLOCK-----
This file can be shared publicly.
Normally, you should not export your private key unless you are making a secure backup or moving it to another trusted device.
To export a private key, the command is:
gpg --export-secret-keys -a john.doe@example.com > john_private_key.asc
This file must be protected carefully.
A private key backup should be stored securely, preferably offline and encrypted.
Never email your private key to yourself or upload it to an insecure cloud location.
If your private key is lost, stolen, compromised, or no longer used, you need a way to tell others not to trust it anymore.
That is what a revocation certificate is for.
To create a revocation certificate, run:
gpg --gen-revoke john.doe@example.com
You can also save an ASCII-armored revocation certificate to a file:
gpg --gen-revoke --armor --output revoke.asc john.doe@example.com
The revocation process looks like this:
Private key compromised or retired
|
v
Create or publish revocation certificate
|
v
Other users learn the key should no longer be trusted
It is a good idea to create a revocation certificate soon after creating a key and store it somewhere safe.
Do not publish the revocation certificate unless you actually want to revoke the key.
A GPG key can have subkeys.
A primary key is often used for identity and certification. Subkeys can be used for specific tasks such as encryption, signing, or authentication.
This is useful because you can keep the primary key more secure and use subkeys for daily work.
The structure looks like this:
[ Primary Key ]
|
+--> [ Signing Subkey ]
|
+--> [ Encryption Subkey ]
|
+--> [ Authentication Subkey ]
If a subkey is compromised, you may be able to revoke or replace only that subkey instead of replacing the entire identity.
To manage subkeys, run:
gpg --edit-key john.doe@example.com
Then inside the GPG prompt:
addkey
GPG will ask what kind of subkey you want.
Example:
(4) RSA sign only
(6) RSA encrypt only
(8) RSA set your own capabilities
After choosing the type, you can set the size and expiration date.
When finished, type:
save
GPG chooses reasonable defaults, but you can also specify options manually.
For symmetric encryption, you can choose a cipher algorithm:
gpg --cipher-algo AES256 --symmetric file.txt
AES256 is a widely used symmetric encryption algorithm.
For public-key encryption, a basic command is:
gpg --encrypt --recipient jane.smith@example.com file.txt
You may also see the shorter form:
gpg -e -r jane.smith@example.com file.txt
In most normal situations, it is better to rely on GPG’s safe defaults unless you have a specific reason to change algorithms.
GPG can be used with email. Some email clients integrate GPG directly, while others require manual encryption and decryption.
The basic idea is:
Write message
|
v
Encrypt message with recipient's public key
|
v
Send encrypted message
|
v
Recipient decrypts with private key
Suppose the message is stored in:
message.txt
To encrypt it for Jane and save it as an ASCII-armored file, run:
gpg --armor --encrypt --recipient 'jane.smith@example.com' --output message.asc message.txt
Here:
--armor creates text-based encrypted output
--encrypt encrypts the file
--recipient chooses who can decrypt it
--output chooses the output filename
The result is:
message.asc
This file can be sent through email or another text-based communication method.
To decrypt the message, run:
gpg --decrypt message.asc > message.txt
This decrypts the encrypted content and writes the readable message to:
message.txt
If the message was encrypted for your public key, your private key is required to decrypt it.
Key servers are systems that allow people to publish and find public keys.
If you upload your public key to a key server, other people can search for it and import it.
The general workflow is:
Create public key
|
v
Upload public key to key server
|
v
Other people search for your key
|
v
They import it and use it
To upload a public key to a key server, use:
gpg --send-keys --keyserver hkp://pgp.mit.edu 1A2B3C4D5E6F7G8H
Example output:
gpg: sending key 1A2B3C4D5E6F7G8H to hkp://pgp.mit.edu
This makes your public key available to people who search that key server.
Before uploading a key publicly, remember that public key servers may preserve information for a long time. Do not upload keys with email addresses or identities you do not want publicly associated.
To search for someone’s public key, use:
gpg --search-keys --keyserver hkp://pgp.mit.edu jane.smith@example.com
Example output:
gpg: data source: http://pgp.mit.edu:11371
(1) Jane Smith <jane.smith@example.com>
4096 bit RSA key 9H8G7F6E5D4C3B2A, created: 2022-01-01
Keys 1-1 of 1 for "jane.smith@example.com". Enter number(s), N)ext, or Q)uit > 1
gpg: key 9H8G7F6E5D4C3B2A: public key "Jane Smith <jane.smith@example.com>" imported
gpg: Total number processed: 1
gpg: imported: 1
After importing the key, you should still verify the fingerprint before trusting it.
A key server can help you find a key, but it does not automatically prove the key is genuine.
Keys may change over time. They can expire, be extended, gain new signatures, or be revoked.
To refresh keys from a key server, run:
gpg --refresh-keys --keyserver hkp://pgp.mit.edu
Example output:
gpg: refreshing 1 keys from hkp://pgp.mit.edu
gpg: key 9H8G7F6E5D4C3B2A: "Jane Smith <jane.smith@example.com>" not changed
gpg: Total number processed: 1
gpg: unchanged: 1
Refreshing keys helps make sure you are not using outdated or revoked key information.
Disk encryption protects data stored on a hard drive, SSD, USB drive, or other storage device.
If someone steals the physical device, disk encryption helps prevent them from reading the files.
Disk encryption is different from encrypting a single file. Instead of protecting only one file, it can protect an entire partition, disk, or volume.
The basic idea is:
[ Disk Data ] + [ Encryption Key ]
|
v
[ Encrypted Disk ]
Without the key, the disk contents are unreadable.
On Linux, a common disk encryption system is LUKS, which stands for Linux Unified Key Setup.
The workflow looks like this:
[ GPG Private Key ]
|
v
Decrypts
|
v
[ Encrypted Keyfile ] -----> [ Plain Keyfile ]
|
v
Unlocks LUKS Volume
|
v
[ Decrypted Disk Access ]
A simpler diagram:
[ GPG Key ] [ Encrypted Keyfile ] [ LUKS Volume ]
| | |
+--> Decrypt Keyfile +--> Unlocks Volume ------+
This creates multiple layers of protection.
The disk needs the keyfile, and the keyfile is protected by GPG.
To create a random keyfile, run:
dd if=/dev/urandom of=/root/luks-keyfile bs=512 count=4
chmod 600 /root/luks-keyfile
The dd command creates random data from /dev/urandom.
The chmod 600 command makes the file readable and writable only by its owner.
Example output:
4+0 records in
4+0 records out
2048 bytes copied
This keyfile should be protected carefully because it can unlock the encrypted volume.
To encrypt the keyfile for yourself, run:
gpg --encrypt --recipient john.doe@example.com /root/luks-keyfile
This creates an encrypted version, usually:
/root/luks-keyfile.gpg
If you see an error such as:
gpg: /root/luks-keyfile: encryption failed: No public key
it means GPG could not find the public key for the recipient.
Check that the key exists:
gpg --list-keys
Then use the correct email address or key ID.
To format a device as a LUKS encrypted volume using the keyfile, run:
cryptsetup luksFormat /dev/sdX /root/luks-keyfile
Be extremely careful with /dev/sdX.
This is only a placeholder. You must replace it with the correct device name.
Formatting the wrong device can destroy data.
GPG/LUKS setup should be tested in a safe lab environment before being used on important systems.
A warning may appear:
WARNING!
========
This will overwrite data on /dev/sdX irrevocably.
Are you sure? (Type uppercase yes): YES
This warning means the data on that device will be overwritten.
To decrypt the keyfile:
gpg --output /root/luks-keyfile --decrypt /root/luks-keyfile.gpg
Then use it to open the LUKS volume:
cryptsetup luksOpen /dev/sdX my_encrypted_volume --key-file /root/luks-keyfile
This creates a mapped decrypted device, usually under:
/dev/mapper/my_encrypted_volume
The flow is:
Decrypt keyfile
|
v
Use keyfile with cryptsetup
|
v
Open encrypted LUKS volume
|
v
Access mapped device
After opening the LUKS volume, mount it:
mount /dev/mapper/my_encrypted_volume /mnt/my_mount_point
This makes the decrypted filesystem accessible at:
/mnt/my_mount_point
The mount point must exist first. If it does not exist, create it with:
mkdir -p /mnt/my_mount_point
After unlocking the volume, the decrypted keyfile should not be left sitting on disk.
To securely delete it, run:
shred -u /root/luks-keyfile
The shred command overwrites the file before deleting it.
The -u option removes the file after overwriting.
This helps reduce the risk of someone recovering the keyfile later.
Some advantages include:
Extra protection for disk unlock keys
Better key management
Support for multiple users or recipients
Ability to revoke or rotate GPG keys
Separation between disk encryption and key protection
However, this setup is more complex than using a normal LUKS passphrase. More complexity can also create more chances for mistakes.
Generate a new key:
gpg --gen-key
List public keys:
gpg --list-keys
List private keys:
gpg --list-secret-keys
Import a public key:
gpg --import recipient_public_key.asc
Export your public key:
gpg --export -a john.doe@example.com > john_public_key.asc
Encrypt a file for someone:
gpg -e -r jane.smith@example.com file.txt
Decrypt a file:
gpg -d -o file.txt file.txt.gpg
Encrypt a file symmetrically:
gpg --symmetric file.txt
Sign a file:
gpg --sign file.txt
Create a detached signature:
gpg --detach-sign file.txt
Verify a signature:
gpg --verify file.txt.gpg
Generate a revocation certificate:
gpg --gen-revoke john.doe@example.com
Edit a key:
gpg --edit-key john.doe@example.com
Search for keys on a key server:
gpg --search-keys --keyserver hkp://pgp.mit.edu jane.smith@example.com
Refresh keys:
gpg --refresh-keys --keyserver hkp://pgp.mit.edu