This document discusses abusing public keyservers by uploading large, bloated keys and files using PGP. It introduces PGP File System (PGPFS), a proof-of-concept that stores files encrypted in PGP keys and uploads them to keyservers. While slow and relying on obscurity, PGPFS ensures keys are never truly deleted and replicates data across keyservers. The document argues this is an amusing way to abuse keyservers since they cannot delete keys. It provides code and invites questions.

1. In which
encounters
Mephistopheles
https://images.fineartamerica.com/images-medium-large-5/faust-matt-hughes.jpg
berlinsides 0x7E1
aestetix

2. Thesis
• I really like the PGP/GPG protocol.

3. Thesis
• I really like the PGP/GPG protocol.
• However, I want the public keyservers to die.

4. Short primer on PGP/GPG
• Symmetric vs asymmetric cryptography
Alice Bob

5. Short primer on PGP/GPG
• Symmetric vs asymmetric cryptography
Alice Bob
Tommy Trickster

6. Short primer on PGP/GPG
• Symmetric vs asymmetric cryptography
Alice Bob
Tommy Trickster
Before 1991:
Steps to defeat Tommy Trickster:
1. Alice and Bob meet secretly and
agree on a key
2. They use this key to both encrypt
and decrypt their messages
3. If Tommy Trickster learns the key,
they are fucked
Symmetric: uses a single key to encrypt
and decrypt

7. Short primer on PGP/GPG
• Symmetric vs asymmetric cryptography
Alice Bob
Tommy Trickster
1991-Present:
Steps to defeat Tommy Trickster:
1. Bob publishes his public key
2. Alice finds his public key and uses it
to encrypt her message
3. Bob receives Alice's message and
uses his private key to decrypt it.
4. Tommy Trickster must get Bob's
private key to read the message
Asymmetric: uses one key to encrypt,
and another key to decrypt

8. Short primer on PGP/GPG
• Symmetric vs asymmetric cryptography
Alice Bob
Tommy Trickster
Keyserver
Two new questions:
1. Where can Bob publish his key so
Alice can find it?
2. How can Alice be sure that key is
actually his?
Answer: a keyserver full of signed keys

9. First Attempt: data mining
• Berlinsides 2015 talk

10. Second Attempt: key signing
• Berlinsides 2016 talk
Output:
aestetix@aestetix $ python pglulz.py
Created key 56F9958B for Ed Snowden esnowden@nsa.gov
now to prepare keys to be signed
This is where we upload our new key to the keyserver
Found 31 keys for Buckaroo Banzai Badguys
Fetching keys from Buckaroo Banzai Badguys
Signing key 1 of 31
{ ... lots of keys ... }
Signing key 31 of 31
Found 1 keys for John Small Berries
Input (yaml):
---
hard_reset: True
keyserver: pgp.mit.edu
real_run: False
keys_directory: key_directory
signing_key:
name: 'Ed Snowden'
email: 'esnowden@nsa.gov'
groups_to_sign:
1:
name: 'Buckaroo Banzai Badguys'
matching: 'buckaroobanzai.com'

11. Third Attempt: client-side "security"
• Removed "email address" validation

12. Third Attempt: client-side "security"
• Creating and uploading ridiculously large keys
• code for this at https://pinky.ratman.org/~aestetix/
aestetix@pinky ~/public_html $ ls -lah please_sir.gpg
-rw-r--r-- 1 aestetix users 1.9M Jun 17 2016 please_sir.gpg
aestetix@pinky ~/public_html $ ./gpg2 --list-packet please_sir.gpg
:public key packet:
version 4, algo 17, created 1466190081, expires 0
pkey[0]: [2048 bits]
pkey[1]: [256 bits]
pkey[2]: [2048 bits]
pkey[3]: [2048 bits]
keyid: F591661738FFED2F
:user ID packet: "{ 1.9 megs of crap }"
:signature packet: algo 17, keyid F591661738FFED2F
version 4, created 1466190081, md5len 0, 2 1)
hashed subpkt 21 len 5 (pref-hash-algos: 8 2 9 10 11)
hashed subpkt 22 len 2 (pref-zip-algos: 2 1)
hashed subpkt 30 len 1 (features: 01)
hashed subpkt 23 len 1 (key server preferences:

13. Third Attempt: client-side "security"
• Creating and uploading ridiculously large keys
• code for this at https://pinky.ratman.org/~aestetix/
aestetix@pinky ~/public_html $ ls -lah please_sir.gpg
-rw-r--r-- 1 aestetix users 1.9M Jun 17 2016 please_sir.gpg
aestetix@pinky ~/public_html $ gpg --list-packet
please_sir.gpg
gpg: packet(13) too large
# off=0 ctb=99 tag=6 hlen=3 plen=814
:public key packet:
version 4, algo 17, created 1466190081, expires 0
pkey[0]: [2048 bits]
pkey[1]: [256 bits]
pkey[2]: [2048 bits]
pkey[3]: [2048 bits]
keyid: F591661738FFED2F
# off=817 ctb=b6 tag=13 hlen=5 plen=1398149
:user ID packet: [too large]
aestetix@pinky ~/public_html $ gpg --keyserver pgp.mit.edu --
search-keys F591661738FFED2F
gpg: data source: http://pgp.mit.edu:11371
(1)
DZl60ir7WOuOTHODbIMVaLzlDNQGKtaaLXFuIRMPhQemnKKp0AKd
vdYQrP83POYbnqqz/2
2048 bit DSA key F591661738FFED2F, created: 2016-
06-17
Keys 1-1 of 1 for "F591661738FFED2F". Enter number(s), N)ext,
or Q)uit > 1
gpg: packet(13) too large
gpg: read_block: read error: Invalid packet
gpg: Total number processed: 0

14. Third Attempt: client-side "security"
• Creating and uploading ridiculously large keys
• code for this at https://pinky.ratman.org/~aestetix/

15. The "Key" Question:
How can we upload large bloated files to the
keyserver while using all standard tools?

16. The "Key" Question
http://images.slideplayer.com/17/5341490/slides/slide_22.jpg

17. The "Key" Question

18. The "Key" Question

19. Introducing PGP File System (pgpfs)
• Demo

20. pgpfs- the bad and the good
• The bad:
• Very slow

21. pgpfs- the bad and the good
• The bad:
• Very slow
• "Security" through obscurity

22. pgpfs- the bad and the good
• The bad:
• Very slow
• "Security" through obscurity
• You do not control where your data is (like the cloud)

23. pgpfs- the bad and the good
• The bad:
• Very slow
• "Security" through obscurity
• You do not control where your data is (like the cloud)
• You must not lose your .kat file

24. pgpfs- the bad and the good
• The good:
• keys are never deleted, only revoked
• From pgp.mit.edu/faq.html:
"Can you delete my key from the key server?
No, we cannot remove your key from the key server. When you submit a key to our key
server the key is also forwarded to other key servers around the world, and they in
turn forward the key to still other servers. Deleting the key from our server would not
cause it to be deleted from any of the other servers in the world and so this is not an
effective way to ensure the discontinued use of your key."

25. pgpfs- the bad and the good
• The good:
• keys are never deleted, only revoked
• The keyservers become a RAID 1 (cloned)
➡
➡

26. pgpfs- the bad and the good
• The good:
• keys are never deleted, only revoked
• The keyservers become a RAID 1 (cloned)
• It is a fun and hilarious way to abuse the public keyservers

27. Questions?
https://github.com/aestetix/pgpfs
aestetix@aestetix.com
gpg key ids:
0x248DBA53*
0xDEADBEEF
0x12345678
* preferred