Pretty Bad Privacy
This article is in early drafting process, made public so I get comments and more people can be aware- OpenPGP
- Pretty Good Privacy standard, derives from the original PGP implementation. "PGP", "Pretty Good", and "Pretty Good Privacy" are trademarks of PGP Corporation. The term "OpenPGP" refers to the protocol described in this and related documents.
- GnuPG / GPG
- Gnu Privacy Guard, main/only implementation of OpenPGP
OpenPGP standard
Compression
RFC4880, November 2007Furthermore, compression has the added side effect that some types of attacks can be thwarted by the fact that slightly altered, compressed data rarely uncompresses without severe errors. This is hardly rigorous, but it is operationally useful. These attacks can be rigorously prevented by implementing and using Modification Detection
Not sure about this one, I’ll go check but this cause few issues in SSH and TLS, so I wouldn’t be surprised that it was also the case for OpenPGP.
Ciphers
The OpenPGP standard mandates that some ciphers must be present in the implementation, they are broken and well known to be.
RFC4880, November 20079.1. Public-Key Algorithms ID Algorithm -- --------- 1 - RSA (Encrypt or Sign) [HAC] 2 - RSA Encrypt-Only [HAC] 3 - RSA Sign-Only [HAC] 16 - Elgamal (Encrypt-Only) [ELGAMAL] [HAC] 17 - DSA (Digital Signature Algorithm) [FIPS186] [HAC] 18 - Reserved for Elliptic Curve 19 - Reserved for ECDSA 20 - Reserved (formerly Elgamal Encrypt or Sign) 21 - Reserved for Diffie-Hellman (X9.42, as defined for IETF-S/MIME) 100 to 110 - Private/Experimental algorithm Implementations MUST implement DSA for signatures, and Elgamal for encryption. […] 9.2. Symmetric-Key Algorithms ID Algorithm -- --------- 0 - Plaintext or unencrypted data 1 - IDEA [IDEA] 2 - TripleDES (DES-EDE, [SCHNEIER] [HAC] - 168 bit key derived from 192) 3 - CAST5 (128 bit key, as per [RFC2144]) 4 - Blowfish (128 bit key, 16 rounds) [BLOWFISH] 5 - Reserved 6 - Reserved 7 - AES with 128-bit key [AES] 8 - AES with 192-bit key 9 - AES with 256-bit key 10 - Twofish with 256-bit key [TWOFISH] 100 to 110 - Private/Experimental algorithm Implementations MUST implement TripleDES. […] 9.4. Hash Algorithms ID Algorithm Text Name -- --------- --------- 1 - MD5 [HAC] "MD5" 2 - SHA-1 [FIPS180] "SHA1" 3 - RIPE-MD/160 [HAC] "RIPEMD160" 4 - Reserved 5 - Reserved 6 - Reserved 7 - Reserved 8 - SHA256 [FIPS180] "SHA256" 9 - SHA384 [FIPS180] "SHA384" 10 - SHA512 [FIPS180] "SHA512" 11 - SHA224 [FIPS180] "SHA224" 100 to 110 - Private/Experimental algorithm Implementations MUST implement SHA-1. Implementations MAY implement other algorithms. MD5 is deprecated.
Some additionnal ciphers got added later on, but this basically mean that you cannot be sure that a OpenPGP message you sent wasn’t done in more-or-less plaintext. DES was broken by the EFF in 199x, 3DES is basically now on about the same size (NIST: 80 bits of security) but computing power got much better, SHA1 was probably still known as okay but could be better (as SHA2 was already a thing), DSA was probably not now enough as good to be hardcoded, no idea for Elgamal.
I tried few years ago to build a GnuPG without support for theses broken ciphers, and I failed doing so. One can note that SSH requires 3DES-CBC, but it can be disabled or non-implemented (tinyssh).
RFC4880, November 200713.4. Plaintext Algorithm 0, "plaintext", may only be used to denote secret keys that are stored in the clear. Implementations MUST NOT use plaintext in Symmetrically Encrypted Data packets; they must use Literal Data packets to encode unencrypted or literal data.
I guess this one is related to SigSpoof
RFC4880, November 200714. Security Considerations * As with any technology involving cryptography, you should check the current literature to determine if any algorithms used here have been found to be vulnerable to attack. […] * There is a somewhat-related potential security problem in signatures. If an attacker can find a message that hashes to the same hash with a different algorithm, a bogus signature structure can be constructed that evaluates correctly. For example, suppose Alice DSA signs message M using hash algorithm H. Suppose that Mallet finds a message M' that has the same hash value as M with H'. Mallet can then construct a signature block that verifies as Alice's signature of M' with H'. However, this would also constitute a weakness in either H or H' or both. Should this ever occur, a revision will have to be made to this document
$ gpg --version
gpg (GnuPG) 2.2.10
libgcrypt 1.8.3
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <https://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Home: /home/haelwenn/.gnupg
Supported algorithms:
Pubkey: RSA, ELG, DSA, ECDH, ECDSA, EDDSA
Cipher: IDEA, 3DES, CAST5, BLOWFISH, AES, AES192, AES256, TWOFISH,
CAMELLIA128, CAMELLIA192, CAMELLIA256
Hash: SHA1, RIPEMD160, SHA256, SHA384, SHA512, SHA224
Compression: Uncompressed, ZIP, ZLIB, BZIP2
“LOL”
It leaks a pile of metadata (time, implementation name+version, …)
There is no deniability possible, there is quite a difference between no-authentication and deniability, to be elaborated on
Your public key/identity will end up on the keyservers at some point, no exception.
There is no forward secrecy
OpenPGP in real life
Real Name policy and other stuff that should be optionnal in the Public Key Verification process (An ID card? Seriously?).
The keyservers/Web-of-Trust is architecturaly vunerable to a DoS by spam. keyservers.md
Bonus: Keybase is a fuck
Keybase is what you get when you want crypto (just the math), but you do not care about security (they are called secrets for a reason) or privacy (social-media with a cryptographically verified graph that lives forever…).
- It got bought by Zoom, which is known-bad/evil for privacy. (Zoom Video Communications - Wikipedia)
- You are encouraged to upload your private keys to them, with their own algorithm) and it is hard to revoke (Please revoke your key and create another): Uploading private keys puts users at risk, keybase/keybase-issues#160, Can't revoke the proof from web, keybase/keybase-issues#731 (note: even after revocation it could still be verified, revocation being advisory), GPG smartcard security bypassed by delegated private key, keybase/keybase-issues#1946, How to export private key from keybase with API or kbpgp.js?, keybase/keybase-issues#1912
- It is centralised (and so proprietary) and harms decentralisation. For example: pleroma basically can’t have keybase integration because the instances are too small, lol, mastodon instances are way too big.
As an alternative (and if you still want OpenPGP), I think putting your fingerprint everywhere you can and putting you minimal public key on your blog is a much better way, and it can be automatised a bit (OPENPGPKEY DNS record, IndieWeb rel="openpgp"
, …).
See also
- Pretty Bad {Protocol,People}
- NeoPG, a fork of GnuPG, found SigSpoof probably more to come
- NetPGP, an implementation of OpenPGP by NetBSD, seems quite unmaintained to me
- What’s the matter with PGP? - A Few Thoughts on Cryptographic Engineering
- [tor-talk] Why the Web of Trust Sucks
- Sweet32: Birthday attacks on 64-bit block ciphers in TLS and OpenVPN, which Triple-DES and Blowfish are vulnerable to