# Tag Info

1

[D]oes adding HMAC to each encrypted field and validating it before decryption makes sense? No. Since you authenticate the data once, you can trust that it is the same as was originally encrypted and authenticated. That is, authenticating the ciphertext also authenticates the plaintext. The goal is to make make the app as secure as possible and ...

2

It is not secure in general, but not insecure in general either. For example, you can get a MAC algorithm for which it would be secure by concatenating constant data to a secure MAC. $Tag_k(m) = M_k(m)||0^n$ is a secure MAC if $M$ is. And clearly taking the first half of that is a secure MAC if $n = |M_k(m)|$. On the other hand, reverse the order of the ...

1

So the idea is to use the IV of MD5 as a key to create a MAC. Like CodesInChaos mentions in a comment, it would be pretty much equivalent to using $H(k||m)$, if your IV is randomly chosen. By only using it on fixed length messages you avoid the length extension attack, but that is not the only attack on hash constructions that try to create a MAC. In this ...

0

An IV is not a key. In modes of operation, an IV does not have to be kept secret, and in order to decrypt everything you need the IV, which is transmitted in the clear. The only required property of an IV is that it is unique, or at least with overwhelming probability unique. For that you can use "bad" randomness to create it (e.g. from a non-secure PRNG). ...

0

As mentioned by SEJPM in the comments, four bytes is much too short for an HMAC key. Since KEY_SECRET is already in place, you could just use it directly as a MAC key, but then you need to make sure that DATA cannot collide with any counter value. You could do this by prefixing DATA with enough constant values to make it longer than the counter. For ...

Top 50 recent answers are included