PGP Encryption & Signatures

Files.com can encrypt and decrypt PGP files as part of a partner exchange. Encryption controls who can read the contents, while a signature lets the recipient check that the signed content came from someone holding the expected signing key and has not changed. A partner may require either protection or both.

OpenPGP is the interoperable format underlying these operations. PGP is the name associated with the original software; GPG, or GnuPG, is an implementation of OpenPGP. Partner agreements frequently use “PGP” for the format regardless of the tool producing it.

The Two Key Relationships

For an encrypted delivery from Files.com, you configure the recipient's public encryption key, and the recipient decrypts the file with its corresponding private key. For incoming files that Files.com decrypts, the partner encrypts with your public key and Files.com uses your private key. Anyone holding that public key can prepare an encrypted delivery, so decryption confirms that the file was addressed to your key without identifying which sender created it.

Signing uses the keys in the other direction: the sender signs with its private signing key, and the recipient verifies with the sender's trusted public key. The recipient needs to associate that key with the expected sender through a verified fingerprint. A name or email address inside the key is not enough to confirm the association.

For a signed-and-encrypted delivery, the sender signs with its own private key and encrypts for the recipient's public key. The recipient uses its private key to decrypt and the sender's public key to verify. Each business keeps its own key pair so the sender's identity remains distinct from the recipient's ability to read the file.

A valid signature confirms that the signed content has not changed since it was signed with the matching private key. An invoice with a valid signature can still contain the wrong amount, come from someone without approval authority, or fail import into accounting. Those checks belong to the business process.

Signature Forms

The agreed signature form determines which files travel and what the receiver verifies.

An embedded signature travels with the data inside an OpenPGP message, which can also be encrypted. The receiving tool recovers the content and checks its associated signature from that message.

A detached signature travels as a separate file, such as invoices.csv.sig alongside invoices.csv. Verification requires both files and checks the original file's bytes. Even a change to the CSV's line endings or encoding can invalidate the signature while leaving the visible text looking the same.

A clear-signed message contains readable text and an armored signature in one text file. It is intended for text, with rules for text canonicalization; it is not a way to preserve arbitrary binary files byte for byte. Choose a detached signature when the original file's exact bytes need to remain separate and unchanged.

Verification With GnuPG

First confirm the sender's public-key fingerprint through the established partner relationship, then import the public key into the keyring used for verification:

gpg --show-keys --with-fingerprint sender-public.asc
gpg --import sender-public.asc

For a detached signature, give both the signature and its data file explicitly:

gpg --verify invoices.csv.sig invoices.csv

For a clear-signed message:

gpg --verify signed-message.asc

GnuPG can also verify signatures while decrypting a signed-and-encrypted message when the sender's public key is available:

gpg --output invoices.csv --decrypt invoices.csv.gpg

Inspect the verification result as well as the decryption result before releasing output for processing. A tool can write readable output even when the required signature is missing or invalid. Automated verification must reject missing or unacceptable signatures, check the expected signer, and release output only after those checks pass. Use GnuPG's documented status interface for automation rather than interpreting a human-readable success phrase alone.

GnuPG can report a “good signature” and still warn about an untrusted identity. The first result means the signature matches the key; the warning concerns whether that key represents the intended sender. Confirming the owner through the partner relationship resolves a question that importing the key alone cannot answer.

Binary and Armored Output

OpenPGP messages can be binary or ASCII-armored. Armor encodes the binary information as printable text with boundary lines such as -----BEGIN PGP MESSAGE-----. It helps systems that need text transport, while increasing the encoded size. Armor is an encoding choice, not additional encryption.

.pgp and .gpg commonly name binary OpenPGP messages. .asc commonly names armored content. Detached signatures can use .sig for binary or .asc for armored output. These are conventions: .asc can also contain a public key, private key, or clear-signed text. Confirm the contents and the agreed profile, not only the extension.

Agree on encryption, signing, signature form, armor, compression, filenames, and supported key algorithms before testing. A partner's older OpenPGP implementation may require a specific compatible profile even when it recognizes the key.

Files.com Processing

Files.com can encrypt, decrypt, and recrypt files through supported manual actions, folder processing, and Automations. Its GPG signing constraints state that decryption does not verify a signature. When the exchange requires verified signatures, run a separate verification step before import.

That verification needs to finish before the receiving application consumes the file, with the signed original and result retained if the exchange needs evidence later. A checksum of the decrypted CSV or a successful GPG processing event reports a different result and cannot substitute for checking the sender's signature.