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.
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.
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.
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.
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
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).
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.
> 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.
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).
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:
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.
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.
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.
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.
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 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.
57 comments
[ 4.8 ms ] story [ 116 ms ] threadThe 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.
Might also make for a neat Geocache.
0. https://hackaday.com/2024/01/27/harvesting-electricity-from-...
1. https://www.instructables.com/Remote-Control-ESP8266-With-Co...
2. https://arduino-esp8266.readthedocs.io/en/latest/esp8266wifi...
Drones on power lines: https://www.zmescience.com/science/news-science/drones-recha...
As a thought exercise I sometimes wonder how far I can go from a specific location without being captured on a camera.
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.
Worst case you could try underwater
All significantly harder though
Worst case, if you cant beat em join em
Balls, figs, and sour dough
All you need is to e loitering nearby, connect and drop the data then move
But phyaical tracking is very much a threat
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.
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.
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
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).
Even better: put it in the ICMP echo request; then you can also spoof the sending address if you wish.
Or encode it in a DNS request/response.
Sounds like the other size of timing leaks that cryptographers are so worried about
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.
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.
Like how low-code involves large amounts of code, serverless is a perfect term for keeping people from knowing what's going on.
But remember that we rely on the lambda scheduler to run it
That does boy have perfect accuracy, so that helps too
Finally, you aren't publishing every 5 minutes, you execute it once a minute, and have 25% chance to publish, so it's going to be mixed
https://www.bbc.com/news/world-europe-16614209
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.
It also has a lot of eyes on it and was reviewed by people whose job is to spot these sort of issues
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.
What an absolutely stupid hot take.
I'm not quite sure OPs approach is the best tho, serverless is just somebody else's server.
Better to use something like Onionshare and run it on a device on-premise then transfer the files to an air gapped device for decryption.
Also that aside, many whistleblowers are not necessarily technologically inclined people, so this would not necessarily work well due to that too
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.
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.
[0] https://news.ycombinator.com/item?id=40589515
Also Apple Wireless Direct Link is pretty interesting as well. It can do a lot more than Airdrop.
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.
https://news.ycombinator.com/item?id=30842757
[0]: https://ipfs.tech
[1]: https://geti2p.net
[2]: https://www.torproject.org