Flamingo Raises $4.5M Seed Round · Led by Vertex Ventures, bringing total funding to $6.7M to build the open, AI-native layer for IT and security.
What PGP is, how its keys and signatures work, where IT teams still meet it in 2026 and what replaced it for everyday email.
A bank sends over a public key and asks for payroll files "PGP encrypted and signed", and the person who set that up at your company left in 2019. The tool is older than many of the people using it, and the three names it goes by (PGP, OpenPGP, GnuPG) do not help. This guide explains what PGP is, how its keys and signatures work, where an IT team still meets it in 2026, and what replaced it for everything else.
PGP solves two problems at once: nobody but the recipient can read the message, and the recipient can prove who sent it. It does that with two kinds of key, used in a fixed order.
Public-key encryption is slow, so PGP does not encrypt your file with the recipient's public key. It generates a random one-time key called a session key, encrypts the file with that key using a fast symmetric cipher such as AES, and then encrypts the session key with the recipient's public key. The recipient's private key recovers the session key, and the session key decrypts the file. This two-step design is called hybrid encryption, and it is why a PGP message to five recipients contains one encrypted file and five small encrypted copies of the session key. The cipher explainer covers the symmetric and asymmetric algorithms underneath.
The signature runs in the other direction. The sender hashes the message, encrypts the hash with their own private key, and attaches it. Anyone with the sender's public key can decrypt that hash and compare it with a fresh hash of the message. A match proves two things: the message came from whoever holds that private key, and nothing changed in transit. Encryption and signing are independent, so a file can be signed but readable, encrypted but anonymous, or both.
The name confusion is the first thing to clear up when a vendor asks for "a PGP key".
PGP is the original program, written by Phil Zimmermann in 1991 and now a commercial product line owned by Broadcom through its Symantec acquisition. You will rarely install it. OpenPGP is the open standard that describes the message and key formats, so that any two programs can exchange encrypted files. It was first published by the IETF as RFC 4880 in 2007 and replaced by RFC 9580 in July 2024. GnuPG, usually shortened to GPG, is the free software implementation of that standard, and it is the gpg command on every Linux server and the engine behind Gpg4win and Kleopatra on Windows. When a bank says "send us your PGP public key", it means an OpenPGP key, and GnuPG is what you generate it with.
The 2024 revision matters for anyone generating keys today. RFC 9580 drops the algorithms that had quietly become weak: MD5, SHA-1 and RIPEMD hashes, the IDEA, 3DES and CAST5 ciphers, ElGamal and DSA keys, and RSA keys shorter than 3072 bits. It adds authenticated encryption, so a tampered message fails to decrypt instead of producing garbage, and the modern Curve25519 and Curve448 key types. Proton's summary of the refresh lists the full set.
There is a catch. GnuPG's maintainers disagreed with parts of the new standard and published their own fork, LibrePGP, so current GnuPG implements RFC 4880 plus its own extensions rather than RFC 9580. Thunderbird, Proton and the major libraries follow the RFC. In practice the two sides still read each other's RSA and Curve25519 keys, and the gap only bites if you turn on the newest formats on one side. The safe default for a key you will hand to a vendor is an RSA 3072 or 4096 key, or an Ed25519 key, with no exotic options, which both camps accept.
GnuPG itself moved on in 2025. The 2.5 series became the stable release, 2.5.24 is current as of October 2026 per the GnuPG site, and the older 2.4 series is heading for end of life. A server still on 2.2 is running a version from 2017.
A public key is only useful if you know it belongs to the person you think it does. PGP and the certificate world answer that question differently, and the difference explains most of what follows.
TLS and S/MIME use certificate authorities. A company you have already decided to trust, such as DigiCert or Let's Encrypt, checks an identity and signs the key, and your software trusts whatever the authority signed. PGP has no authority. Instead, each key has a fingerprint, a 40-character hash that identifies it, and you check that fingerprint against something out of band: the vendor's website, a phone call, a printed letter. Users can also sign each other's keys to say "I checked this one", and a key signed by someone you already trust gains some of that trust. That network of signatures is the web of trust.
The web of trust never grew past hobbyists and open-source projects. For an IT team the practical version is simpler: treat every key you receive as unverified until you have compared the fingerprint through a second channel, and record where you got it. The public keyservers that used to distribute keys are a weak link, since anyone can upload a key with any name on it. The modern keys.openpgp.org server only publishes a key after the email address on it confirms, which fixes the worst of that.
Email was PGP's original job and is now its smallest one. Four places keep it alive.
Signed software and packages. Every apt and yum repository, every Linux ISO, HashiCorp's tools, Signal's desktop builds and plenty of Windows utilities ship an OpenPGP signature next to the download. The package manager checks it on every install, which is why a repository with an expired key stops updates cold. This is the PGP a technician touches most often, and it rarely gets noticed.
File exchange with banks, payroll and insurers. SFTP encrypts the connection, and PGP encrypts the file itself, so it stays unreadable on the counterparty's server, in their backups and in whoever's inbox it gets forwarded to. Banks and payroll providers require both for payment and HR files, and they usually want the file signed with your key as well. The setup is one key pair per integration, exchanged once, and then it runs unattended for years until a key expires or a vendor's software chokes on a feature it does not support. The thread below is the version of that story that keeps landing on r/sysadmin: subkeys that some vendors handle and some cannot.
The replies carry the lesson. Managed file transfer products support a small subset of PGP, so the key you hand a vendor should be plain: one primary key with an encryption subkey generated by the defaults, RSA or Ed25519, no custom subkey layouts. Keep the private key in a password manager or a hardware token, not on the transfer server, and put the expiry date in the calendar that the integration's owner reads.
Encrypted email, where someone insists. Thunderbird has OpenPGP built in since version 78, Proton Mail uses it under the hood for every mailbox, and Mailvelope adds it to webmail in a browser extension. Outlook does not support it natively, and Microsoft's own email encryption guide states that Microsoft 365 does not support PGP/MIME, only the older inline form. That one sentence is why PGP email in a Microsoft shop is a per-person exception, never a policy.
Backup and archive encryption. Some backup tools and many scripts that push archives to cloud storage use gpg --symmetric or a public key to encrypt before upload, because it works on every platform and needs no agent. It does the job, and it moves the whole risk to one question: where is the private key, and who can find it in five years. The same question applies to disk encryption keys, which is why the BitLocker guide spends most of its length on key escrow.
If you run OpenFrame, a script run across a client's devices reports which machines have gpg installed and at what version, with the output collected in one place, so the 2017-era installs show up before a vendor's key format does.
The cryptography was never the problem. Everything around it was.
Key management falls on the user. Both people need a key pair, need to exchange public keys, need to verify fingerprints, and need to keep a private key for years across laptop replacements. Lose the key and every message ever sent to it is gone. Companies that tried PGP email at scale ended up running a key directory, a revocation process and a help desk queue for it.
There is no forward secrecy. PGP encrypts every message to the same long-lived key, so a private key stolen in 2026 decrypts every message that key ever received, back to the day it was made. Signal and TLS 1.3 generate fresh keys per session for exactly this reason, and OpenPGP has no equivalent.
The clients leaked. In May 2018 a team of European researchers published EFAIL, a pair of attacks that made an email client decrypt a captured message and send the plaintext to an attacker's server through a hidden HTML image load. Per the EFAIL disclosure, exfiltration channels existed in 25 of the 35 S/MIME clients and 10 of the 28 OpenPGP clients tested. The fix was in the clients and the standard, and it took years to land, which is part of why RFC 9580 added authenticated encryption.
Metadata stays in the clear. PGP encrypts the body and attachments. The subject line, the sender, the recipients and the timestamps travel as plain text through every server on the path, because the mail protocol needs them. Anyone watching the traffic knows who is talking to whom and about what, and only the paragraphs are hidden.
The r/sysadmin thread below is the question an IT lead gets after a bank refuses to open an encrypted email, and the top reply is what teams settled on: let the bank start the encrypted conversation on its own portal, and keep TLS between servers for everything else.
Three tools cover the ground PGP email was meant to cover, and each trades something for ease of use.
| OpenPGP | S/MIME | Microsoft 365 Message Encryption | |
|---|---|---|---|
| Who vouches for the key | Fingerprint check, web of trust | Certificate authority | Microsoft, via the tenant |
| Who can read the message | Holder of the private key only | Holder of the private key only | Recipient after sign-in or one-time passcode; Microsoft holds the keys |
| Works with any recipient | Only one with a PGP key | Only one with an S/MIME certificate | Any address, read in a browser portal |
| Outlook support | None for PGP/MIME | Built in, needs a certificate per user | Built in, policy driven |
| Can the mail gateway scan it | No | No | Yes, before encryption |
| Forward secrecy | No | No | No |
| Fits | Cross-platform file exchange, signed releases | Government and regulated peer-to-peer mail | Sending sensitive mail to customers and outsiders from Microsoft 365 |
Microsoft's own guidance says the same thing in its own words: S/MIME when both sides need true peer-to-peer encryption, Purview Message Encryption for sensitive mail to anyone outside, and TLS between servers underneath both. TLS is on by default between Microsoft 365, Google Workspace and every major provider, and for the audit question "is email encrypted in transit" it is usually the whole answer. The switches that make it enforceable sit in the email security guide.
For messages rather than mail, Signal and the end-to-end modes in the big messaging apps give forward secrecy and automatic key management, which is the thing PGP never had. For files between two organizations, PGP over SFTP is still the answer, because it is the one format every bank's transfer platform understands.
This is the PGP task worth knowing by hand, because it is the one that catches a tampered download. The example uses GnuPG on any platform; Kleopatra does the same through a window.
First import the publisher's key. Projects publish it on their site or point to a keyserver:
codegpg --import publisher-key.asc gpg --fingerprint "Publisher Name"
Compare the fingerprint gpg prints against the one on the publisher's website, a second source, not the page you downloaded the key from. This is the step that does the work. A signature only proves the file matches a key; the fingerprint check proves the key belongs to the publisher.
Then download the signature file that sits next to the installer, usually with a .sig or .asc extension, and verify:
codegpg --verify installer.zip.sig installer.zip
Two outcomes matter. Good signature from "Publisher Name" means the file is intact and signed by that key. BAD signature means the file or the signature changed, and the download does not get installed. A warning that reads This key is not certified with a trusted signature will appear under a good signature almost every time. It means your local gpg has not been told to trust the key, which is the web of trust talking. The fingerprint comparison you already did is the trust.
The same three commands, with --encrypt --recipient and --sign in place of --verify, are the whole bank file exchange. The decryption explainer covers what happens on the receiving side.
Every PGP integration has one fragile moment: the day two organizations swap keys. The failure is never cryptographic. It is a private key attached to an email because someone asked for "your key", a public key pasted into a ticket with the header lines stripped, or a key generated with a two-year expiry that nobody wrote down. The SAP and bank forums are full of the first one, and the reply is always the same four words. Never exchange private keys.
The fix is a short written procedure for the integration owner: generate the pair on a machine you control, export only the public key with gpg --armor --export, send it, confirm the fingerprint by phone or on a call, store the private key and its passphrase in the password manager, and put the expiry date on a calendar with a reminder 60 days out. Treat the counterparty's key the same way in reverse. That page is the difference between an integration that runs for five years and one that breaks the first Friday the payroll person is on leave.
PGP is a 1991 design that still does two things well: it signs software so you can trust a download, and it encrypts a file so it stays encrypted wherever it lands. Hybrid encryption with a session key makes it fast, the signature makes it provable, and the fingerprint check is the only trust it has. It lost the email war to key management, no forward secrecy, leaky clients and metadata in the clear, and TLS plus Microsoft 365 message encryption or S/MIME took that job. Keep it for signed packages and bank file exchange, generate plain RSA 3072 or Ed25519 keys, and write down where the private key lives.
If the encryption vocabulary is still fuzzy, the FIPS 140-3 guide covers how the algorithms underneath get validated, and the email archiving post covers what happens to encrypted mail once it has to be retained.
Content Marketing Lead
Ohayo! I run content, SEO, social, and community at Flamingo. Before IT, I worked as a correspondent for Ukraine's Public Broadcasting Company and have a Master's in journalism.
Still deciding?
Ask Mingo answers from our docs and customer stories.
Still deciding?
Ask Mingo answers from our docs and customer stories.
