Security & vulnerability disclosure.
An honest description of what PGPony protects, what it doesn't, and how to report a flaw.
The honest summary: PGPony correctly implements OpenPGP and keeps your private keys in the device's secure enclave. It does not protect against a compromised device, coerced access, traffic analysis, or any threat above the cryptographic layer. No third-party audit has been completed. Security reports go to NorseHorse@norsehor.se with subject line SECURITY.
The threat model.
Where the trust boundary sits, drawn out.
What PGPony protects against — and what it doesn't.
Encryption is a tool with a specific job. Knowing its edges matters.
- Network eavesdroppers. Anyone observing the wire — ISP, public Wi-Fi attacker, hostile network operator — cannot read encrypted messages without the recipient's private key.
- Server-side breaches. Mail providers, chat platforms, and file hosts that carry PGP-encrypted content cannot read it even if they're fully compromised.
- Tampering in transit. Signed messages reveal tampering. Verification fails if a single byte changed.
- Forged identity (at the cryptographic layer). A correctly verified signature proves the message was produced by the holder of a specific private key — not someone impersonating them.
- Key extraction by a malicious app. Other apps on your device cannot read PGPony's keys; the OS keystore enforces process-level isolation.
- A compromised device. If your phone is rooted, jailbroken, or running active malware with sufficient privileges, no client-side encryption can save you. The key has to live somewhere usable.
- Coercion. A passphrase you can be made to reveal is a passphrase the message can be made to reveal.
- Metadata leakage. PGP encrypts content, not envelopes. Recipients, timing, message sizes, and subject lines (in email) remain visible to anyone watching the channel.
- Wrong-key encryption. If you encrypt to a public key the attacker controls — because they tricked you into importing it — PGPony cannot detect the substitution. Verify fingerprints out of band.
- Forgotten passphrases. There is no reset. A lost passphrase is a destroyed key. Back up accordingly.
- Traffic analysis. An attacker who can see that you publish or look up keys still learns useful information about your network, even if they can't read your messages.
What's actually doing the math.
PGPony does not roll its own cryptographic primitives. The OpenPGP packet layer is hand-written and auditable; the underlying math comes from established libraries.
- Symmetric & hashing
- Apple CryptoKit (AES-GCM, AES-CTR, SHA-256/512)
- Curve25519 / Ed25519
- Apple CryptoKit native implementations
- OpenPGP packet layer
- Hand-rolled parser & builder (Swift), auditable
- RSA legacy
- ObjectivePGP (read & import only)
- Argon2id (v6 S2K)
- Pure-Swift implementation, parsing only — not yet validated against RFC 9580 Appendix A test vectors
- Key storage
- iOS Keychain with Secure Enclave (every iPhone since 5s)
- OpenPGP primitives
- Bouncy Castle (bcpg-jdk18on, the reference Java OpenPGP)
- Curve25519 / Ed25519
- Bouncy Castle native
- OpenPGP packet layer
- Hand-rolled parser & builder (Kotlin), auditable
- Argon2id (v6 S2K)
- Bouncy Castle, parsing only — not yet validated against RFC 9580 Appendix A test vectors
- Key storage
- Android Keystore, hardware-backed where the device supports it
- RFC 4880
- OpenPGP Message Format (v4 keys)
- RFC 9580
- OpenPGP v6 (import, decrypt, verify; generation in v6.0)
- RFC 6637
- ECC in OpenPGP (Curve25519 / X25519)
- RFC 7253
- AEAD-OCB authenticated encryption
- RFC 9106
- Argon2 password hashing (v6 S2K)
- WKD
- draft-koch-openpgp-webkey-service-15
- GnuPG interop
- Round-trip suite vs
gpg 2.4.xon every release - Ed25519 + Cv25519
- Generate in PGPony → import to GnuPG → re-export → re-import (full cycle, byte-exact)
- v4 ↔ v6
- Sign/verify across both versions verified; v6 messages decrypt cleanly. Encrypt-to-v6 deferred to v5.1.
- AEAD-OCB
- 5-byte AAD, GnuPG-compatible chunk size confirmed
Has it been audited?
No. PGPony has not been through a formal third-party security audit. A proper audit of an OpenPGP client costs in the range of $30,000 to $80,000 and requires a firm with both cryptographic-protocol expertise and mobile-platform expertise. Funding that as a solo developer of a free app is not currently feasible.
In place of a paid audit:
- Standards strict-compliance. PGPony is tested for byte-exact round-trip with
gpg 2.4.xon every release. If the math is wrong, GnuPG rejects the output and the test fails. - Hand-written, auditable packet layer. The OpenPGP parser and builder are kept deliberately small and unobscured so that anyone with OpenPGP experience can read the code and find flaws.
- No custom primitives. Symmetric encryption, AEAD modes, hashing, and elliptic-curve math all come from Apple CryptoKit (iOS) or Bouncy Castle (Android). PGPony does not implement low-level crypto itself.
- Active disclosure policy. Reported vulnerabilities are acknowledged within 72 hours and patched in priority order (see below).
If you are in a position to fund or perform a formal audit, please get in touch.
Reporting a vulnerability.
Coordinated disclosure. We're glad you're looking.
Email the report
Send the report to NorseHorse@norsehor.se with the subject line SECURITY. Plain text is fine. If you have a working proof of concept, include it.
Acknowledgment within 72 hours
You will receive a human acknowledgment within three days. Holidays and weekends may extend this slightly, but it will not be silent.
Triage and patch timeline
Critical issues (key disclosure, ciphertext-revealing flaws, authentication bypass) are patched on an expedited timeline — typically days, not weeks. Lower-severity issues are batched into the next regular release.
Coordinated disclosure window
Please withhold public disclosure for at least 30 days after the initial report, or until a patched build reaches both the App Store and Google Play, whichever comes first. This window is negotiable for active-exploitation cases.
Credit
Reporters are credited in the release notes by name or handle, on request. If you prefer to remain anonymous, that is also fine.
Not a bug bounty. PGPony cannot offer monetary rewards for vulnerability reports while the app remains free and ad-free, per the developer's current legal and operational constraints. This may change in the future. The quality of the work is recognized through public credit and a sincere thank-you.
Where security is going.
- Encrypt to v6 recipients
- Currently PGPony decrypts v6 messages but does not encrypt to v6 keys. Adding encrypt-to-v6 is targeted for v5.1.
- v6 key generation
- PGPony generates v4 keys today; native v6 generation arrives in v6.0 along with full Argon2id RFC 9580 Appendix A test-vector validation.
- Hardware tokens
- YubiKey and NFC-based hardware key support is on the roadmap (planned for v6.0 alongside v6 generation).
- Post-quantum
- Tracking the OpenPGP working group's PQ drafts. PGPony will add support when the standard stabilizes — not before.
- Reproducible builds
- Long-term goal. Both platforms have ongoing reproducibility work upstream that PGPony intends to align with.
- Pass / password-store
- Direct integration with the Unix
passpassword manager is planned for a later release.
See the roadmap for non-security planned work and the changelog for shipped security-relevant changes.