0

Can this method of encryption prevent bruteforce attacks?

If I had a hypothetical table (or function) where every grammatically valid sentence (limited to some number of words) was given an associated number, e.g:

"Good morning, how are you." = 3283
"Today is a nice day." = 2183

Then added a number (as a key), e.g:

3283 + 1234 = 4516

Wouldn't this final output of 4516 be effectively protected against bruteforce attacks?

Ignoring the difficulty of producing a hashtable/function capable of reducing every valid input into a single number, and the issue of sending the key 1234 securely.

Is there any way of finding the original input only from the output?

Is limiting the domain of the encryption to only valid inputs, an effective method of preventing bruteforce attacks?

If so is there any practical example of this? Why or why not?

Improve this question
15
  • This is a very obscure way to generate your secret. What happens when (not if) someone learns every valid input? That list of valid inputs is quite a bit shorter than the list of invalid inputs, right? While this is thinking along the right lines, it forgets one of the foundations of security: Kerckhoffs' Principle: Assume that the attacker knows everything except your password (and any other secret keys).
    – Ghedipunk
    Jan 7, 2020 at 4:28
  • "Ignoring the difficulty of..." No, we don't ignore the difficulty of anything. We absolutely depend on difficulty. If we ignore the difficulty of something, we (wrongly) assume that the something is (as asserted) a difficult thing. Maybe it's difficult to develop an exhaustive hash table, but it isn't difficult for someone to guess what another human might think is valid grammer at least 80% of the time, which gives us 80% of the plausible passwords.
    – Ghedipunk
    Jan 7, 2020 at 4:31
  • @Ghedipunk Well I was imagining something more like the library of babel except it only includes grammatically valid inputs. So the number of valid inputs would be massive. So for the attacker to perform the attack, it would produce a perfectly valid input every time? So I'd assume password is plausible?
    – Some Dinosaur
    Jan 7, 2020 at 4:33
  • Again, right idea, wrong implementation. Don't hide information. Destroy information.
    – Ghedipunk
    Jan 7, 2020 at 4:33
  • 1
    If the number of valid inputs is finite and limited, then bruteforcing becomes easier. It's just a dictionary attack, and the only challenge is finding the most optimal order to bruteforce through that dictionary. You want to allow every single bit, from b00000000 through b11111111 to be valid in every single byte of every single key, if possible. Even with Matrioshka Brains around every star, it would take until the heat death of the universe to brute force a 256 bit key. That's your ideal, not filtering based on human languages.
    – Ghedipunk
    Jan 7, 2020 at 4:42

1 Answer 1

Reset to default
-1

"Is limiting the domain of the encryption to only valid inputs, an effective method of preventing bruteforce attacks?" -- No. It is merely limiting the search space that attackers need. – Ghedipunk

If this was a traditional encryption, GhediPunk would be correct. But in this case it is different, as explained below:

This in fact is immune to bruteforce, as it is the same as a One-Time Pad; except instead of having a static transform you apply to a plaintext, you have a static plaintext (with the agreed codewords).

Since there is no structure like grammar to impose in order to check correctness, bruteforce won't help.

Of course, while it is immune to a bruteforce attack, like a One-Time Pad it is not immune to an attack on the key-exchange or other weaker parts of the protocol. So this is basically just a One-Time Pad with a slightly impractical twist.

What this does highlight are the few cases where bruteforce is completely impractical (assuming the adversary has unlimited computational power):

  • When the enciphered output produces valid input for incorrect keys (e.g this cipher & One-Time Pad)
  • When the enciphered output is incomplete (e.g Shamir's secret sharing)
  • When the enciphered input has no pattern (e.g Encrypting a random bits)

(Note the last point is essentially the same as the first)

Of course in most modern practical cases, no one assumes the adversary has unlimited computation power, and generally one opts for the option where the cost of breaking the cipher outweighs the cost of the gaining the information, as it is more realistic.

Edit: Demo of one-time-pad with text swapped out with pad.

Improve this answer
7
  • 2
    I don't see how this is a one-time pad. It seems to be missing the "one-time" part. What OP seems to have is a lookup table combined with a poor transformation (why + instead of eg XOR?) with a static key (1234).
    – tim
    May 4, 2020 at 8:30
  • @tim The lookup table is static, the key is the "one-time" part. It is not a static key 1234. XOR is essentially binary addition except there is no carry from bit to bit. Plus is more understandable for some people and more destructive than XOR.
    – Some Dinosaur
    May 4, 2020 at 8:36
  • 1
    The focus of the question seemed to be the lookup table. But if you ignore that part and if 1234 is generated from a truly random key stream and only used once, then it's a one-time pad. Non-modular plus is less destructive than XOR (see here, especially point 4.), and I'm not sure modular plus is easier to understand for most people than XOR.
    – tim
    May 4, 2020 at 8:48
  • @tim Right, I guess the original question was unclear on several points. I assume it depends on the persons background on which is more understandable. XOR maybe more understandable for people here.
    – Some Dinosaur
    May 4, 2020 at 8:55
  • This does not work because you need a second key. You need something to ensure that the decrypted message is the one intended. So, sure, it's protected against brute-force, because it's protected against integrity, too. You have no idea whether the ciphertext or key was corrupted or altered or if you ended up with the intended plaintext.
    – schroeder ♦
    Jun 13, 2020 at 8:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .