1
$\begingroup$

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.

$\endgroup$
  • 1
    $\begingroup$ This sounds overly complicated, pretty unreliable, and very insecure. What is your scenario so that you can't use simpler, yet more well-vetted encryption algos (like, for example, ChaCha20) in combination with a KDF… potentially agreeing on a common secret via public-key encryption? Also, how are you planning to handle authentication? OTP generally doesn't provide that out-of-the-box. $\endgroup$ – e-sushi Sep 6 '17 at 20:25
  • $\begingroup$ One scenario would be government or other authority that frowns on overt encryption technology, such as ChaCha20 or public key crypto. When mere possession of encryption technology is either illegal per se or evidence of bad intent, a hash function (which has many other uses) can provide plausible deniability. $\endgroup$ – Paul S Sep 6 '17 at 20:42
  • $\begingroup$ You know the design of ChaCha20 itself arose partly as a response to export controls on block ciphers that did not cover hash functions? You can always turn a preimage-resistant hash function into a stream cipher by applying it in ‘CTR mode’—which is exactly what ChaCha20 does. $\operatorname{MD5}(k\mathop\Vert 0)\mathop\Vert\operatorname{MD5}(k\mathop\Vert 1)\mathop\Vert\cdots$ accomplishes the same thing, albeit much slower. $\endgroup$ – Squeamish Ossifrage Sep 6 '17 at 21:32
  • $\begingroup$ Thanks, Ossifrage. I actually did not know the history of ChaCha20. It still seems though that possession of ChaCha20 or similar crypto could be incriminating, in ways that possession of a hash function is not. It's like the difference between possession of a firearm and possession of a kitchen knife. Both can be used as weapons, but the knife is more easily explained. $\endgroup$ – Paul S Sep 6 '17 at 21:43
1
$\begingroup$

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 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.

$\endgroup$
  • $\begingroup$ Thanks again for your feedback. Of course generating perfectly random keys is a significant challenge, and to the extent that a key falls short of that its security is compromised. However I believe that the output of a good hash function is very close to random. The main fly in the ointment is the vulnerability of the input files. $\endgroup$ – Paul S Sep 6 '17 at 22:23
  • $\begingroup$ As I mentioned up-thread, any dead-drop relies on security through obscurity. If a drop is identified by the enemy it is useless. However despite this drawback dead drops have been used continuously even to the present day, and even against governmental adversaries. So while I recognize the vulnerability of a drop I don't think that's a dealbreaker. Thank you particularly for the advice on generating a stream cipher from a hash function. $\endgroup$ – Paul S Sep 6 '17 at 22:23
1
$\begingroup$

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.

$\endgroup$
  • $\begingroup$ I don't understand how you can make the theoretical equivalency between a true OTP key and a PRNG? It's not like you... $\endgroup$ – Paul Uszak Sep 9 '17 at 20:43
  • $\begingroup$ Also your dead drop idea is only 47 bits secure, compared to your 256 bit key. That's bigly different. $\endgroup$ – Paul Uszak Sep 9 '17 at 20:45
  • $\begingroup$ @PaulUszak: What is 47 bits here? I didn't assert a theoretical equivalence. I asserted a practical approximation that will resist real adversaries far better than any hare-brained schemes one tries to cook up to stealthily establish practical email-length pads uniformly at random to an adversary, as evidenced by the trillions of dollars of economic value routinely protected by one-time pads generated using AES-CTR and one-time authenticators made with GHASH using keys agreed on with ECDH. (My HTTPS connection to this site is doing exactly that—TLS with ECDHE-RSA-AES128-GCM-SHA256!) $\endgroup$ – Squeamish Ossifrage Sep 10 '17 at 0:00
0
$\begingroup$

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?

$\endgroup$
  • $\begingroup$ Thanks, Paul. That's the sort of feedback I'm looking for. So reusing blocks of the OTP key in a different order breaks the security. This I did not know. $\endgroup$ – Paul S Sep 6 '17 at 20:51
  • $\begingroup$ > The URI of the folder. How does that get to the users, and how do you keep it secret? This could be a problem, yes. The simplest method would probably be a twitter feed in which the "folder" is identified by username. The username can be left at a physical dead drop, scrawled on a wall as graphiti, etc. Security through obscurity is a basic flaw of any dead drop, of course, be it digital or physical. If the location of the drop is discovered then it is no longer useful. Fortunately it is possible to make them very obscure. $\endgroup$ – Paul S Sep 6 '17 at 21:02
  • $\begingroup$ A possible solution to the OTP reuse problem is to provide more files, identified with a hashtag unique to each users. Then users could recover the files needed to generate truly unique keys, with no need for reuse. $\endgroup$ – Paul S Sep 6 '17 at 21:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.