1

Respected community,

I was wondering how weak would AES-128 be, if we provide only a 64 bit key with the other remaining 64 bits either zero bits or public constants, known to the attacker. Is it easy for the attacker to try $2^{64}$ guesses for the unknown part of the key?

To gain more clarity to my query, lets say I have only 64 bits of data that can be used as a key, how can I derive a 128 bit key out of that 64 bit data, so that I get the full strength of AES-128 ? I don't think using a hash function like SHA-256, and taking its first 16 bytes would add a considerable amount of effort for the attacker, since we presently have the hardware like ASICs and FPGAs, for calculating SHA-256 quickly!

I am using AES in counter mode, so does that increase / decrease the effort required by the attacker?

Please understand that this is a question for learning and increasing my knowledge in cryptography and not intended for practical or serious use cases.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
Aravind A
  • 1,020
  • 10
  • 21

2 Answers2

8

Using AES-128 with only 64-bit uniform random is not secure. There are many entities around that can break this easily by searching the $2^{64}$- space.

Machines in a second in an hour in a day in a year
Summit on SHA-1 $\approx 2^{49.7} $ $ \approx 2^{61.5}$ $\approx 2^{66.1}$ $\approx 2^{74.6}$
Titan on SHA-1 $\approx 2^{49.1} $ $\approx 2^{61.0}$ $ \approx 2^{65.5}$ $\approx 2^{74.1}$
Bitcoin Miner on SHA-256D $\approx 2^{67.1}$ $\approx 2^{78.9}$ $\approx 2^{83.5}$ $\approx 2^{92.09}$

See the details here*;

Only possible additional complexity that you can put is using Key Derivation Functions that has iteration count/ memory-cache hardness, and parallelization hardness. However, this will not be enough to save you, because;

  • you need around $2^{64}$-iteration (to reach $2^{128}$) to reduce the attack speed of the brute force ( assuming that you crippled the ASIC/FPGA with memory hardness, and crippled the parallelization, too) so that they will need to execute $2^{64}$ steps to derive the key from one of the $2^{64}$ candidate keys. Well, this is not meaningful for you.

As, a conclusion, you are safe as much as further you can iterate and you can correctly use the KDFs;

  • Scrypt, Balloon, Argon2, or better bScrypt ( has cache hardness )

    Reaching $2^{64}$ for a single entity is very hard, for you, too. And, NIST requires at least 112-bit security from lightweight crypto, this should mean something to us. Even for reaching 112 bits of security, you may need days, months, on your key generation to encrypt or decrypt to access your files.

Note: The Grover's machine was not considered on the above, it may break(!) the AES-128 if the problems are solved.

I am using AES in counter mode, so does that increase / decrease the effort required by the attacker?

Not much, CTR mode enables random access, that's all here.

* The table was calculated for SHA-1 and SHA-2, and should gives us some information about publicly available computing powers.

kelalaka
  • 48,443
  • 11
  • 116
  • 196
  • Thankyou very much, kelalaka :) I have marked it as the accepted answer :) So now the problem has become like deriving a secure key from a 8 byte password :) – Aravind A Oct 07 '23 at 18:32
  • Prefer to use 256-bit cipher with 256-bits of uniform random key, that is the golden standard, secure from all attacks, classical and quantum. Keep in mind that each mode of operations has pros and cons, so depending on the use case, be careful what you select. – kelalaka Oct 07 '23 at 18:35
  • Keep in mind that we have good password generators like dicewire, bip-39. – kelalaka Oct 07 '23 at 19:22
  • 4
    @VivekanandV Do note that if the 8-byte password is written by user (as opposed to random binary data), it probably has less than 50 bits of entropy. – jpa Oct 08 '23 at 07:36
0

Simply leaving parts of the key fixed would make this scheme susceptible to a related-key attack, so it's possible that an attacker could recover the key in less than $2^{64}$ time. Using a hash function (or preferably, a KDF as suggested by kelalaka) for key derivation would prevent this.

eax
  • 101
  • 1