New answers tagged

3

The strength here depends on the collision resistance of $H$. If $H$ is not collision resistant, like MD5, then the attacker can find $H(m) = H(m')$, ask for the MAC of one message and forge it for the other. So for many secure hashes you lose half the security bits. E.g. SHA-256 should give you a 256-bit secure HMAC, but would be at most 128-bit secure in ...


3

Should be comparable in strength to $H(m||k)$. The weakness is that a collision in the inner hash breaks the MAC. Using strong hashes the strength in bits is $\min(2^{n_O},2^{{n_I}/2})$ where $n_O$ is the output size of the outer hash and $n_I$ the output size of the inner hash. But since cryptoanalysis usually breaks collision resistance long before it ...


3

"Given the above assumptions and limitations, is the encryption scheme still secure?" No; the attacker can remove blocks of [IV + rest_of_ciphertext] from either end to remove corresponding plaintext blocks without affecting any other part of what it decrypts to change the IV to change the initial plaintext block in the same way as for the OTP, without ...


4

Short answer: 32 bytes of full-entropy key is enough. Assuming full-entropy key (that is, each bit of key is chosen independently of the others by an equivalent of fair coin toss), the security of HMAC-SHA-256 against brute force key search is defined by the key size up to 64 bytes (512 bits) of key, then abruptly drops to 32 bytes (256 bits) for larger ...


0

You can use CCM or EAX mode. EAX mode is not standardized by NIST, but it uses AES + AES-CMAC as underlying primitive, implementing a secure authentication mode. You could use AES-CMAC (or EAX mode without any ciphertext and just Additional Authenticated Data) to calculate an authentication tag over the authentication tags of the blocks. Advantage of EAX ...


0

To answer your ideas of: "I use hash-then-encrypt" with CBC + SHA-1 "I use MAC-then-encrypt" with CBC + HMAC "I won't use GCM because of unclear usage guidance" First, hash-then-encrypt is a really bad idea. You really should avoid it if possible. Details are explained in this related question on Crypto.SE. Second, MAC-then-encrypt is a concept you also ...


3

Would these steps result in a suitable pair of keys for AES-encrypt-then-HMAC-authenticate? Yes. That would be fine. It almost is HKDF-Expand, in fact. However, as you note, by deriving the two 256-bit keys from a 160-bit key your effective security will "only" be 160 bits, since an attacker could brute force the intermediate key. That is not at all a ...


4

See NIST SP 800-107, section 5.3.4: The effective security strength of the HMAC key is the minimum of the security strength of $K$ and the value of $2C$. That is, security strength = min(security strength of $K$, $2C$). For example, if the security strength of $K$ is 128 bits, and SHA-1 is used, then the effective security strength of the HMAC key is 128 ...


0

You might want to call out to libsodium instead. It provides password hashing and authenticated encryption built-in, with a very clean API that is easy to use correctly, as long as you remember to choose a fresh nonce every time you encrypt. It will also be faster than AES+HMAC, and uses Argon2 for password hashing, the winner of the Password Hashing ...


3

PBKDF2 alone would be bad for step 4, since the blocks of its output can trivially be computed independently. ‚Äč If the PBKDF you use can't directly produce enough output, then you should compose with a fast key-based KDF. Make sure that the IV is part of step 9's ciphertext and step 5 of decryption is constant-time .



Top 50 recent answers are included