Generating OTP using Digital Dead Drop
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.