Generating OTP using Digital Dead Drop I've had a thought and I'm wondering if this would be a useful way to devise and distribute a one-time pad. It relies on a digital dead drop and a hash function.

The digital dead drop could take a variety of forms. 


For wide distribution it might be a Twitter, Facebook, or Instagram feed, a cloud storage container (Dropbox, Pastebin, etc.) or similar method.
For local distribution it could be a wireless server set up in a public area using Raspberry Pi, Beaglebone, or similar hardware. It could even be a physical dead drop using thumb drives. Such repositories could be password protected if desired.


The "payload" for the dead drop would be delivered and retrieved using VPN access from a public computer, and could be any set of 5 files. These could be anything: photos from the NOAA weather satellite, text files from Shakespeare, videos pulled at random off Youtube, whatever. Each group of 5 files would be in a labeled folder and numbered 1 to 5.

To generate the key, an user would run SHA-3-512 on each file, generating five hashed outputs. Each user would have a unique ID number, such as 12345, 24315, etc., and would arrange the five keys in that order to generate his or her unique one-time pad key, with a total length of 2560 bits.

The ciphertext would contain some indicator of the user's ID and the label from the repository folder, to allow the recipient to generate the proper key.

I've identified some security problems with this method already. The most obvious is the nature of the input files. The input relies on security through obscurity, with the input files "hidden in plain sight" either as innocuous Twitter posts or files on an obscure server available only within a small public area. But granting that this is a significant problem of operational security, is this method otherwise usable?

EDIT TO ADD: Based on some of the feedback (thanks to all who have written), I've thought of a variation that could resolve some of the problems with the dead drop while maintaining the basic principle of obscurity and utility. It's a variation on a book code.

Each user is issued a digital book, in PDF format, Word format, or text (text explicitly divided into pages). Each user has a unique book, but they can be any sort of innocuous writing: A complete Shakespeare, a Handbook of Chemistry and Physics, a complete edition of the Talmud -- any long book will work. 

User generates the OTP key by copying single pages of the book into individual files, and hashing those files.
As for your idea to use a hash to create your OTP, please read Hash functions to generate one time pad to avoid the obvious OTP pitfall of getting its definition wrong. 


  …
  
  As a reminder: a one-time pad…
  
  
  has to be truly random, 
  must be at least as long as the plaintext, 
  is never reused in whole or in part, and
  is kept completely secret.
  
  
  Only when all four points are met, we´re talking about OTP.
  …


Now, that linked Q&amp;A asks if hashing PRNG output would be good enough to create an OTP stream… but your fixed-files idea is not much different in the end (just less volatile in relation to the data you're hashing, making the file-based solution worse).


You're failing the OTP definition in point 1 because files are not truly random. A hash won't magically make it truly random.
You're failing the OTP definition in point 3 because reuse of even a tiny portion of an OTP is a big problem (key reuse issues which lead to partly recoverable data/plaintext).
You're failing the OTP definition in point 4 because it is not kept completely secret. Obscuring the files used as hash source isn't secret by any means. Which brings us to your “…Fortunately it is possible to make them very obscure.” – This is irrelevant and a flawed assumption in a “governmental adversary” scenario as you describe it. The most obvious scenario (among many) which will be a neck-breaker is simple surveillance. For that reason, “security by obscurity” is not really considdered a safe solution in cryptographic realms. This is one of the reasons RSA &amp; Co. have been developed.


Last but not least: you're also missing authentication which is another security problem related to your idea. Related to that, check Q&amp;As like “Why should I use Authenticated Encryption instead of just encryption?” and maybe the related Wikipedia article about “Authenticated Encryption”.

Wrapping it up

My advise would be to rather rely on well-vetted cryptographic solutions which are publically available: an encryption algo (for example, something like ChaCha20), a MAC (to enable authentication), a KDF (to allow users to create according keys based on one or more common secrets), and potentially something like RSA to allow users to agree on a common secret via public-key encryption.

If you – as your comment describes – want to avoid using dedicated encryption algos and regard hashes to be “less obvious” (which I personally don't agree to), you should know that you can build a steam cipher from a hash (see “Building a stream-cipher out of a hash function?”, you can use a hash to create a MAC (see HMAC), and you can even create a KDF with a hash (see HKDF). If you do this, be sure to rely on a secure hash. MD5 nd SHA-1 are considered broken and should therefore be avoided for these purposes. Yet, SHA-2 and SHA-3 are also available and secure.

And if you really insist on using a “Digital Dead Drop”, you could use that instead of public-key encryption to agree on a common secret. Yet, I would advise against it as “security by obscurity” is generally a bad idea… especially when facing a governmental adversary. 

This should be somewhat what you're looking for and cover all issues your scenario descibes.