Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Upcoming SlideShare
What to Upload to SlideShare
Next
Download to read offline and view in fullscreen.

Share

Berlinsides2017

Download to read offline

introducing pgpfs

Related Books

Free with a 30 day trial from Scribd

See all

Related Audiobooks

Free with a 30 day trial from Scribd

See all
  • Be the first to like this

Berlinsides2017

  1. 1. In which encounters Mephistopheles https://images.fineartamerica.com/images-medium-large-5/faust-matt-hughes.jpg berlinsides 0x7E1 aestetix
  2. 2. Thesis • I really like the PGP/GPG protocol.
  3. 3. Thesis • I really like the PGP/GPG protocol. • However, I want the public keyservers to die.
  4. 4. Short primer on PGP/GPG • Symmetric vs asymmetric cryptography Alice Bob
  5. 5. Short primer on PGP/GPG • Symmetric vs asymmetric cryptography Alice Bob Tommy Trickster
  6. 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. 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. 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. 9. First Attempt: data mining • Berlinsides 2015 talk
  10. 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. 11. Third Attempt: client-side "security" • Removed "email address" validation
  12. 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. 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. 14. Third Attempt: client-side "security" • Creating and uploading ridiculously large keys • code for this at https://pinky.ratman.org/~aestetix/
  15. 15. The "Key" Question: How can we upload large bloated files to the keyserver while using all standard tools?
  16. 16. The "Key" Question http://images.slideplayer.com/17/5341490/slides/slide_22.jpg
  17. 17. The "Key" Question
  18. 18. The "Key" Question
  19. 19. Introducing PGP File System (pgpfs) • Demo
  20. 20. pgpfs- the bad and the good • The bad: • Very slow
  21. 21. pgpfs- the bad and the good • The bad: • Very slow • "Security" through obscurity
  22. 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. 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. 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. 25. pgpfs- the bad and the good • The good: • keys are never deleted, only revoked • The keyservers become a RAID 1 (cloned) ➡ ➡
  26. 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. 27. Questions? https://github.com/aestetix/pgpfs aestetix@aestetix.com gpg key ids: 0x248DBA53* 0xDEADBEEF 0x12345678 * preferred

introducing pgpfs

Views

Total views

273

On Slideshare

0

From embeds

0

Number of embeds

10

Actions

Downloads

1

Shares

0

Comments

0

Likes

0

×