0
$\begingroup$

As title I have a password-like passphrase (8 chars at least) that is then hashed with argon2(with the salt is SHA256 of that passphrase).

Then use it as AES256 key along with a random IV generated by CryptoJS.lib.WordArray.random(256 / 8);

Is it okay?

Or should I use the IV as a key?

Improve this question
$\endgroup$
1
  • 1
    $\begingroup$ Did you search our site? We had tons of questions like this. Hash functions cannot increase the entropy. So, your input has 64-bit entropy ( assuming the ASCII encoding). This is a matter of time for huge adversaries like NSA, Summit, and collective bitcoin miners to reach your key in seconds. IV is not a key. Start searching from here password+AES $\endgroup$
    – kelalaka
    Aug 17, 2022 at 15:06

1 Answer 1

Reset to default
0
$\begingroup$

with the salt is SHA256 of that passphrase

Don't use the SHA-256 of the passphrase as the salt; randomly generate it so it's not the same for identical passwords.

CryptoJS.lib.WordArray.random(256 / 8);

Don't use CryptoJS. From memory, it generated random numbers incorrectly, the passphrase methods for the ciphers used/use some broken KDF, and it doesn't offer AEAD modes.

See if you can use libsodium.js instead. Alternatively, there's the Web Crypto API. Unfortunately, I know nothing about JavaScript.

Then use it as AES256 key

I presume you're currently using AES-CBC (the default for CryptoJS). It needs to be paired with HMAC-SHA-256 or HMAC-SHA-512 to be secure.

If you switch to a better library, you should just use an AEAD mode like AES-GCM or ChaCha20-Poly1305. You then don't need to apply HMAC because they authenticate the inputs for you. Importantly, with most AEAD modes, you should use a counter nonce (number used once), meaning you increment it after each encryption operation with the same key.

should I use the IV as a key?

No, the IV should only be used as the IV and is a different size to the key. The Argon2 output should be used as the key.

along with a random IV

With AES-CBC, the IV should indeed be random and unpredictable for each encryption operation. It should not be reused with the same key. You can prepend it to the ciphertext output.

Improve this answer
$\endgroup$
5
  • 1
    $\begingroup$ CBC requires not only random also unpredictable in network communications. $\endgroup$
    – kelalaka
    Aug 17, 2022 at 18:54
  • $\begingroup$ I originally wrote that but dumbed it down because random via a CSPRNG is unpredictable. I will add it back. $\endgroup$
    – samuel-lucas6
    Aug 17, 2022 at 19:37
  • $\begingroup$ I'm not sure a counter nonce is a good suggestion. In many cases there is no good way to keep the state of the counter. And e.g. AES-GCM leaks the key if you accidentally re-use that nonce. $\endgroup$
    – Elias
    Aug 18, 2022 at 10:40
  • $\begingroup$ @Elias It's not sensible to use a random 96-bit nonce either unless you're rotating the key frequently. $\endgroup$
    – samuel-lucas6
    Aug 18, 2022 at 14:31
  • 1
    $\begingroup$ Agreed, just wanted to point out the danger. For a counter it's not being able to keep the state properly for random nonces it's not having good randomness or too few bits. $\endgroup$
    – Elias
    Aug 23, 2022 at 7:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.