Preparing a Secure Password File
Storing passwords in plain text is a quick way to lose data, yet the urge to keep them all in one place persists. A single encrypted file is a safer alternative to a scattered list of notes or an unprotected spreadsheet. The first step toward that secure file is to create it under strict permissions and with a clear owner so that only you can read it before encryption.
Open a terminal and begin with a private directory for your secrets. Setting the file mode creation mask to removes read, write, and execute permissions for group and others, leaving only the owner with full access. The command looks like this:
Next, open an editor that respects the current working directory and create a file named mypasswordfile. Depending on your preferred editor, you might type:
When you close the editor, the file will exist with restrictive permissions. A quick ls -l confirms the mode:
Each line of the file should follow a simple, parseable format - perhaps service:user:password:notes. Avoid embedding personal data such as full names or addresses in the clear, because once the file is decrypted those details become available to any reader of the output. Keep the file as short as possible to limit the amount of sensitive data that could be exposed if the encryption were broken.
After writing your list, double‑check that no accidental newline or trailing spaces have crept in. Those small changes can alter the resulting hash and break signature verification later. Save the file and close the editor. The file is ready for encryption, but its contents remain exposed on disk until the next step.
Why not just use a password manager? That is a good option, but many people prefer the transparency of a plain text file that they can inspect, version, or archive. By encrypting that file with GnuPG, you keep the benefits of a plain text format while protecting the data against anyone who gains file‑system access.
Encrypting with GnuPG from the Command Line
With the file ready, the command that turns it into a safe, encrypted blob is simple yet powerful. GnuPG (often called GPG) accepts a suite of flags that dictate whether the file is signed, encrypted, or both. The example below demonstrates a typical approach: sign the file, encrypt it for yourself, and produce ASCII‑armored output.
When you run this command, GPG first asks for the passphrase that unlocks the secret key you created earlier. This step is mandatory because signing requires access to the private key, and encrypting for a recipient requires a copy of that recipient’s public key. In our case, the recipient is the owner of the same key pair, so GPG asks for the user ID. The prompt will look similar to:
Providing the user ID in this interactive fashion works when you only have one key that matches. In scripts or automated environments, you can supply the recipient directly on the command line:
The shorthand flag sequence -seat bundles --sign, --encrypt, --armor, and --text. The -r flag introduces the recipient. If multiple keys share the same name or email, using the key ID eliminates ambiguity. This technique keeps the command line concise while preserving clarity.
After signing and encrypting, GPG writes two files. The original remains unchanged, while the encrypted blob appears as mypasswordfile.asc (the .asc extension marks ASCII‑armored output). A quick directory listing shows both:
At this point the file is safe for storage, transfer, or email attachment. Anyone who attempts to open mypasswordfile.asc will see gibberish until they supply the matching private key and passphrase. The next section explains the mechanics behind these options in more detail.
Understanding GPG Options
GPG’s command line offers a rich set of flags that allow precise control over the encryption and signing process. Breaking down each flag clarifies how they work together to produce a secure artifact.
--encrypt instructs GPG to protect the data so that only the designated recipients can recover it. Internally, GPG creates a random session key and uses a fast symmetric cipher - such as AES‑256 - to encrypt the file. That session key is then wrapped with the recipient’s public key, ensuring that only someone who owns the corresponding private key can retrieve the original symmetric key and decrypt the content. Because the symmetric key is random for each file, even if two files contain the same text, the encrypted output will differ. --sign adds a digital signature to the file. GPG computes a cryptographic hash of the data - SHA‑256 by default - and encrypts that hash with the signer's private key. Anyone who has the public key can decrypt the signature and verify that the hash matches the file’s current state. If the file has been altered, the signature verification will fail, alerting the recipient to tampering. --armor chooses ASCII representation over binary. When you attach a file to an email or embed it in a text‑based medium, binary data can become corrupted by line‑ending conversions or character encoding mismatches. The ASCII‑armored format surrounds the encrypted data with a header and footer, like-----BEGIN PGP MESSAGE----- and -----END PGP MESSAGE-----, making it safe for transport over any channel that expects printable characters. The downside is a larger file size, usually about 33% larger than the binary version.
--text tells GPG that the input is plain ASCII text. During decryption, GPG automatically converts line endings between CRLF, CR, and LF, depending on the operating system of the original file. This feature reduces the need for manual editing of line breaks when exchanging files between Windows, macOS, and Linux systems.
When combining flags, GPG processes them in a fixed order: it first signs, then encrypts, then applies ASCII armor, and finally treats the input as text if requested. Knowing this order helps when debugging unexpected output or when configuring scripts that rely on specific formats.
The .asc extension is common for ASCII‑armored messages, but some older PGP implementations expect .pgp. If you encounter a program that refuses a .gpg or .asc file, simply rename it to file.pgp. Likewise, you can instruct GPG to output a binary file by omitting --armor or by using --output file.gpg. The choice between binary and armored depends on the intended transport mechanism.
GPG also supports multiple recipients in a single command. Each -r flag adds another public key to the encryption list. The overhead of supporting an extra recipient is minimal because the session key is encrypted only once per recipient, not per file segment. This feature is useful for sharing a document with a team while keeping the file itself encrypted.
Understanding these options not only demystifies the command line but also empowers you to tailor encryption to your workflow. Whether you need a quick one‑off protection for an email attachment or a script that encrypts backups automatically, GPG’s flag set covers most use cases.
Decrypting and Viewing Your Encrypted Data
Once you or a trusted recipient has the appropriate private key and passphrase, opening the encrypted file is straightforward. The most common command simply passes the file name to GPG:
GPG will prompt for the passphrase and, upon success, write the decrypted contents to a file with the same base name but without the .asc extension. If you prefer to specify an output location, the -o flag does the job:
For immediate inspection without creating a new file, direct the output to standard output and pipe it to a pager:
or, more concisely, using the shorthand for decryption:
These variations allow you to choose whether to keep a temporary plain text file, stream the contents live, or feed the output into another program. If you want to search for a specific service, you can pipe the output directly into grep:
During decryption, GPG will display two types of information. First, it prints the signature verification result, such as:
Second, if you run the command without the --quiet flag, GPG also echoes the decrypted data to the console. In most cases you’ll want to suppress the passphrase prompt echo by using --quiet or by running GPG within a terminal that keeps the input hidden.
If the signature does not match, GPG warns with BAD signature or BAD signature from. This situation indicates that the file has been altered or that the wrong public key was used. It’s a safeguard against tampering and an essential part of the trust chain.
When dealing with large archives or frequent decryptions, consider using gpg-agent to cache your passphrase for a limited time. That way you don’t have to type it for every decryption while still maintaining a strong security posture.
Decryption can also be scripted. For instance, a cron job that automatically decrypts nightly backups into a temporary directory for processing is a common pattern. The key is to store the script’s directory permissions securely and to avoid writing the passphrase in clear text within the script.
Next Steps and Key Management
The encryption and decryption workflow described here assumes that both parties share a key pair and that the public key is already available locally. In practice, exchanging keys safely is a crucial step. The next part of this series will cover how to retrieve others’ public keys from key servers, verify their fingerprints, and assign trust levels.
To import a key you can use the --recv-keys command against a public key server:
After importing, you’ll want to confirm the key’s fingerprint with the owner - either over the phone or through a secure channel - to ensure the key has not been tampered with. GPG displays the fingerprint using --fingerprint:
Trust management in GnuPG involves assigning a trust level to each key. The default is unknown, meaning GPG will ask you each time you use the key. You can raise trust to full or ultimate for keys you consider reliable. This is done via --edit-key and the trust command.
Keys can also expire. GPG allows you to set an expiration date when you create or later modify a key. Once a key expires, it should not be used for signing or encryption. If you rely on a key for regular communication, consider setting a reasonable lifetime and planning a renewal before expiration.
When integrating GPG into email clients, such as Evolution or Thunderbird, the GUI front‑ends typically handle key selection and passphrase prompting for you. However, understanding the underlying command‑line behavior ensures you can troubleshoot issues that may surface when the GUI fails to locate a key or misinterprets a signature.
Finally, always back up your private key and its passphrase in a secure, offline location. Losing the key means losing access to all data encrypted for you, while a compromised key threatens the confidentiality of everything you encrypt. Protecting the key is as vital as protecting the data it protects.
No comments yet. Be the first to comment!