Understanding AES Keys and Passphrases

Question

I am trying to get my head around how AES works and in particular I have queries around the key generation and 'passphrases'.

My understanding is that AES has a 128 bit block size but the key length changes depending on which variation you use, e.g AES256 uses a 256bit key.

1. If the encryption is reliant on the key, should you be using a cryptographically secure psuedorandom random number generator in order to generate a 256 bit key?
2. Looking at this site it also allows you to set a passphrase when generating a key. What role does the passphrase have when generating the key?
3. If you were required to rotate an AES key due to policy, would the encrypted data need to be decrypted using an old key before re-encrypting with the new key? I'd assume this would need to be built within the application login?

Answer 1

This question is both too broad and too narrow, but I'll see what I can do.

Your understanding about AES block and key sizes is correct.

1. Usually, yes, you'd want to use a cryptographically secure (P)RNG to generate encryption keys (for any cipher, AES included). However, there are times when this isn't practical, such as when a human needs to be able to remember the key (or remember some data that can be used to generate the key). For situations like that, there are key-derivation functions that turn a "secret" (potentially a password/passphrase) into a key. KDFs don't actually add any entropy, so the resulting key is far more subject to brute-force than a truly random one (a truly random 128-bit key is practically impossible to brute-force, much less a 256-bit key), but sometimes that's a risk you have to accept. KDFs are usually deliberately slow and sometimes (relatively) RAM-intensive, to make brute-forcing the key from a (usually large) pool of potential secrets much slower / harder to parallelize.
2. I don't know what that site is doing, and without examining its source code I couldn't say with confidence even if it has a "what am I doing?" write-up somewhere. It doesn't require the passphrase (though it produces buggy-looking output without it). It might be using a PRNG (secure or not) to generate a "salt" and then generating a key from that salt and your passphrase using a KDF. It might be using a PRNG - secure or not - that allows you to "add entropy" and inserting the passphrase as added entropy then generating the key out of that PRNG directly; this is not technically insecure but is generally pointless and may be misleading. (For example, Java's SecureRandom class can accept additional entropy but there is approximately never a good reason to do this.) If you want more info about that site, ask it in a separate question.
3. If you need to rotate any encryption key (AES included) for any reason (policy included), then you need to decrypt the data using the old key before the old key is discarded, or the data will be lost. You then need to re-encrypt the data using the new key, or the data will be in plain text. The usual way to do this performantly is to generate a "master key" that is the one actually used to encrypt and decrypt data, and encrypt (and decrypt) the master key with a user key (which might be derived from a passphrase, stored in a file, whatever). The master key is never stored in plain text, and is only decrypted briefly when it is necessary to encrypt or decrypt the data, or to rotate a user key. This way, rotating the user key just requires decrypting the master key and re-encrypting it with the new user key; you don't have to decrypt and re-encrypt the entire body of data. Since the master key is itself stored encrypted and is never exposed to the user or to any other system (at least, not in plain text), it does not, itself, need rotation unless you suspect it to have been compromised. This is how many systems that need to encrypt large amounts of data, such as full-disk encryption utilities, work.

Without a lot more information about how your application works and what its goals are, I cannot comment on when or where the key rotation process would happen. If you want help with designing a specific cryptosystem, you could ask another question here but you really should hire somebody who is familiar with designing cryptosystems. Cryptography is hard, and rolling your own design - while probably safer than rolling your own implementation of a primitive, much less designing your own primitive - is still a risky business.

Answer 2

Just to add-on to your third question, key rotation can mean different things in different contexts. When using a key management system, key rotation means generating a new key to be used for future encryptions; but the old keys remain in the system and are preserved for decryption. All encrypted data is tagged with the identity of the key used to encrypt it, allowing the data to be decrypted with the same key used to encrypt it. This avoids the risks of reencrypting batches of bulk data; data that is often scattered all over the place and is sometimes out of the control of the key owner.

This also allows the cryptoperiod of encryption to differ from the cryptoperiod of decryption. For example I can rotate keys monthly, and delete old keys annually, just by keeping only the last 12 keys in the key manager.

Such systems have their drawbacks, though. They often use a proprietary tagging system that doesn’t interoperate with others (I haven’t seen any that use a CMS formatted envelope to identify the encrypting key, for example.) This strongly promotes vendor lock-in, because only that vendor’s library will decrypt the data.