Generating OTP using Digital Dead Drop

Question

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.

Answer 1

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…

1. has to be truly random,
2. must be at least as long as the plaintext,
3. is never reused in whole or in part, and
4. is kept completely secret.

Only when all four points are met, we´re talking about OTP. …

Now, that linked Q&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 & 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&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.

Answer 2

There is a much simpler way to share a one-time pad that works in practice.

First, share a short secret, say 256 bits, that an adversary can't guess—the adversary's state of knowledge should have at least 256 bits of entropy. You can do this, for example, by sharing authenticated public keys and performing an X25519 key agreement, or, for a dead drop, by encapsulating a key with your favorite key encapsulation mechanism, such as Shoup's RSA-KEM.

Next, use a long-output pseudorandom function family to expand the short secret into a long secret. For example, you could use $\operatorname{MD5}(k\mathop\Vert 0)\mathop\Vert \operatorname{MD5}(k\mathop\Vert 1)\mathop\Vert \cdots$. This is an unconventional approach: a more conventional approach would use ChaCha20 instead of MD5, or HKDF-MD5 instead of MD5 in CTR mode. But you seem to be looking for something unconventional, so you can carelessly use MD5-CTR like a hipster with no adverse consequences because you don't have any auditors to answer to.

You can use the resulting long secret as a one-time pad to encrypt a long message. If you do this, I recommend that you also use a part of it as the key for a one-time authenticator so your adversary can't flip bits in the messages without your noticing. Remember not to use the same pad or authenticator for two messages.

(‘But that's not a one-time pad!’ you object. As long as your adversary's energy budget is bounded to what the sun can put out, and as long as the adversary's best guess has about $2^{256}$ to 1 odds against being right, then as far as the adversary is concerned it might as well be uniformly distributed among all possible pads. The modern concept of a stream cipher is a practical approximation to the model of a one-time pad, much like AES is a practical approximation to a PRF and Newton's law of gravitation is a practical approximation to how large masses really behave when no one's looking.)

If you aren't allowed to use X25519 or RSA-KEM or anything like that, your task may be more difficult. But the basic conceit of modern cryptography, on which the secure ownership of trillions of dollars of economic value relies using today's internet (along with states to violently enforce property rights, etc.), is that you can break the problem into two parts:

1. First, exchange a small amount of information in public to establish small uniform random secrets.
2. Then expand those small secrets into long ones to conceal and authenticate long nonuniform secrets.

Your question then reduces to how to do the first part in the face of whatever adversary you have in mind, and that depends on the capabilities of the adversary and what resources you have available to you.

Answer 3

Err no. You broke your OTP. The one time bit of it. Order 12345 and 24315 constitutes significant pad reuse when messages are sent by the different users, and that's not good. Do a search for OTP reuse on this site for further details.

There's also the security of the physical disk drop you mention. Seems safe enough to hide a flash drive somewhere to be picked up later. But you're invoking the OTP tag. This means that you're looking for really secure security and now the numbers just work against you again. Assume that THEY can search any one square metre to find your flash drive hidden somewhere under a rock or inside a badger. If you were to randomly hide the drive in any square metre of the land area of Earth and all things being equal, that would only give you 47 bits of security against it being found. That's several squigzillion times less security than the 2560 key bits you were hoping for. The security level will roughly translate to the virtual world too.

Yes, this is also security through obscurity but there is a secret quasi key that you might be unaware of. The URI of the folder. How does that get to the users, and how do you keep it secret?