2

Suppose you encrypt a list of names of Americans with a 512-bit secret-key algorithm. Currently no supercomputer can break it, but someday a supercomputer might exist that could iterate through all possible keys and find a key that decrypts the list to what sound like American-sounding names, and when you find that, you know you've probably got the right key.

Is there a term for secret-key encryption where many possible keys will decrypt the ciphertext to realistic-looking plaintext, so the encryption can never be brute-forced, because even if you find a key that decrypts to one of the realistic plaintexts, you won't know if you got the right one? (And thus, presumably, the encryption could be done with a shorter encryption key, since it can't be brute-forced anyway.)

A one-time pad would have this property, of course, but presumably so could other systems.

Say, instead of storing a list of American names, you come up with an index of every American first name and every American last name. Then when storing the firstname-lastname pairs, you store them as pairs of numbers. Then any key that decrypts the ciphertext to a list of numbers will thereby decrypt to a list of names. (Except, you'd need to do more work than that, because some names are more common than others, so the attacker could try to find a key which decrypts to a list where the names follow the expected distribution. But that's the idea.)

So does this have a name? Many-plaintext encryption or something?

Bennett
  • 653
  • 3
  • 10

2 Answers2

3

That reminds me of the concept of encryption that offers Plausible Deniability, aka "Deniable Encryption" which has the following property:

Deniable encryption makes it impossible to prove the existence of the plaintext message without the proper decryption key. This may be done by allowing an encrypted message to be decrypted to different sensible plaintexts, depending on the key used. This allows the sender to have plausible deniability if compelled to give up his or her encryption key.

The commonly-cited use for this is at airports: have two operating systems steganographically overlapped on the same hard drive. When airport security asks you to boot up your laptop, enter the decryption password for the "innocent" OS. Even if they forensically examine your laptop, nobody would guess that there's a second OS hiding in plain sight.

Thanks to @JamesMishra for pointing out in this post that:

TrueCrypt had a similar hidden operating system feature where the TrueCrypt bootloader would accept two different passwords, giving access to two different operating systems. The hidden operating system was concealed with a bit of clever steganography.

Second, let's talk about this:

someday a supercomputer might exist that could iterate through all [2512] possible keys and find a key that decrypts the list

I see where you're coming from, but brunt computing power alone isn't enough. See this answer of mine for math showing that counting from 0 to 2208 would require you to consume the energy equivalent of the sun.

The YouTube channel 3Blue1Brown has an excellent video showing just how mind-bogglingly large the number 2256 is.

In summary:

2^256 = (4 billion) x (4 billion) x (4 billion) x (4 billion) x (4 billion) x (4 billion) x (4 billion) x (4 billion)

Counting from 0 to 2256 would require: a GPU capable of doing 4 billion ops/s x 1 kilo-Google's worth of servers x 4 billion people each having their own personal kilo-Google's worth of servers x 4 billion copies of the planet Earth x 4 billion copies of the Milky Way x 37 time the age of the universe. And we're still missing one more factor of 4 billion. Yeah, 2256 is an unfathomably large number.

Your intuition is not entirely wrong though; over time we do get better at cracking encryption keys, but that has more to do with advances in understanding the mathematics of a specific encryption algorithm that let us narrow in on likely keys, but brunt computer speed alone won't even get us there.

Mike Ounsworth
  • 59,005
  • 21
  • 158
  • 212
  • Does your analysis take quantum computing into account -- i.e. is it possible that quantum computing would offer a practical way to brute-force the password, notwithstanding everything you said? (I know nothing about quantum computing except for hearing that it makes brute-forcing much easier.) – Bennett Sep 09 '18 at 22:17
  • Regarding the "duress password" for booting up your laptop, this technically doesn't meet my requirement because of the attacker did make an image of your disk and a virtual simulation of your laptop, they could still use brute-force to find the two passwords that lead to two different operating systems, and then they could probably guess which was the one you were trying to hide. – Bennett Sep 09 '18 at 22:19
  • @Bennett Quantum computers give a square-root speedup, so cracking a 512-bit key takes 2^256 quantum ops, cracking a 256-bit key takes 2^128 quantum ops. But doing 128 quantum ops (ie cracking a single key) would still consume the power equivalent of the sun's output for 30 years. – Mike Ounsworth Sep 10 '18 at 13:03
  • An important property of a cipher is that the cipher text (or equivalently, decrypting with the wrong key) is indistinguishable from a random string. If you take a string at random, there's a 99.99...% chance that it's unintelligible. You seem to want a cipher where the wrong key gives you intelligeable text with high probability. This would make it vulnerable to all sorts of statistical attacks, and therefore a terrible cipher. So I think what you want is a duress key system, but with many duress key / data pairs. (still unsure why you want this, a 256-bit key will not be guessed, ever). – Mike Ounsworth Sep 10 '18 at 13:09
  • take the example that I used in the post -- rather than storing people's first names and last names, make a list of all possible first names and last names and then store a list of indexes into that list. If that's the format of your plaintext, then decrypting with the wrong key will still give you "intelligible" plaintext -- it will be a list of numbers which are indexes into those lists, it just won't be the right names. – Bennett Sep 11 '18 at 05:44
  • Also, why is it an "important property of a cipher" that the ciphertext be "indistinguishable from a random string"? Presumably the only important property of a cipher would be that it's hard to break without the key. – Bennett Sep 11 '18 at 05:46
  • @Bennett Maybe. How many names on your list, and what's the bit-width of your integers? If a decryption contains even a single integer that's larger than your list, then the attacker knows it's not a valid decryption. (This shouldn't discourage you from thinking about this, getting crypto right is hard work!) – Mike Ounsworth Sep 11 '18 at 13:05
  • @Bennett If cipher text is not indistinguishable from random, then it's easy to break without the key :) See wikipedia/Ciphertext_indistinguishability. Imagine your cipher is being used to encrypt one of two possible messages "Yes" and "No!". The attacker sees the ciphertext going by. If, based only on the ciphertext, they can do better than a random guess which plaintext it came from (even a 50.01% chance of being right) then it's considered to be a broken cipher. This concept is summarized as "indistinguishable from random". – Mike Ounsworth Sep 11 '18 at 13:15
  • the definition on that wikipedia page says that given the ciphertext and a choice of plaintexts, the attacker should not be able to guess (with better than random chance) which plaintext resulted in the ciphertext. That is not the same as the ciphertext being "indistinguishable from a random string" :) I can imagine a cipher being a perfectly good cipher and still only producing, for whatever reason, hexadecimal numbers in the range from 0 to B instead of 0 to F. – Bennett Sep 13 '18 at 01:10
  • @Bennett Right, but if I gave you two strings 1) the ciphertext for "yes", 2) a random hexadecimal number in the range 0 to B, and you could tell which was which then it would be a bad cipher. ("random string" meaning a valid output string chosen at random). It turns out to be an equivalent statement to "able to guess (with better than random chance) which plaintext resulted in the ciphertext" cause if you can do one, you can do the other. – Mike Ounsworth Sep 13 '18 at 01:22
  • ah OK, so you meant that the ciphertext should be (essentially) indistinguishable from the ciphertext of encrypting a random string. But what you said was that "An important property of a cipher is that the cipher text is indistinguishable from a random string", which is not the same thing :) – Bennett Sep 13 '18 at 20:29
  • @Bennett Yes? No? I mean, these are all equivalent: a) distinguish between encr("yes") and encr("no"), b) distinguish between encr("yes"), and encr("oe8"), c) distinguish between encr("yes"), and "4ge". I guess technically they are different, but they are different ways of expressing the same "ciphertext indistinguishability" property of a good cipher. Like, if your cipher passes one of them, then it'll pass the others; if it fails one then it'll fail the others. – Mike Ounsworth Sep 13 '18 at 20:49
  • but what you are saying is that the ciphertext is indistinguishable from the ciphertext of a random string. I understand that is an important property of a cipher. However what you first wrote was "that the cipher text is indistinguishable from a random string", and there is a difference between "the ciphertext looking like a random string" and "the ciphertext looking like the ciphertext of a random string", and that's what threw me. Clear what I mean now? – Bennett Sep 14 '18 at 21:24
  • @Bennett No. There is no difference between those two things. See my last post. – Mike Ounsworth Sep 14 '18 at 21:27
  • Oh OK but you later clarified to say "random string" means chosen at random from possible ciphertexts. The problem is that even that is not precisely the same, because suppose for the sake of argument you have a ciphertext that mostly produces output hex chars in the range 0x00 to 0xAF, but one in every 1,000 characters is in the range 0xB0 to 0xFF. There's no reason this can't be a perfectly good cipher. However, if you're now comparing the output to a truly random string, you can determine with very high probability which is one is the "random" string (because it has a ... – Bennett Sep 14 '18 at 21:44
  • @Bennett I guess I can clarify that when I say "the same" it's short-hand for "when you unroll the math, they are both giving you the same information". aka "the same" = "equivalent". The same way I would say that the point on a graph (2,3), the complex number 2+3i, and the fraction 3/2 are all "the same" when the property you care about is the slope of the line that they describe. – Mike Ounsworth Sep 14 '18 at 21:45
  • ... normal frequency of 0xB0 to 0xFF characters), even though technically both are valid ciphertexts. What you want is for the ciphertext to be indistinguishable from a string chosen at random from valid outputs with a weighted average toward the more frequent outputs. This is logically equivalent to "ciphertext of a random string", which is a much simpler way of expressing the same thing. – Bennett Sep 14 '18 at 21:46
  • @Bennett There's plenty of reason that would be a bad cipher: one in every 1,000 times you've leaked something about either your key or your plaintext. In fact, 100% of the time you're leaking something: either than combination of ciphertext+key either is or isn't in the set that gives you the "one in 1,000" behaviour. If you allow me to see 100,000's of ciphertexts, I'll be able to crack your key. – Mike Ounsworth Sep 14 '18 at 21:47
0

The word you may be thinking of is a duress password, one that is given when you suspect or know you are being monitored.

It is possible to provide two different plaintexts from the same ciphertext, by using a true One Time Pad with XOR. (For text, this can also be done with a classical Vigenere cipher.) But this requires a key as long as your message. That works for short text messages, but isn’t practical for something like a disk image.

John Deters
  • 34,205
  • 3
  • 61
  • 113
  • I know about duress passwords but it's not exactly what I'm looking for because, for example, there is usually one "real" password and one "duress" password, and if a brute-force effort found both of them, the attacker could usually guess which cleartext was the one you were trying to hide. I'm talking about systems where there are so many possible plausible plaintexts, depending on which decryption key you use, that the attacker can't guess which one is real. – Bennett Sep 09 '18 at 22:14