How LE might read our PGP messages, and how we can prevent it - especially important if you're worried about honeypot markets

TL;DR: Everyone learn about the importance of Key Trust. LE can replace a "vendor's" Public Key with one that they control, read your messages, then re-encrypt them to the "real" key and send them along, with nobody ever knowing. This is especially feasible if a market site is a honeypot and people are getting public keys from the market instead of from keyservers. Vendors: please start including in your shipments a written copy of your GPG key's Fingerprint and a totally unique (never before used) "password," and encourage buyers to verify their copy of your key against the shipped Fingerprint and then send you a signed, encrypted message containing the "password". Then both buyer and vendor can Sign each other's keys and upload those Key Signatures to keyservers, and we can begin to know that the public keys being tossed around are legitimate. How about discounts offered to buyers who verify their own keys, and wide publicity in glowing reviews for vendors that do this, to get the ball rolling?


So.

People are talking about honeypots a lot, and how they don't care, because "all their messages use PGP anyway."

This is a serious problem.

An LE honeypot market can serve forged OpenPGP public keys instead of authentic ones, and then the feds can read everything, no problem. They can also swap out the buyer's public key with one that they also control, so that they can read both directions of communication. LE could also potentially swap out public keys transmitted in other ways, too (including from keyservers and the like).

This is the single most simple and easy way that OpenPGP (and many other cryptosystems) can be defeated, and it's been known for a long, long time. This is the classic "Man in the Middle" attack, and it's a very big deal, and in some cases, hard to prevent. But not for us, if we take some simple measures.

Thankfully, OpenPGP systems have a really awesome and really effective way to deal with this: the Web of Trust - as long as people use it.

Problem: Most people using DNMs don't know about the Web of Trust or the importance of this stuff, and they aren't using it.

But there's an easy way to build a really strong Web of Trust for DNMs, which could work even better than some of the ways it's done on the clearnet and in meatspace. That's because vendors are really good "hubs" for trust, as they communicate with many people, and since folks are using mailed packages, we have a really good "out-of-band" communications channel to transmit and verify OpenPGP Key Fingerprints that are really difficult for LE to tamper with.

Solution: Vendors write out their OpenPGP Key Fingerprint and a totally unique (never re-used) "password" on some paper that's in their shipments (they can use a second-hand printer or write in simple block characters with gloves on), and encourage buyers to:

After a buyer validates their own key to the vendor (by supplying the secret "password" that only existed in their package), the vendor can then sign the buyer's Key as Trusted and either upload it to a keyserver or send it to the buyer so they can upload it.

If enough people start doing this, it becomes easy for a prospective buyer to check a supposed "vendor's" public key that they found online against the Web of Trust, to see if it really belongs to the vendor, and isn't a substituted one from LE.

If at any point a vendor's published public key doesn't match up with the fingerprint they ship out, that's a serious and very easily-spotted RED FLAG that LE is attempting to read their communications. If this happens, it should be reported and repeated widely and loudly.

Alternate version: forget the "passwords" in shipments, and vendors just ship their Key Fingerprint. This still allows the buyers to verify, Sign and publicize the vendor's public key, and it's vendor keys that are most important. But including the "password" and Signing buyer keys is what makes an actual Web of Trust possible, so doing it both ways is definitely preferable.

If anyone's got further questions about any of this stuff or the nitty-gritty How To Do It shit, please don't hesitate to ask, I love helping people step up their security game. If you wanna talk securely, my GPG key with fingerprint 69E7 EB65 1CB6 19DE 9153 3A2B D16B 4CC5 857D 0298 is available at https://ssl.reddit.com/r/publickeyexchange/comments/2cmfob/sapiophiles_public_key/ , https://keybase.io/sapiophile , and on the SKS Keyserver network.

Potential problems:

See also:

http://directory4iisquf.onion/ - not my site, but it seems to have similar goals. I found it while searching for a .onion keyserver.

Tips appreciated, but definitely not required - my BTC address can be found on https://keybase.io/sapiophile


EDIT: some very quick alternative ideas, addressing concerns about profiling, etc.:

  1. Vendor only sends a single "password", vendor and buyer can then establish key trust using the Socialist Millionaire's Protocol or similar. I don't know how feasible SMP is in an asynchronous channel (e.g., back-and-forth messages on a market site), but it can probably be done, though it might be a PITA. I don't think there are tools for doing this easily, yet. At the very least it would require at least a couple messages back and forth, and I don't think anyone would do it. I may do some research on this and perhaps even try to organize a development effort to make SMP a reasonable option over market messages...

  2. Folks start checking for public keys in multiple locations (preferably at least 3 - on different markets, on grams, etc.), then upload Casual Trust Signatures (sig1) for those keys to keyservers. Definitely less secure, but still better than nothing.


Comments


[9 Points] m4uer:

I just wanted to say that people like you are so damn important to this community. Thank you


[9 Points] None:

[deleted]


[6 Points] fun-gee:

I think it would be more viable solution if vendors would check their own pubkey from time to time, using an other account.


[4 Points] RedBullHasWings:

I must be missing something, but I don't really understand what additional security this provides? Yes, it ensures the package came from the vendor and not LE, but what else? Really, how often to LE intercept packages and send their own instead? And would they be dumb enough to change any crypted signatures on a package?

It sounds as though you're trying to prevent public key injection into online dbs by adding crypted signatures to physical parcels. There's a disconnect there. How does that help?

By no means am I trashing the idea, and throwing ideas around is excellent, as additional solutions are always welcomed. I'm just curious as to what this actually achieves? Again, I must be missing something.


[3 Points] og_by_monsanto:

This is cyberwar

You gotta fight, for your right, to party!


[3 Points] 13tom13:

yeah always a good idea to see if the key has changed recently or is different on a certain site...


[3 Points] feignrmk:

You're spot on with this I think. Not that I see it as very likely to occur... people have a hard enough time just getting the concept of public key encryption, much less learning the practical steps to use it. Getting them to take extra steps to prevent a MitM attack, which they potentially don't even fully grok in the first place, is going to be somewhat difficult. It would be cool to see some incentives for vendors and buyers to take those extra steps, and then vendors could be ranked on how strongly associated with the WoT they were...


[3 Points] blackvictor:

After reading your post I was compelled to setup an additional public key server in onionland as we need more distributed services to support the good of the ecosystem. I dig what El Presidente is doing but wanted something not tied directly to vending.

http://torkeyuhgrgsjkkw.onion is running Hockeypuck and will let you upload and view keys. The web interface is available or standard hkp for use with gpg directly if your box is transproxy'd or with a tool like proxychains

On Tails, Linux or even a Mac this should do the trick:

Search for a key

proxychains gpg --keyserver torkeyuhgrgsjkkw.onion --search-keys sapiophile

Upload your public key

gpg --list-keys # find your key id should look like pub   4096R/857D0298

proxychains gpg --keyserver torkeyuhgrgsjkkw.onion --send-key 857D0298


[2 Points] adamfowl:

This is an amazing idea


[2 Points] Explore411:

Is it me or is this whole process you're talking about to protect customers ? Well this is admirable, it's fairly pointless as operations such as the one that just went down was to catch the market owners and vendors. Trying to get focus on vendors and making their packages contain "verifiable" information is just "exhibit b" waiting to happen. What we really need are servers set up in countries that make it so difficult and cost-prohibitive that it slows LE down considerably. Colombian drug lords are successful because their home operation is protected, not because the coke has verifiable passwords and serial numbers. Now, will a market ever admit to being hosted in Cuba, or Russia, and if they did could we verify it ? That's something to be solved in the future.


[2 Points] None:

[deleted]


[2 Points] ThinkFlat:

I absolutely do not understand where this would make any sense. I know a lot about security and for me this looks pointless.

First, a lot of people do not use pgp at all. That doesn't mean that it is impossible or useless to enhance opsec, but it clearly shows that if a technology is too complicated it is very likely not used. What you are doing is adding a layer to an already complicated system, so I think it will only work with a few percent.

Second, the password is useless. If Bob receives a box from Alice and the printed fingerprint doesn't match the known DNM-signature, Bob knows that there is a man in the middle. Why he needs a password now?

Third, if LE secretly seize a server and replace the key, they are aware of the recipient. So it will be very easy to track down the shipment and replace fingerprint, password and so on.

Imagine this: Everyone who uses DNM use an encrypted life system like tails. Everyone use pgp, and every vendor check his key on the market sites every day. Yeah, it would be easy like this. But it doesn't work. Do you really think that adding a further security layer would help?


[2 Points] ScorchedTerran:

I apologize if this is a dumb question: I only have a laptop- it uses windows. When on Tor, I always have the No Script on. When you say Windows, osx Ha, is there something else I could do? I also have PGP 10 and am still re-familiarizing myself with it.

ALso, thanks for this post, very helpful and instructional.


[1 Points] SgtFaecesProcessor:

Haven't read whole post yet but problem with one of your ideas is if you include PGP fingerprint with package then it can help LE profile packages.


[1 Points] cyclopedia:

What about using a .jpg to verify a PGP?


[1 Points] madcuntmcgee:

i feel like the average person can't be fucked with this. too much effort.


[1 Points] funkskipneedlebank:

It sounds like you have to be at least a decent code writer if not a full on hacker to be good at this shit. Looks like business will be cut to a 1/20th since most people just want to tumble encrypt then buy drugs.


[0 Points] Digatmebro:

The real problem is any LE will use anonimity to his advantage and once the trust is built with vendors\admins shit goes down again. Why can't we use one owner/admin to verify members real identity before being granted access to membership and vendorship without sharing it amongst other admins. Therefore if it gets seized we know who the culprit is.


[-3 Points] achahaloociiic:

You wrote all that and you dont even know how pgp works lol, LE cant "replace" a vendors key if you already have msgd vendor before, real one would be in your keyring. If you hadnt then why would they have to re-encrypt to the "real" address, you wouldnt know that it wasnt le key to begin with.