On March 10th, several days after Incognito Market was assumed to be shut down or no longer be processing transactions, the site posted a message to its homepage that reads as follows:
”Expecting to hear the last of us yet? We got one final little nasty suprise for y'all. We have accumulated a list of private messages, transaction info and order details over the years. You'll be surprised at the number of people that relied on our "auto-encrypt" functionality. And by the way, your messages and transaction IDs were never actually deleted after the "expiry"...”
”SURPRISE SURPRISE !!! Anyway, if anything were to leak to law enforcement, I guess nobody never slipped up. We'll be publishing the entire dump of 557k orders and 862k crypto transaction IDs at the end of May, whether or not you and your customers' info is on that list is totally up to you. And yes... YES, THIS IS AN EXTORTION !!! As for the buyers, we'll be opening up a whitelist portal for them to remove their records as well in a few weeks.”
”Thank you all for doing business with Incognito Market”
Exit scams are not uncommon on dark web markets, but this one is particularly large and openly threatening compared to most. Incognito Market requires the loading of cryptocurrency to a site-based wallet, which can then be used for in-house transactions only. All cryptocurrency on the site was seized from user’s wallets, estimated to be anywhere from $10 million to $75 million. After seizing the cryptocurrency wallets of all of the marketplace’s users, the site now openly explains that it will publish transactions and chat logs of users who refuse to pay an extortion fee. The fee ranges from $100 to $20,000, a volume based 5 tier buyer/seller classification.
Incognito Market also now has a Payment Status tab, which states ”you can see which vendors care about their customers below.” and lists the some of the market’s largest sellers. Sellers which have allegedly paid the extortion fee to not have their transaction records released are displayed in green, while those who have not yet paid are displayed in red.
Additionally, in a few weeks the site claims it will have a “whitelist portal” which would allow buyers to wipe their transactions and re-encrypt chat records.
Whoever is behind the website must be extremely, extremely confident in their anonymity, already working with government agencies, or both, because a bounty on this person is likely worth millions.
If you're playing it by-the-book, that is the standard operation procedure. You don't want to give any data to or have any other connection with a vendor who doesn't 100% require PGP.
What I meant is: I don't know if there was a way for vendors to identify whether a specific buyer was using their own PGP key or the auto-encryption feature. Both might have looked the same from the vendor's side of things. If so, they wouldn't have been able to selectively deny auto-encryption users.
I edited this comment for clarity and because I accidentally said something backwards initially:
Hmm, it should be plainly obvious if someone is encrypting their messages to you. Like, what I think you're describing couldn't even work by accident. Other people's keys can't be used. If someone wants to communicate with you, they need your public key to encrypt their message to you and only you can then decrypt that message with your private key. If you then want to respond, you need their public key to encrypt your response, which only they can decrypt.
Example: if a buyer contacts a vendor, the buyer is not using their (the buyer's) own key. The buyer must use the vendor's public key to encrypt a message that the vendor then decrypts locally (which only the vendor can do with their private key). If the buyer used any other key, the vendor couldn't decrypt the message and no transaction could proceed. If the vendor wants to then send a message to the buyer, that's when the vendor uses the buyer's public key to encrypt that message. If the buyer gave the vendor any public key that is not their own, that buyer then couldn't decrypt the message the vendor sent them. There's really no place in this process where the vendor wouldn't know if the buyer was using their own PGP key.
In my past experience, people would put their public keys in their profile. The auto-encryption doesn't even look like encryption, it just looks like sending messages normally, the same way it looks using any encrypted messenger service: you just accept and trust that the service really is encrypting and decrypting at both ends and all you see is the text that someone sends you. There are steps both you and the person you're talking to have to take when doing your own encryption. Even when you're using PGP, you're still sending text over the market messaging system, and the market is encrypting that, but the text you're sending will look like total gibberish to everyone. Not just to the market, but it will look like total gibberish even to you after you encrypted the text locally on your own device, and of course it will also look like total gibberish to the person you're sending it to until they decrypt it locally on their end. There really should be no room for confusing who's public key is being used, not even mistakenly because the decryption wouldn't work. Unless I'm still misunderstanding you, or unless communication methods on the DNMs have so drastically changed in recent years that they're incomparable, but I know that's not the case.
Yes, I think we might be missing each other a little bit again, perhaps due to different ideas about how the auto-encryption is operating.
The correct public and private keys will always be used if the communication is going to work. Auto-PGP would still be using public and private keys for the buyer and the vendor.
The way I understand it, auto-encryption is a one-sided mechanic: It's something that the buyer ticks on/off.
If so then it is designed to interface fine with people using manual PGP, such as vendors.
If such a system generates the proper keys for the buyer and handles encryption/decryption automatically so that everything always appears to them as plaintext on the frontend (because the system maintains their keys), then it would still be able to serve the vendor a traditional UX that requires manually handling the keys. In this case, the experience of the vendor would be identical regardless of whether the buyer is using auto-encryption or not.
This would only expose one side of the conversation to the server admins, of course: The messages sent from the vendor to the buyer (because the system only has the buyer's private key).
I do not know if this is the way it was actually implemented. However there is discussion on Dread right now that leads me to believe that auto-encryption works somewhat similarly to what I have just described (at least from the vendor's perspective).
edit: Looking back, I might have introduced some confusion with this line:
It would have been more clear for me to say: