The one that interests me is inspired by the Blackhat movie.
The premise here is that the donor has an app on their phone. They load their data into the app.
Then they go to a mall, down town shopping district, someplace busy and they walk around.
When they got home they see a green dot showing the data has been transferred.
Somewhere hidden where they were walking is a BT receiver. The app and phone sniffed it out and sent the data as they walked by.
Once the data is loaded onto the drop, it’s exported out via a mesh of LORA radios.
I don’t know how to get BT radios to pair automatically without ever seeing each other, even between cooperating parties. Or maybe it could work with WiFi Direct. Not really familiar with that.
I thought Briar could provide this functionality without any previous pairing using BLE? I don't know too much about BLE but you should be able to just broadcast data without any pairing. Could be encrypted with a pre-shared secret. If the payload is small enough, it shouldn't be that much of a problem.
Also Apple Wireless Direct Link is pretty interesting as well. It can do a lot more than Airdrop.
> Both companies will provide any data they have, including the full contents of any messages, if provided with an appropriate court order.
As we have learned, many companies hosting your data do not even require a court order. An urgent-sounding email with an official-looking return address is all that is needed.
I’m kind of surprised no one has mentioned IPFS [0]. IPFS x I2P [1] or IPFS x Tor [2] gets you like at least 60%-75% there (depending on individual skills).
I think what we are specifically speaking about here is one where it can be done remotely. Intelligence orgs have had secure(ish) digital dead drops for years. Example:
I don’t get it. Can’t you just upload the data to an anonymous GitHub repo or other public service? Have a predetermined prefix for the repo name and you can pull it from the firehouse.
Could you encrypt a file with a public key and expose it via web server that another server scrapes later. Maybe with a common url like example.com/deaddrop. The dead drop server would decrypt the scraped file with the private key. You would have plausible deniability because any other site could have a dead drop endpoint with encrypted files. They would be indistinguishable from any others.
I think the issue with that might be that it would be relatively easy (especially with nation state level powers) to identify who paid for the server and/or domain, making it defeat the purpose.
Also that aside, many whistleblowers are not necessarily technologically inclined people, so this would not necessarily work well due to that too
> I think the issue with that might be that it would be relatively easy (especially with nation state level powers) to identify who paid for the server and/or domain, making it defeat the purpose.
So? Post it on craigslist (or reddit/twitter/mastodon/youtube comment/wherever).
Most of those need logins, but so what - use a fresh account for each dead drop.
My favorite recent one I read was encoding it in the http packet delays. So the content of the server is innocuous but you measure the timings
I wonder how many packet sniffers record exact extremely-accurate timestamps, maybe you could even use synchronized gps clocks so even if the saved a millisecond (or better?) timestamp, you send enough packets with enough exact timings that you need to have saved higher resolution
> I wonder how many packet sniffers record exact extremely-accurate timestamps
Accuracy is hard to judge, but tcpdump/wireshark usually show 6 digits after the decimal. It's gotta be close enough within the bounds of usual jitter on a packet switched network.
But it's so easy to defeat with a device that would random delays to packets, maybe even shuffling their order a bit. It does not need to unpack and process the packet, only record and check boundaries, even simpler than a switch.
Would introduce a configurable amount of delay variance,
Would attach directly to the Ethernet port, before the patch cord going to the rack's router.
Note that Tor doesn't have "global passive adversary" in the threat-model (i.e. an actor that can monitor traffic entering and leaving the Tor overlay).
Can't a malicious entity running this system identify decoy messages by the fact that they are conveniently published at intervals divisible by 5 minutes? ie. 17:07:43 then 18:42:44
I think Pond had better-thought-out decoy traffic https://github.com/agl/pond with a statistical design and clients would always upload and download the same amount of data (so it was very hard to determine if they "got a message" or just checked and didn't get a message).
The ultimate serverless dead drop was a USB thumb drive epoxied into a hole in the wall, with only the port sticking out.
The only criteria the thumb drive in the wall fails is "Accessible via Tor to protect against traffic analysis.", however it doesn't need network access at all so I think it is kind of a moot point.
There is some minor risk of surveillance on the site, but that can be defeated with a fake mustache or whatever. Also physical security risk, the drive might be designed to damage computers that connect to it via a voltage spike.
One of my previous homes was in a neighborhood that put a security camera at the entry roundabout, ostensibly because “teenagers were doing drugs.” It was one of my deciding factors to leave that neighborhood.
Even if you could, there are now satellites and airplanes capturing photos of major cities constantly.
GMan is not yet using that to track dope dealers, but it is not impossible to imagine access to this data being “democratized” to other government agencies.
I think the best way to do a public dead drop would be to use something that is already there and transfer in a way that looks normal. E.g. giving a certain shop in a mall a modified EC card reader and then have your courier "pay" via NFC.
Ideally you'd like your data transfer to be completely invisible even to watching eyes, ears and attenas, so the best option is to use signals (or the absence of signals) one would expect to be there.
Pull in power inductively from power lines to recharge battery. [0] Use ESP chip with rechargable coin cell [1]. Only turn on chip with no ssid broadcast every hour at some odd minute for a short time. [2] Put/get only URI & decrypt key, main body is on Mega or similar.
I'm trying to think of a reason not to just drop a microSD card in the mail addressed to the journo. Are we going to do better than physical media delivery? The only way to be found out would be some sort of surveillance of the mailbox or your fingerprints/DNA, which you could be careful with.
That's how they got the Harvard bomb threat suspect. Even though he was using Tor, he was one of only a few people directly accessing it from the university's network at the time it was sent, and they had logs.
One concern I have is the usage of Libsodium. Libsodium is way too popular to be secure. Many non-technical folks seem to think that just because a library has a lot of eyeballs on it, that it's secure. Unfortunately, these libraries are very complex and low level. It's possible to hide backdoors which look just like regular bugs; e.g. stack overflows can seem like accidental bugs. Also, popular libraries can be attacked at the distribution layer to backdoors may not even show up in the source code on GitHub. I've used Libsodium for Node.js in the past and the installation process was suspiciously heavy because it had to build a ton of C bindings. Red flags.
Libsodium was independently audited by respectable reviewers. OP is spreading FUD for some very weird reason.
Libsodium is also extremely robust. The only crypto project I’ve seen that is as footgunless is google’s tink, and that isn’t available for a JS environment.
What’s great about libsodium is that it’s a single code base that works everywhere. RSA libs I’ve used have subtle differences when it comes to loading keys in different formats and also incompatibilities due to dropping leasing zero bytes for instance. Compared to that, libsodium was a breeze that just worked.
You probably had to compile libsodium and build a shared object. That can take a long time. But the scripts that run when npm installing modules can contain malicious payload, yes.
I always try to find something that runs in web-assembly, but it's better to avoid nodejs altogether if you want high security.
Go is much better for these kind of things overall.
The premise here is that the donor has an app on their phone. They load their data into the app.
Then they go to a mall, down town shopping district, someplace busy and they walk around.
When they got home they see a green dot showing the data has been transferred.
Somewhere hidden where they were walking is a BT receiver. The app and phone sniffed it out and sent the data as they walked by.
Once the data is loaded onto the drop, it’s exported out via a mesh of LORA radios.
I don’t know how to get BT radios to pair automatically without ever seeing each other, even between cooperating parties. Or maybe it could work with WiFi Direct. Not really familiar with that.