# Can you encrypt a 256bit password with a 256bit key so that it cannot be bruteforced?

Lets say we have an arbitrary but dictionary attackable password that is less than 256bit. (Lets just say the password is '1234Password').

We encrypt this password with a securely random 256bit key using AES.

So we have encrypted_password = aes(password, key).

The key is ONLY used to store this password, and is not used anywhere else.

Assuming someone has the encrypted_password and unlimited processing power, will they be able to bruteforce the password? Of course they can run through all the possible keys and one of them will output 1234Password, but will there be copious of other human readable passwords, and thus the attacker wouldn't have a useful output? Or would this set be limited and thus not impactical to find the password.

Let me rephrase for clarity.

1. We live in a universe where processing power is unlimited and bruteforcing all of the possibilities is practical.
2. We have a password p, less than 256bit that isn't random. (very limited entropy)
3. it was encrypted with k, a random key of 256bit. This key is unique to this use case and does not encrypt anything else.
4. encrypted_password ep = aes(p, k).
5. If the attacker obtains ep, can they determine what p was? Or will different keys produce too many results that are also very limited entropy, and thus could also be the possible password.
• Comments are not for extended discussion; this conversation has been moved to chat. – Ella Rose Feb 17 at 20:20

## 2 Answers

What you are describing is a one-time-pad. If the password was encrypted with a 256 bit key and the resulting ciphertext was acquired by the attacker then he would produce all $$2^{256}$$ possible plaintexts (including the correct one) but there would be no way to distinguish which one is correct.

However no one uses OTP in practice because the key has to be truly random and as long as the message itself. AES is not perfectly secure but sufficiently secure. If your attacker was able to brute force all $$2^{256}$$ possibilities then he would be able to confidently claim what your plaintext is.

Luckily for the defender brute forcing a 256 bit key is impractical.

--edit--
To show why an attacker could confidently claim what the original plaintext was of all possible plaintexts it would be easiest to show by an example.

If you have a substitution cipher with the given scrambling.

abcdefghijklmnopqrstuvwxyz
xyzabcdefghijklmnopqrstuvw

and then you encrypt a message say 'flee at once. we are discovered'

flee at once. we are discovered
cibb xq lkzb. tb xob afpzlsboba

xob could have been are, ate, sue, car, sub, cat, etc... but if we use frequency analysis we can see that the letter b shows up the most and so that's probably and e in the plaintext which rules out car, sub, cat. The plaintext for xob is more likely to be ate, are, or sue but we're not sure which one. If you keep going with the frequency analysis you'll rule out more and more plaintext possibilities until only a few or just 1 is left.

• There is a way to determine at least reduce the candidates. Read the chat. – kelalaka Feb 17 at 21:13
• Why do you write “If your attacker was able to brute force all 2^256 possibilities then he would be able to confidently claim what your plaintext is.”? Wouldn’t the attacker also find things like “qwertyuiop”, “1234567890”, “qazwsxedc” and thousands (or even millions) of other weak passwords, amond the possible plaintexts? – user2233709 Feb 17 at 21:15

If the 256-bit AES key is only used to encrypt the 256-bit password, then I don't think you even need AES at all because a simple OTP can do the work. You may want to use AES if considering a computationally bounded adversary that is able to know some plaintext-ciphertext pairs. OTP has perfect secrecy for one-time use so no adversary (with unlimited computational power) can obtain any additional information about your password by looking at the ciphertext (i.e., a random key xor your password).

However, I don't think encrypting the password can benefit you in any way. You need to privately store either a 256-bit key or a 256-bit (but low-entropy) password. Encrypting the password costs additional computational power.

• The OP. has to decide his question. AFAIK he was asking for password protection. You can find in the comments under the quesiton. – kelalaka Feb 18 at 6:36