Sending short (?) messages but not initially on cell service.

[Zenaan Harkness]

On Sun, Dec 08, 2019 at 09:43:03AM +0000, jim bell wrote:
> A few days ago, there was a news item about a bank robber who was caught because he (stupidly) took his cell phone to the robbery.  He was exposed by the technique called "geo-fencing".  https://www.nbcnews.com/news/us-news/police-used-google-location-data-find-accused-bank-robber-he-n1086836    The legitimacy of the use of this technique is currently a subject of his appeal, but is not relevant to my comment, below.  
> Maybe if he had been smart enough to know how to activate his
> phone's "airplane mode", which supposedly turns off all electronic
> transmissions, he wouldn't have quite as identifiable.  But, as
> cypherpunks know, it isn't clear that a smartphone's promise that
> it won't transmit and thus reveal its location can be relied upon. 
> Further, even if we can know, for sure, that a phone didn't
> TRANSMIT during that relevant period, that doesn't mean that it
> didn't record its path in space (by GPS) and time during such a
> period, later to be uploaded to Google servers.


We know that does happen.



>  Perhaps wrapping
> that phone in a few layers of aluminum foil would have blocked the
> (already quite weak) GPS signals, so the phone wouldn't know where
> it was.  
> However, it occurred to that there may one day be a need for a person to enter a geographic area that has cellular phone service, but not have his smartphone emit signals that would (immediately) identify that phone's presence there.  Okay, "airplane mode".  But, he could also want his presence to be unknown including later, by disabling Google location services.  MAYBE that would 'work'.  He might want to visit like this multiple times, leaving that area each time, not leaving an electronic trace.  Yet, maybe he'd want to use that smartphone's camera (to record video and still frame) and audio (to record sound).  
> Even more, maybe an event would occur, and he would have evidence of it in video and audio, and he might (later) want to document the fact by uploading video and audio evidence to a server somewhere, at that time or seconds later.  But he might not want to record the video, still frames, or audio 'in the clear'.  And, there would be no reason that he'd have to upload the entire (huge) video and audio files:   He could subject the resulting data to a 'cryptographic hash', https://en.wikipedia.org/wiki/Cryptographic_hash_function   so that he could upload only 256 bits.  That hash could itself be encrypted, and could actually be a hash of a table of hashes:  A hash for each one second of video and/or audio, or even a smaller quantity of time, just for an example.   Initially, he could upload just the overall hash.  And if, later on, he wanted to prove that he had acquired some data at a specific time, or at least prior to some specific time (when it was uploaded), he could do so by releasing files which correspond to the segments of video and/or audio files, and show that their hashes match the hashes in the uploaded hash-files.   
> How could he transmit that short hash back to his home base, or anywhere else?   How about https://www.popularmechanics.com/promotions/a20777855/the-mesh/?src=syn&dom=yah&mag=pop
> His release of that hash would allow him to later prove, once the source files are released, that he had generated them, at or before a specific time (If you believe the system to which the transmission was initially sent, or your own computer if it's sent along quickly enough), and the video and audio would provide evidence of the event he chooses to claim.  But he might not release the open, unhashed and unencrypted information, immediately:  His claim might be challenged, and he could hold that in reserve as evidence he was correct.  
>               Jim Bell
> 
> 
> 
> https://www.popularmechanics.com/promotions/a20777855/the-mesh/?src=syn&dom=yah&mag=pop
> 
> Or:   https://gotenna.com/pages/sdk   Full technical specs:https://gotennapro.com/pages/spec-sheets#pro-pro-x-spec-sheet
>  True, it would be better if this was an SDR, or "software defined radio".  
> I just found this a couple of days ago.