How safe is AES 256bitkey encoded in HEX, Base64?

Question

I am using CryptoJS AES 256 encryption:

CryptoJS.AES.encrypt(realData, generateKey(passphrase), {iv: iv});

The secret is generated through:

function generateKey(passphrase) {
  const salt = CryptoJS.lib.WordArray.random(128 / 8);
  const key256Bits = CryptoJS.PBKDF2(passphrase, salt, {
    keySize: 256 / 32,
    iterations: randomBigNumber,
  });

  return key256Bits;
}

I plan on storing on an SQL(or a text file) database the encoding readable HEX or Base64 of key256Bits returned from generateKey(passphrase) and then later retriving those encoding readable string to parse back to the key256Bits to decrypt the realData in CryptoJS.AES.encrypt(realData, generateKey(passphrase), {iv: iv});

Is it the correct way? Can the key256Bits be stored in SQL(or a file) database then retrived later for decrypting?

Also the encoding readable(Hex, Base64) string of generateKey(passphrase) (which in Crypto-JS I can just use key256Bits.toString(<-- base64 or hex -->)) does not contain any special characters if hex or only '/,+' and wierd ending '==' if base64. And that is easy for brute force then convert back to array of bytes(the returned key from generateKey(passphrase)) then put into decrypt the realData?

So what should be the correct way to store the key256Bits and can be easily to retrive later? I'm new to this, correct me if wrong. Thanks!

Answer 1

You seem dangerously confused about this whole topic, so I'm going to answer the question as asked, and then a few others you might have meant (or should have meant), and explain what's going on and what you should actually do.

---

You asked: How safe is AES 256bitkey encoded in HEX, Base64? Exactly as safe as any other data stored in the same place or transmitted via the same connection as the key.

Your confusion might be based on: How much security is added or lost by encoding a secret, such as a key, in Hex or Base64? None whatsoever, in either direction, for either encoding (or even both of them together, if you want to waste space and CPU cycles).

Encodings are fully reversible and easily recognizable; they are not keyed, there's no secret to them whatsoever. As such, they can't add any security, because there's nothing that the attacker doesn't know. At the same time, they don't cost any security, because while there is less entropy (unguessability) per encoded byte, the encoding makes the secret (or any other data) longer by exactly the amount necessary to preserve the total entropy it had before (this follows necessarily from the "fully reversible" property).

You seem to want to know: How do I securely store a key? Ideally, you don't. You leave that up to the user / client to enter when needed, make the key storage somebody else's problem. Since you're already deriving your keys from a passphrase, which is presumably provided by somebody, have that somebody remember the passphrase, and all you need to remember is the salt and iteration count[1] and you can re-derive the key when the user re-supplies the passphrase.

If you don't have the option of getting the passphrase from a user/client whenever the key is needed, or if you aren't willing to accept the weaknesses of using passphrases[2] and would rather generate and store a secure random key yourself, you can do that too. First, ditch the passphrase in that case - just use a secure random number generator to generate the key (the same as you're already doing the for the salt) - unless it's serving some critical purpose (such as key recovery).

Next, pick somewhere as secure as possible to store the key. The database is an option, since presumably you already care if your DB is breached and thus have security in place against that, but you can do better. A file on the file system is slightly less likely to be exposed by something like SQL injection (though more likely to be exposed through local file inclusion) and is not generally a good idea. Storing the key in the DB but encrypting it with another key that is stored on the file system is a decent option, especially if the software that uses the key is running on a different machine than the DB, since then a SQLi can't read the keyfile and a LFI can't read from the DB, so then an attacker has to compromise both to get your key(s) in a usable form. Even better than a DB or file, though, is a hardware security module (HSM), which is a hardened computer chip that allows controlled access to the secrets it contains, and can even be made write-only (that is, you can add secrets - along with ways to use them, such as "HMAC this data" or "decrypt data X using AES256-CBC with IV Y" - in such a way that the HSM will never divulge the actual key). HSMs cost money, of course, and need to be protected themselves (can't let just anybody use the HSM, or worse walk off with it). There are also software security modules or "vaults", which are hardened processes that run on a machine (possibly, though not always, the same machine as where their secrets are used) but with unique access permissions that prevent anybody else (except the admin/superuser) from reading their data. The processes have a defined interface, and act basically like an HSM, except of course the data must be stored on disk or similar in some form because there's no dedicated hardware for it. Windows and MacOS have these built in, and there are various third-party options. Some cloud providers also offer a key storage / management system, which is usually backed by an HSM but sort of shares out its functionality using software.

[1]: Please use a better algorithm than PBKDF2 if you're actually hashing/deriving keys from passphrases, it's not the 00s anymore and there are plenty of better choices.
[2]: Human-memorable passphrases tend to have low entropy, and even securely random ones are at best as good as MAX(entropy_of_passphrase, entropy_of_key_derivation_function_output) and in practice usually a bit less because KDFs, like all hash functions, are not fully reversible and lose a little entropy in the process... though in practice this loss is irrelevant for any decent secure hash.