[HN Gopher] Building a serverless secured dead drop
       ___________________________________________________________________
        
       Building a serverless secured dead drop
        
       Author : ayende
       Score  : 62 points
       Date   : 2024-06-04 05:51 UTC (1 days ago)
        
 (HTM) web link (ayende.com)
 (TXT) w3m dump (ayende.com)
        
       | hadlock wrote:
       | 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.
        
         | gsliepen wrote:
         | How about a little microcontroller and SD card entirely
         | encapsulated in a brick, with a coil for power and
         | communication with the outside world?
        
           | pitaj wrote:
           | May as well just use RFID tags, unless you have a lot of
           | data.
        
           | adolph wrote:
           | 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.
           | 
           | 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...
        
             | password4321 wrote:
             | Put that on a solar-powered drone that sleeps on commercial
             | roofs where there is free WiFi, autonomously finding
             | another if discovered.
             | 
             | Drones on power lines:
             | https://www.zmescience.com/science/news-science/drones-
             | recha...
        
         | fhub wrote:
         | The increase in density of security cameras makes physical dead
         | drops less ultimate than they once were.
         | 
         | As a thought exercise I sometimes wonder how far I can go from
         | a specific location without being captured on a camera.
        
           | 01HNNWZ0MV43FF wrote:
           | I don't think I can even leave my neighborhood. I hate it.
        
             | redeux wrote:
             | 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.
        
             | normie3000 wrote:
             | Don't worry, you'll get used to it. And then you'll be
             | scared to live without it.
        
             | 0cf8612b2e1e wrote:
             | 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.
        
           | hughesjj wrote:
           | Parks, woods, thermal camera
           | 
           | Worst case you could try underwater
           | 
           | All significantly harder though
        
         | ayende wrote:
         | Actually, if you want that, go with a rapberry pi with a hidden
         | Ssid
         | 
         | All you need is to e loitering nearby, connect and drop the
         | data then move
         | 
         | But phyaical tracking is very much a threat
        
         | vhcr wrote:
         | Have fun getting hacked with BadUSB.
        
       | JZL003 wrote:
       | 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
        
         | 8organicbits wrote:
         | Wouldn't you need a very low ping for that to work?
        
           | pitaj wrote:
           | As long as it's very consistent, you can use differences
        
             | meejah wrote:
             | Yes, inter-packet timings are unfortunately pretty good at
             | holding information. (e.g.
             | https://www.freehaven.net/anonbib/cache/stepping-stones.pdf
             | )
             | 
             | 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).
        
           | _0ffh wrote:
           | I don't think it needs to be low, but rather consistent, so
           | that the delay between packets is preserved.
        
           | vhcr wrote:
           | You could implement error correction code on top.
        
         | eddd-ddde wrote:
         | Could even go a lower level and use something like the TCP
         | packets metadata as the encoding. Send data in the form of TTL
         | variations across packets.
        
         | ayende wrote:
         | Sounds really interesting, and resources on that?
         | 
         | Sounds like the other size of timing leaks that cryptographers
         | are so worried about
        
         | toast0 wrote:
         | > 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.
        
       | tonetegeatinst wrote:
       | Serverless.... So a physical location
        
       | wwilim wrote:
       | 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
        
         | ayende wrote:
         | You have bots that are ideally not controlled by the system.
         | 
         | 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
        
         | meejah wrote:
         | 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).
        
       | secfirstmd wrote:
       | 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:
       | 
       | https://www.bbc.com/news/world-europe-16614209
        
       ___________________________________________________________________
       (page generated 2024-06-05 23:00 UTC)