Return to Answer

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need an integrity check, which HMAC can provide. Search for Authenticated Encryption for more details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built into the algorithm.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with different a iteration count (say 20000). What's interesting about this approach is you could use the key derived for HMAC to authenticate the user, i.e. if the HMAC check fails, don't try decrypting the ciphertext - just return an error stating password was wrong. Although a simplification, this is how password managers work in a nutshell - same password is used for authentication as well as encryption.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need an integrity check, which HMAC can provide. Look up Authenticated Encryption for details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built-in.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with a different iteration count (say 20000). What's interesting about this approach is you could use the key derived for HMAC to authenticate the user, i.e. if the HMAC check fails, don't try decrypting the ciphertext - just return an error stating password was wrong. Although a simplification, this is how password managers work in a nutshell - same password is used for authentication as well as encryption.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need integrity check, which HMAC can provide. Search for Authenticated Encryption for more details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built into the algorithm.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with different a iteration count (say 20000). What's interesting about this approach is you could use the key derived for HMAC to authenticate the user, i.e. if the HMAC check fails, don't try decrypting the ciphertext - just return an error stating password was wrong.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need an integrity check, which HMAC can provide. Search for Authenticated Encryption for more details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built into the algorithm.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with different a iteration count (say 20000). What's interesting about this approach is you could use the key derived for HMAC to authenticate the user, i.e. if the HMAC check fails, don't try decrypting the ciphertext - just return an error stating password was wrong. Although a simplification, this is how password managers work in a nutshell - same password is used for authentication as well as encryption.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need integrity check, which HMAC can provide. Search for Authenticated Encryption for more details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built into the algorithm.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with different a iteration count (say 20000). It is standard practice to use the same password for both authentication and encryption, generating different keys using different PBKDF2 iteration counts. The iterations for authentication should be high (see below about brute force attacks), while iterations for encryption key are typically much lower. For example, LastPass uses 100000 for authentication, and 5000 for encryption.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.

Now my main question is, HMAC seems redundant, but seems like the only good way to check that the key is valid, otherwise a hash of the plain text data would need to be compared which would be very easy to reverse engineer / brute force.

HMAC is important. AES CTR encryption gives you confidentiality. But that is not enough. You also need integrity check, which HMAC can provide. Search for Authenticated Encryption for more details.

Getting the implementation right can be tricky so I recommend using AES GCM, which has the integrity check built into the algorithm.

But since you're rolling your own integrity check...

Also, do I really need two separate keys for AES and HMAC?

Yes, but easy to do. Churn the same password through PBKDF2 but with different a iteration count (say 20000). What's interesting about this approach is you could use the key derived for HMAC to authenticate the user, i.e. if the HMAC check fails, don't try decrypting the ciphertext - just return an error stating password was wrong.

Lastly, does PBKDF2 really help?

Yes, to mitigate against brute force attacks by:

1. Intentionally making PBKDF2 an expensive operation, especially with higher iterations.
2. Expanding the password to take up the entire 128 or 256 bit space of AES. Otherwise you'd need ridiculously long passwords.