# Are really, really long passwords any securer than short ones?

Just for fun, I want to encrypt a message that will take about 10 or so years to decrypt. My idea is to encrypt a message with AES-512 with a password one million decimal digits long.

Knowing not much about cryptography, is this any more difficult to decrypt than a shorter password? (I'm trying to prevent brute-forcing, until computing power becomes so high that it is irrelevant).

-
AES (in all variants) does not take a password, but a fixed-length key. You'll have to define how to derive the key from the password. Also, "decrypt" is normally used when one has the key, otherwise one used "break". Also, welcome to Cryptography Stack Exchange. –  Paŭlo Ebermann Dec 7 '12 at 21:54
See 2.1 on page 3 of $\:$ people.csail.mit.edu/rivest/lcs35-puzzle-description.txt . $\hspace{1.2 in}$ –  Ricky Demer Dec 7 '12 at 22:29
What is AES-512? –  mikeazo Dec 12 '12 at 19:25
We should also note that 'very long passwords' tend to contain much less entropy than you might hope. For example, they are often based on famous phrases or quotes, and modern dictionary based attacks include these. –  figlesquidge Nov 22 '13 at 16:31

There is no AES-512; AES takes keys of 128, 192 or 256 bits.

When encrypting with a password, there are two steps: first the password is converted into a key for the symmetric encryption, then the encryption is applied. Brute force can be applied either on the password (enumerating all possible passwords until a match is found) or on the key itself (enumerating all possible keys until a match is found).

A 128-bit key is large enough to defeat brute force for long period of times. You can use a larger key for display purposes (larger figures impress managers, and some people apparently believe that key length correlates with manhood -- in the same way as big cars).

The same applies to a password with 128 bits of entropy -- which is a way of saying that there are 2128 possible passwords, and you chose one at random among them. You can lower the entropy requirements on the password by using a slow hashing process; roughly speaking, if the function which converts the password into a key has the cost of 220 elementary encryption operations (that's about one million, and will be done in a fraction of a second with a basic PC) then you can be content with 108 bits of password entropy.

If your passwords are random sequences of alphanumeric characters (uppercase letters, lowercase letters, digits), then 19 characters are enough (because you use 62 distinct signs, and 6219 is greater than 2108). More characters are useless. Note that "random" is an important word: I am certainly not talking about choosing the password with your head ! Human brains are definitely bad at randomness. Use a coin, dice, or a computer with /dev/urandom.

All of the above is about making sure that the message will not be decrypted within the next 10 years. A much harder problem is to also ensure that the message will be more or less easily decrypted in year 2022, but not before. I suggest entrusting the key to a notary, with instructions to reveal it at a specific future date.

-
My comment above (to the OP) is about an alternative approach to that much harder problem. $\;\;\;$ –  Ricky Demer Dec 8 '12 at 1:13

According to Gibson Research's Password Haystacks website 23 digits would take 35 years at 100 trillion guesses per second.

-
Note: assuming a 64-character charset, 23 digits is overkill for AES-128 (it would take less time to brute-force the derived encryption key than the actual password). In this situation adding more digits is useless. –  Thomas Dec 8 '12 at 14:22