PGP verification: step-by-step

From In the Hidden Wiki
Jump to navigation Jump to search


PGP verification is the process of checking whether a file, message, release, or document was signed by the expected person or project and whether it has been changed since it was signed. It is one of the most important uses of public-key cryptography because it helps answer two practical questions: who signed this, and has it been modified?

PGP verification is commonly used for software downloads, security advisories, public statements, cryptocurrency releases, source code archives, backup files, email messages, and sensitive documents. It is especially useful when files are shared through mirrors, public websites, forums, file hosts, or any channel where tampering is possible.

A valid PGP signature does not automatically mean that a file is safe, legal, useful, or free from bugs. It only means that the signature matches a particular public key and that the signed content has not changed since the signature was created. The real value of PGP verification depends on whether the public key itself has been verified correctly.

The most important rule is simple: verifying a signature without verifying the signer’s public key is incomplete.

What PGP Verification Means

PGP verification checks a digital signature.

A digital signature is created with a private key. The matching public key is used to verify it. If verification succeeds, the user learns that the signed data matches the signature and that the signature was made by someone who controlled the corresponding private key.

This provides two important security properties:

  • Integrity — the file or message has not changed since it was signed.
  • Authenticity — the signature matches the public key that claims to belong to the signer.

The second property depends on key verification. A signature from an unknown key proves very little. It may prove that the file was signed by some key, but not necessarily by the person or project the user expected.

PGP verification is not only about running a command. It is about building confidence that the right key signed the right content.

PGP, OpenPGP, and GPG

The terms PGP, OpenPGP, and GPG are often used together, but they are not exactly the same.

PGP originally referred to Pretty Good Privacy, a system for encryption and digital signatures.

OpenPGP is the open standard that defines message formats for PGP-style encryption and signatures.

GPG, or GNU Privacy Guard, is a widely used free software implementation of OpenPGP. Many people say “PGP verification” when they are actually using GPG commands.

In practical guides, the commands usually use `gpg`, because GnuPG is the common command-line tool.

What a PGP Signature Can Prove

A successful PGP verification can prove that the content matches the signature and that the signature corresponds to a specific public key.

It can help confirm:

  • A software release was signed by the expected project key.
  • A document was not modified after signing.
  • A message was signed by a particular key.
  • A downloaded file matches the signed release.
  • A public announcement was made by someone controlling the expected private key.

But PGP verification does not prove everything.

It does not prove that the signed software has no vulnerabilities.

It does not prove that the signer is honest.

It does not prove that the public key belongs to the claimed person unless the key has been verified.

It does not prove that the website where the key was downloaded is authentic.

It does not prove that the signer’s private key was never compromised.

PGP verification is powerful, but it must be understood correctly.

What You Need Before Verifying

To verify a PGP signature, you usually need three things:

  • The file or message being verified.
  • The PGP signature.
  • The signer’s public key.

For software downloads, this often looks like: 

program.tar.gz
program.tar.gz.asc
developer-public-key.asc

The `.asc` file may be a detached signature, meaning it contains the signature separately from the downloaded file.

Sometimes the signature may be embedded inside a signed message instead of provided as a separate file.

The exact process depends on the signature type.

Detached Signatures

A detached signature is stored separately from the file it signs.

This is common for software releases. The project provides the file and a separate signature file.

Example: 

example-1.0.tar.gz
example-1.0.tar.gz.asc

The `.asc` file does not contain the original file. It contains the signature. Verification checks whether the signature matches the downloaded file.

This is useful because mirrors can distribute large files while signatures remain small and easy to publish.

Clear-Signed Messages

A clear-signed message is a readable text message that includes a PGP signature block.

It usually looks like: 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

This is the signed message.

-----BEGIN PGP SIGNATURE-----
...
-----END PGP SIGNATURE-----

The message remains readable, and the signature can be verified.

Clear-signed messages are commonly used for announcements, statements, release notes, and identity proofs.

Inline or Attached Signatures

Some signed files contain both the signed data and the signature together. In these cases, GPG may verify the signature and extract the original content.

This is less common for ordinary software downloads than detached signatures, but it is still part of the OpenPGP ecosystem.

Step 1: Install GPG

Before verifying a signature, install GPG.

On many Linux systems: 

sudo apt install gnupg

On Fedora: 

sudo dnf install gnupg

On Arch Linux: 

sudo pacman -S gnupg

On macOS, GPG can be installed through package managers or GPG-specific distributions.

On Windows, many users install Gpg4win, which includes GnuPG and graphical tools.

After installation, check that GPG works: 

gpg --version

This should print the installed version and supported algorithms.

Step 2: Download the File and Signature

Download the file and its signature from the project’s official source whenever possible.

For example: 

example-1.0.tar.gz
example-1.0.tar.gz.asc

Keep both files in the same folder to make verification easier.

Be careful with unofficial mirrors, forum links, social media posts, shortened URLs, and copied download pages. A signature is useful only if the public key and signed file are handled carefully.

If a project publishes checksums as well as PGP signatures, the PGP signature is generally more meaningful because it can authenticate the checksum file or release file. A checksum alone only proves that two copies match; it does not prove who published the checksum unless the checksum itself is authenticated.

Step 3: Get the Signer’s Public Key

To verify a signature, you need the signer’s public key.

The public key may be available from:

  • The project’s official website.
  • The project’s official repository.
  • A signed release page.
  • A trusted documentation page.
  • A keyserver.
  • A developer profile.
  • A security contact page.
  • A package maintainer page.

A public key may look like this: 

-----BEGIN PGP PUBLIC KEY BLOCK-----
...
-----END PGP PUBLIC KEY BLOCK-----

Save it as a file, for example: 

developer-public-key.asc

Then import it: 

gpg --import developer-public-key.asc

Importing a key does not mean you trust it. It only adds it to your local keyring.

This distinction is important. A key can be imported and still be unverified.

Step 4: Check the Public Key Fingerprint

The fingerprint is the most important part of key verification.

A fingerprint is a compact representation of a public key. It is designed to let users compare keys accurately.

To display the fingerprint of an imported key, use: 

gpg --fingerprint

Or search for a specific identity: 

gpg --fingerprint name@example.com

GPG will show the key information and fingerprint.

A fingerprint may look like grouped hexadecimal characters. Compare it carefully with the fingerprint published by the signer through a trusted source.

Do not compare only the short key ID. Short key IDs are not enough for strong verification.

A safer process is to compare the full fingerprint from more than one reliable source, such as:

  • The official website over HTTPS.
  • The official source code repository.
  • A signed release announcement.
  • A known developer profile.
  • A printed fingerprint from a conference or official document.
  • Direct confirmation from the owner through a trusted channel.

If the fingerprint does not match exactly, stop.

Do not verify the file. Do not run it. Do not assume it is a harmless typo.

Step 5: Understand Trust Warnings

After importing a public key and verifying a signature, GPG may show a warning such as: 

WARNING: This key is not certified with a trusted signature!
There is no indication that the signature belongs to the owner.

This warning does not always mean the signature is invalid.

It means GPG does not know whether you personally trust that the key belongs to the claimed owner. GPG is telling you that the cryptographic signature matches the imported key, but the trust relationship has not been established in your local keyring.

This is why fingerprint verification matters.

A common beginner mistake is to panic at this warning or ignore it completely. The correct response is to verify the fingerprint through a trusted source.

Step 6: Verify a Detached Signature

For a detached signature, use: 

gpg --verify example-1.0.tar.gz.asc example-1.0.tar.gz

The first file is the signature.

The second file is the file being verified.

If the verification succeeds, GPG may print something like: 

gpg: Signature made ...
gpg: Good signature from "Example Developer <developer@example.com>"

A “Good signature” means the signature matches the file and the public key.

But again, it is only meaningful if the public key fingerprint has been verified.

If the file has been changed, corrupted, or replaced, verification should fail.

Step 7: Verify a Clear-Signed Message

For a clear-signed message, save the entire signed text into a file, for example: 

announcement.asc

Then run: 

gpg --verify announcement.asc

GPG will check whether the message was signed by a key in your keyring and whether the content was modified.

Be careful when copying clear-signed messages. Extra formatting, missing lines, changed spaces, or modified line endings can sometimes affect verification.

Always copy the entire message, including: 

-----BEGIN PGP SIGNED MESSAGE-----

and: 

-----END PGP SIGNATURE-----

Step 8: Verify a Signed File With Embedded Content

If the signature and content are combined, GPG may verify and extract the content using: 

gpg --output verified-file --decrypt signed-file.asc

Although the command uses the word “decrypt,” it can also process signed data and recover the original content depending on the structure.

For ordinary detached signatures, use `--verify` instead.

Step 9: Read the Verification Output Carefully

Do not look only for the word “Good.”

Read the output carefully.

Important details include:

  • Whether the signature is good or bad.
  • Which key made the signature.
  • The fingerprint or key ID.
  • The signing date.
  • Whether the key is expired.
  • Whether the key has been revoked.
  • Whether GPG warns that the key is untrusted.
  • Whether the signature was made by an expected subkey.
  • Whether the file name matches the release you intended to verify.

A valid signature from the wrong key is not good enough.

A good signature from an expired or revoked key may require further investigation.

A good signature on the wrong file does not help.

Verification is a careful process, not a checkbox.

Step 10: What a Good Signature Means

A good signature usually means:

  • The file matches the signature.
  • The signature was created by a private key corresponding to the public key in your keyring.
  • The content has not changed since signing.

It does not automatically mean:

  • The signer is trustworthy.
  • The software is safe.
  • The key was not stolen.
  • The file is legally safe to use.
  • The project is legitimate.
  • The public key was verified correctly.
  • The signature was created recently.
  • The signed file is the one you intended to download.

A good signature is one strong piece of evidence. It is not the entire security story.

What a Bad Signature Means

A bad signature means verification failed.

Possible causes include:

  • The file was modified.
  • The download is incomplete or corrupted.
  • The wrong signature file was used.
  • The wrong original file was used.
  • The signature belongs to a different version.
  • The file was tampered with.
  • The message formatting changed.
  • The wrong public key is being used.
  • The signature file was damaged.

If verification fails, do not run or trust the file.

Download the file and signature again from the official source. Check that the filenames and versions match. Re-check the public key fingerprint.

If it still fails, treat the file as unsafe or contact the project through official channels.

Checking Key Expiration and Revocation

Public keys can expire or be revoked.

An expired key may no longer be intended for new signatures. A revoked key may have been compromised, replaced, or retired.

GPG output may warn about expiration or revocation.

To inspect keys: 

gpg --list-keys --with-fingerprint

To refresh keys from a keyserver, if appropriate: 

gpg --refresh-keys

However, keyservers are not always the best source of truth. Official project pages, signed announcements, and repository documentation may provide better context.

If a key is revoked, do not trust new signatures from it unless the project provides a clear explanation through verified channels.

Verifying Software Downloads

PGP verification is especially important for software downloads.

A safe workflow looks like this:

  • Download the software from the official site.
  • Download the detached signature.
  • Download or import the public signing key.
  • Verify the signing key fingerprint from a trusted source.
  • Run `gpg --verify`.
  • Confirm that the signature is good.
  • Confirm that the key identity and fingerprint match expectations.
  • Only then install or run the software.

This helps protect against tampered downloads, compromised mirrors, malicious reuploads, and accidental corruption.

It does not guarantee that the software itself is secure, but it confirms that the file matches what the signer released.

Verifying Checksums With PGP

Many projects publish checksum files, such as: 

SHA256SUMS
SHA256SUMS.asc

In this model, the PGP signature signs the checksum file. The checksum file then verifies the downloaded files.

The workflow is: 

gpg --verify SHA256SUMS.asc SHA256SUMS

If the signature is good and the key is verified, then check the file hash: 

sha256sum -c SHA256SUMS

This approach is common because one signed checksum file can cover many downloads.

The important point is that the checksum file must be authenticated. A checksum copied from the same untrusted place as the file does not prove much by itself.

Verifying Email Messages

PGP can also verify signed email messages.

Some email clients support OpenPGP directly or through plugins. If properly configured, the client can show whether a message signature is valid.

For email verification, the same key rules apply:

  • Import the sender’s public key.
  • Verify the fingerprint.
  • Check whether the signature is valid.
  • Watch for warnings.
  • Confirm that the signed identity matches the sender.
  • Be careful with forwarded or modified messages.

Email signatures can be useful for security advisories, sensitive statements, software announcements, or identity confirmation.

However, email clients vary in how clearly they display verification results. Users should learn how their specific client handles OpenPGP signatures.

Verifying Text Statements

Public figures, developers, administrators, or projects may publish signed text statements.

These may include:

  • Security announcements.
  • Warrant canaries.
  • Release notes.
  • Address changes.
  • Identity proofs.
  • Emergency warnings.
  • Public policy statements.
  • Cryptocurrency address confirmations.

To verify them, save the complete signed message and run: 

gpg --verify statement.asc

The value depends on whether the signing key was previously known and verified.

A signed statement from a newly discovered key is weaker than a signed statement from a long-established verified key.

Keyservers and Their Limits

Keyservers are directories that store public keys. They can make it easier to find keys, but they do not automatically prove that a key belongs to the claimed person.

Anyone may be able to upload a key using someone else’s name or email address. For that reason, keyserver results should not be trusted blindly.

A keyserver can help distribute keys, but fingerprint verification still matters.

The safer approach is:

  • Get the fingerprint from an official source.
  • Import the key.
  • Compare the full fingerprint.
  • Verify the signature.

Do not assume a key is authentic only because it appears on a keyserver.

Full Fingerprints vs Short Key IDs

A key ID is a shortened identifier for a key. It is convenient, but convenience can be dangerous.

Short key IDs are not enough for serious verification because collisions and impersonation risks have existed in practice.

Use full fingerprints whenever possible.

A full fingerprint gives a much stronger way to confirm that the imported key is the expected one.

When documentation provides only a short key ID, look for a better source. A serious project should publish the full fingerprint.

Signing a Verified Key

After verifying a key’s fingerprint, users may locally sign the key to mark it as verified in their own keyring.

This is optional and depends on the user’s workflow.

A local signature can help GPG remember that the key was verified, reducing repeated trust warnings.

However, users should not sign keys casually. Signing a key means making a statement about identity verification. Only sign a key after checking the fingerprint through a reliable channel.

For private local use, some users may mark trust locally rather than publish a signature publicly.

Common PGP Verification Mistakes

Common mistakes include:

  • Importing a key and assuming it is trusted.
  • Comparing only short key IDs.
  • Ignoring fingerprint mismatches.
  • Downloading the public key from the same untrusted mirror as the file.
  • Using the wrong signature file.
  • Verifying the wrong version.
  • Ignoring expiration or revocation warnings.
  • Treating “Good signature” as proof that software is safe.
  • Copying only part of a clear-signed message.
  • Trusting keyserver results without verification.
  • Ignoring warnings because the command “worked.”
  • Running a file before verifying it.
  • Failing to check whether the signature belongs to the expected project.

PGP verification is reliable only when the human process is reliable.

Troubleshooting Common Errors

“No public key”

This means GPG does not have the public key needed to verify the signature.

Import the signer’s public key, then verify the fingerprint before trusting it.

“BAD signature”

This means the signature does not match the file or message.

Do not use the file. Re-download the correct file and signature from the official source.

“Good signature, but key is not certified”

This means the signature matches the key, but GPG does not know whether you trust that key.

Verify the full fingerprint through a trusted source.

“Can’t check signature: No public key”

The required public key is missing from your keyring.

Find the correct public key from an official source and import it.

“Signature made by expired key”

The signature may have been made by a key that is now expired or was already expired at signing time. Check project documentation, signing date, and key status.

“Key has been revoked”

A revoked key should be treated with caution. Check official announcements before trusting any signature involving it.

PGP Verification on Windows

Windows users can use Gpg4win or another trusted OpenPGP tool.

A common command-line workflow is still similar: 

gpg --import developer-public-key.asc
gpg --fingerprint developer@example.com
gpg --verify file.asc file

Graphical tools may make this easier, but users should still understand the output.

The most important part remains the same: verify the public key fingerprint from a trusted source.

PGP Verification on macOS

On macOS, GPG can be installed using package managers or graphical distributions.

The basic workflow is: 

gpg --import developer-public-key.asc
gpg --fingerprint developer@example.com
gpg --verify file.asc file

macOS users should be careful with downloaded applications and disk images. PGP signatures may complement, but do not replace, platform code-signing and notarization checks.

PGP Verification on Linux

Many Linux users already have GPG installed.

A common workflow is: 

gpg --import maintainer-key.asc
gpg --fingerprint maintainer@example.org
gpg --verify package.tar.xz.asc package.tar.xz

Linux distributions often have package managers that verify repository metadata automatically. Manual PGP verification is most useful when downloading software directly from a project, checking source releases, or verifying external files.

PGP Verification and Package Managers

Many package managers use cryptographic signatures internally.

For example, Linux package managers often verify repository metadata and packages automatically. This is different from manually verifying a file with GPG, but the security goal is similar: confirm that software comes from an expected trusted source and has not been modified improperly.

Users should not disable package signature checks to bypass errors. A signature error may indicate a real problem, such as a broken mirror, expired key, misconfiguration, or attempted tampering.

PGP Verification and Trust Models

PGP uses a decentralized trust model.

Unlike the web browser certificate system, where certificate authorities play a central role, PGP allows users to decide which keys they trust. This can be powerful, but it also creates usability challenges.

The user is responsible for verifying public keys.

Different communities handle this in different ways:

  • Direct fingerprint comparison.
  • Signed keys.
  • Web of trust.
  • Project-maintained key lists.
  • Repository signatures.
  • Developer documentation.
  • Offline verification.
  • Published security policies.

There is no single universal trust method that fits every situation.

The key question is always: how do I know this public key belongs to the signer I expect?

PGP Verification vs Encryption

Verification and encryption are different.

Encryption protects confidentiality. It keeps content secret from people who do not have the right key.

Verification checks authenticity and integrity. It confirms that content matches a signature from a particular key.

A message can be encrypted but not signed.

A message can be signed but not encrypted.

A software release is usually signed, not encrypted, because the goal is not to keep it secret. The goal is to let anyone verify that the release has not been modified and was signed by the expected project.

PGP Verification vs Hash Checksums

A hash checksum verifies that a file matches a specific hash value.

A PGP signature verifies that a file or checksum was signed by a private key corresponding to a public key.

Checksums are useful for detecting accidental corruption. They can also detect tampering if the checksum comes from a trusted source.

PGP signatures add authentication. They help prove who published the checksum or file.

The strongest workflow often uses both:

  • Verify the PGP signature on the checksum file.
  • Use the checksum file to verify the downloaded files.

PGP Verification and Supply Chain Security

PGP verification is part of supply chain security.

Software supply chain attacks may involve tampered downloads, compromised mirrors, fake release pages, malicious updates, stolen signing keys, or impersonated maintainers.

PGP signatures help defend against some of these risks by allowing users to check whether a release was signed by the expected key.

However, signatures are not a complete supply chain solution. If the signing key is stolen, if the project itself is compromised, or if the signed code contains malicious changes before signing, verification may still succeed.

PGP verification is one layer. It should be combined with secure build systems, reproducible builds when available, code review, trusted distribution channels, and careful key management.

Security Best Practices

Good PGP verification habits include:

  • Download files from official sources.
  • Use detached signatures when provided.
  • Import public keys from trusted sources.
  • Compare full fingerprints, not short key IDs.
  • Check multiple sources for important keys.
  • Watch for expiration and revocation warnings.
  • Verify before running or installing files.
  • Keep GPG updated.
  • Do not ignore warnings.
  • Keep a record of trusted fingerprints for important projects.
  • Treat key changes as significant events.
  • Be cautious with mirrors and reposted files.
  • Understand that a good signature is not the same as safe software.

For high-risk situations, verify keys through more than one channel.

Example: Complete Verification Workflow

A careful workflow might look like this: 

# 1. Import the public key
gpg --import developer-public-key.asc

# 2. Show the fingerprint
gpg --fingerprint developer@example.com

# 3. Compare the full fingerprint with an official trusted source

# 4. Verify the detached signature
gpg --verify example-1.0.tar.gz.asc example-1.0.tar.gz

If the fingerprint matches and GPG reports a good signature from the expected key, the file has passed signature verification.

If anything does not match, stop and investigate.

High-Risk Verification Situations

Some situations require extra care:

  • Security software downloads.
  • Operating system images.
  • Cryptocurrency wallet releases.
  • Firmware downloads.
  • Privacy tools.
  • Password managers.
  • Backup tools.
  • Administrator scripts.
  • Emergency security updates.
  • Public key changes.
  • Files downloaded from mirrors.
  • Files shared through forums or chat.

In these situations, do not rush. Attackers often rely on urgency.

A fake emergency update can be more dangerous than an ordinary malicious file because users may install it quickly without checking signatures.

Key Rotation

Projects may rotate signing keys over time.

Key rotation can happen because:

  • A key is expiring.
  • A stronger algorithm is being adopted.
  • A maintainer changes roles.
  • A project changes release process.
  • A key may have been exposed.
  • Security policy is updated.

A legitimate key rotation should be announced clearly and signed by the old key when possible. Users should treat unexplained key changes cautiously.

If a project suddenly signs releases with a new key and provides no clear verification path, investigate before trusting it.

Revocation Certificates

A revocation certificate allows a key owner to mark a key as no longer valid, often because it was compromised, lost, or retired.

Revocation is important because public keys can spread widely. Once a key is published, people may continue using it unless they learn that it has been revoked.

Users verifying signatures should pay attention to revocation warnings and updated project announcements.

A revoked key should not be trusted for new signatures without a very clear explanation from an official source.

The Human Side of PGP Verification

PGP verification is technically strong but often difficult for users.

The hardest part is not the command. The hardest part is trust.

A user must decide where to get the public key, how to verify the fingerprint, whether warnings matter, and whether a key change is legitimate.

This is why many people skip verification even when signatures are available.

A good verification guide should make the process realistic: check the fingerprint, verify the signature, read the output, and understand what the result means.

PGP verification is not perfect, but it is much better than blindly trusting downloads.

Common Myths About PGP Verification

“A good signature means the file is safe.”

False. A good signature means the file matches the signature and the signing key. It does not prove that the file is free from bugs, malware, or bad design.

“Importing a key means I trust it.”

False. Importing a key only adds it to the keyring. Trust requires fingerprint verification.

“A keyserver proves identity.”

False. A keyserver distributes public keys. It does not automatically prove that a key belongs to a specific person or project.

“Short key IDs are enough.”

False. Use full fingerprints whenever possible.

“PGP is only for email.”

False. PGP is also widely used for file verification, software releases, signed statements, and checksums.

“If verification fails, I can ignore it if the file came from the official site.”

False. A failed signature may indicate corruption, mismatch, misconfiguration, or tampering. It should be investigated.

“PGP verification is too technical to matter.”

False. It can be learned step by step and is especially important for high-risk downloads.

Frequently Asked Questions

What is PGP verification?

PGP verification is the process of checking a digital signature to confirm that a file or message matches a public key and has not been modified since it was signed.

What command verifies a PGP signature?

For a detached signature, the common GPG command is: 

gpg --verify signature.asc file

For a clear-signed message: 

gpg --verify message.asc

What does “Good signature” mean?

It means the signature matches the signed content and the public key in your keyring. It does not automatically prove that the key belongs to the claimed person unless you have verified the fingerprint.

Why does GPG say the key is not trusted?

GPG is warning that it does not know whether you trust the key’s identity. You need to verify the full fingerprint through a trusted source.

What is a public key fingerprint?

A fingerprint is a unique-looking representation of a public key used to compare and verify that the key is the expected one.

Should I trust keys from keyservers?

Not automatically. Keyservers help distribute keys, but users still need to verify fingerprints through trusted sources.

What is a detached signature?

A detached signature is a separate signature file used to verify another file. It commonly ends in `.asc` or `.sig`.

Can PGP verification detect a corrupted download?

Yes. If the file changed after signing, verification should fail.

Can PGP verification detect malware?

Not directly. It verifies authenticity and integrity, not whether the content is safe.

What should I do if verification fails?

Do not run or trust the file. Re-download the file and signature from official sources, check that versions match, verify the public key fingerprint, and investigate further.

Final Thoughts

PGP verification is one of the most practical ways to check whether a downloaded file, signed message, or public statement matches an expected cryptographic identity.

It is not perfect, and it is not always easy. The commands are simple, but the trust decisions require care. A signature is only as useful as the public key behind it, and a public key is only trustworthy if its fingerprint has been verified.

Used correctly, PGP verification can protect against tampered downloads, fake releases, corrupted files, malicious mirrors, and forged messages. Used carelessly, it can create false confidence.

The best approach is step-by-step: get the file, get the signature, import the public key, verify the full fingerprint, run the verification command, read the output carefully, and understand what the result does and does not prove.

PGP verification is not about trusting blindly. It is about replacing blind trust with evidence.

Retrieved from "https://inthehiddenwiki.net/index.php?title=PGP_verification:_step-by-step&oldid=381"