0

If you have a symmetric-key algorithm that is limited to using a small key size (say 40-bits) is there any way you could increase the resistance to brute force attacks without increasing the key size?

I am interested in approaches that increase the ciphertext message size (such as padding of some form, or a method that creates a ciphertext larger than the plain text) as I think it would still be affordable to transmit a message that is up to 10 times the original plain text size.

Is there a way to greatly increase the time a brute force attack would require to decrypt the message without increasing the key size?

For prior art I can provide this paper about hiding the key in large amount of random data, and the Chaffing and winnowing method that word plays with authentication and encryption.

Later I found this paper that asks "Is there any way to significantly increase the difficulty for an adversary of performing a brute-force search, while keeping the key size the same and not overly burdening the legitimate communicants?", which is the question I am asking.

daniel
  • 912
  • 5
  • 15
  • 3
    If you don't see a Dyson sphere around the sun, you shouldn't worry about brute-force attacks against a 256-bit key. – CodesInChaos Jun 26 '17 at 10:01

2 Answers2

2

Is there a way to greatly increase the time a brute force attack would require to decrypt the message without increasing the key size?

Something tells me you haven't understood what "brute force attack" means. In short, it boils down to: "try every possible key until you guess the correct one".

As a logic consequence, enlarging plaintext or ciphertext does not add anything to the security of a cipher when it comes to brute force attacks. Your cipher would still rely on the security of that

…small key size (say 40-bits)…

which is definitely too short to make brute-force attacks unfeasible.

Now, instead of thinking about increasing plaintext and/or ciphertext message sizes (which might even introduce additional attack vectors which could void the need for a brute force attack), we usually fall back on KDFs (key derivation functions) to get a stronger key.

Differently worded: instead of trying to make the "message" stronger (which doesn't really make sense), we make the "secret" stronger as that actually adds to security… thanks to the algorithm design of KDFs (with tweakable parameters et al).

Think of it this way — a burglar (read: attacker) doesn't care how big or small your house (read: message) is. All that counts is the strength of the lock (read: cryptographic algorithm) and the strength of the key. A good lock and key can keep a small toolshed in your backyard safe, while a bad lock with an easy to reproduce key can make a military bunker as accessible as a public park bench.

To wrap it up, the security of a cipher mainly* comes from:

  1. the individual cryptographic algorithm used, and
  2. the key, which should be strong/large enough to make it unfeasible to simply "walk all keys until you stumble upon the correct one" (which is what we call a "brute force attack")

When not enough key material is available, KDFs come handy. And in case the cryptographic algorithm doesn't support an accordingly strong key size, you should switch the algorithm for a stronger one. There are ample, well-vetted algos availabe.

* Nota bene: Surely there are some additional nit-bits like initialisation vectors etc that also add to the security of modern ciphers, but I've bluntly skipped all that to keep this answer short and simple.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
  • "try every possible key until you guess the correct one" - Try (takes time) every possible key (number). So the max time to brute force is = try time x number of keys. Can we make the try time bigger, if for whatever reason we can't make the key bigger? +1 for KDF as key stretching is sort of adding time (if you are brute forcing the weak key) , but its also sort of just making a bigger key. – daniel Jun 28 '17 at 17:35
  • Nitpick: there are brute force attacks that don't involve guessing keys. E.g., a brute force MAC forgery attack that guesses message/tag pairs. – Luis Casillas Jun 28 '17 at 21:56
  • Just to mention that fact, according to SHAttered.io, they brute-forced their collision thanks to over $2^{63}$ SHA-1 computations... (And it's not because it is a non-standard scheme that you are any safer, it is most likely possible to build specific hardware to brute-force it.) So you should truly not have any faith in keysizes below 100. – Lery Jun 30 '17 at 22:14
1

$256$ bits is not "small" - humans are really awful at grasping exponential growth. I suggest reading this question and the 3 highest rated answers. If the key has full entropy, a full search is far beyond what is physically posible - and that's what you consider in your question.

Other than that: What do you mean with increase order of magnitude? Other than that: You're trying to fix a 'problem' which does not exist within the limits of our universe.

edit: The original question has $256$ instead of $56$ key bits. To answer the $56$ bit case: This implies you're using DES (single, not triple), which is broken for decades. A small constant factor like $10$ (or $100,1000,...$) does not make DES secure again. Anything below $128$ bits of security is just unacceptable for new systems. 3DES is still used in legacy systems (with just 2 independent keys that's $112$ bits) - but it's strongly discouraged when developing new systems.

tylo
  • 12,654
  • 24
  • 39