Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.
Sign up to join this community
I am trying to understand the logic behind some basic principles of AES key padding. Why do we use different kinds of AES key padding schemes instead of the simplest zero-padding? Take AES-128 for example, if my key is "cipherkey", How does the padding work, and what is the problem behind it?
Sorry if the question is too elementary, but I fail to find a good explanation of it.
The question considers padding memorable text like "cipherkey" into an AES key by appending zero bytes to the (UTF-8) expression of this text as bytes, until reaching 16, 24, or 32 bytes for AES-128, AES-192, or AES-256.
The main problem with this is that it's fast and inexpensive, which is a disaster in the context: it allows an adversary to quickly and inexpensively apply that process to plausible passwords, and test the resulting keys against a ciphertext (with known or known-redundant plaintext), and thus find the key. This is password cracking, and there's a small industry developing mixes of software and hardware for this.
A dictionary of the most common million English words (for some extended definition of the word) would I think contain "cipherkey". At least, a Google search found 78,400 occurrences, and it's in the list of the registered domains in three common TLDs. With a known plaintext/ciphertext pair or a ciphertext for a plaintext with some structure, this is going to take few second(s) to break for someone with the right tools.
Even though that can be tremendously improved (see next paragraph), "cipherkey" is not a good password. It's advisable to choose a password that's harder to guess. Merely naming that passphrase will help! But that's a secondary problem.
When turning anything memorable (password, passphrase..) into a key, one must use a key derivation function intended for passwords, that is one with a workfactor parameter allowing to tune the cost of the key derivation. If that cost is 0.5 seconds of a powerful computer's time, rather than 20 nanoseconds for the proposed method, that will become the bottleneck for password cracking, and likely give them at least a sweat. With a passphrase à la XKCD or Diceware, it can be quite secure.
One should use salt, which will prevent computing derived keys in advance, and prevent amortizing the cost of such derivations for several password/key pairs. That's another secondary problem.
It's important that the key derivation function is memory-hard, that is makes use of a sizable amount of memory throughout its computation, for that greatly increases the monetary cost of attack, at little cost to legitimate users. Recommendable functions include Argon2 and scrypt. Common but not recommendable functions include PBKDF2, which is not memory-hard, and among the worse possible use of CPU time for the purpose of password-to-key derivation: it maximizes the edge of attackers using ASICs, FPGAs, and even GPUs w.r.t. legitimate users using CPUs. I find NIST's recommendation for PBKDF2 consistent with their former push for Dual_EC_DRBG:
While PBKDF2 is time-hard but not memory-hard, it is so widely deployed that it is not practical (at this time, anyway) to introduce a requirement for a memory-hard key derivation function.
