New answers tagged

2

No, wrapping the data key set seems a good idea to me. It's pretty standard and should even work with e.g. hardware modules. Note that your old ciphertext would still rely on the security of your old secret (password) when you choose this scheme! If $Enckey$ is ever guessed it can be confirmed by decrypting (the first part of) your ciphertext. There is a ...


1

For full explanation, see Is there a standard for OpenSSL-interoperable AES encryption? . Short answer: what openssl enc (without -K for raw) uses is not PBKDF2; it is almost PBKDF1, with iteration count 1. This imposes almost no cost on attacker trials, so unless your passwords are strong enough to be keys by themselves you should avoid it if you can. In ...


1

OpenSSL uses EVP_BytesToKey, an algorithm proprietary to OpenSSL, with a salt and an iteration count set to 1. The algorithm isn't that insecure; the iteration count of 1 of course is. There are implementations for other languages/runtimes if you look for it. This page (on nabble.com) explains a bit about accessing PBKDF2 from the command line. It also ...


5

HMAC is sometimes called a keyed hash. The key is not part of the input of a secure hash (as CodesInChaos already indicated in the comments). HMAC is a relatively simple construct to allow a key to be used as input to the underlying secure hash. It specifically is constructed to disallow length extension attacks - although those are not likely an issue in ...



Top 50 recent answers are included