5

I think I need to use a MAC for ensuring the integrity of a URL that my system will provide to an end user that will use it to download a content from another component of the system, i.e., an URL has to go from one component of my system to another component using the end user as a non-secure channel.

I had thought to use something like AES256(shared_key, MD5 (URL)), i.e., using the output of the MD5(URL) will be 16 bytes that will the input for the AES256, i.e., just one block encryption.

The point is that the key will not be changeb a lot, i.e., lots of MACs will be generated using the same key so and I am not sure if this method is secure on existencial forgery, because, using the same key multiple with AES is not CPA secure.

Please could anybody help on this?

Update: Thanks very much for the responses

I forgot to mention that in some way I am enforced to use that approach.

However I am a little bit upset with the fact of generating MACs using the same key, I mean, AES with a single block is not CPA secure if the same key is used and I am not sure how this impacts the security of the MAC using the approach that I have described.

Thanks in advance

saturn
  • 51
  • 1
  • 3

3 Answers3

4

If you really need to use AES, then you may use CBC-MAC. Be wary, though, of the conditions: CBC-MAC is secure only if:

  • all messages have the same length, or (alternatively) you always compute the MAC over a structure which begins with a header which defines the message length;
  • you never use the key for anything else than CBC-MAC (and, in particular, you don't encrypt anything with the same key).

If you are already ready to use a hash function, then you will find it simpler to rely on HMAC. HMAC uses only a hash function, not a block cipher, so it is less complex than combining a block cipher and a hash function. HMAC is already implemented in many cryptographic frameworks (as usual, the less crypto code you have to write yourself, the better you get). HMAC/MD5 is, as far as we know, secure, despite the known weaknesses of MD5. However, if only for public relations, you might want to use HMAC/SHA-1 or HMAC/SHA-256. You can also truncate the HMAC output: this is known to be safe, i.e. if you truncate the output of HMAC/SHA-256 to, say, 80 bits, then you get a good 80-bit MAC, that the attacker won't be able to bypass with probability higher than 2-80 (and that's already complete overkill for most purposes).

Thomas Pornin
  • 322,884
  • 58
  • 787
  • 955
  • I thought that CBC-MAC seems to be more difficult to implement (http://blog.cryptographyengineering.com/search?q=CBC-MAC). I thought that using MD5 + AES single block (No IV) would be easier. – saturn Oct 29 '13 at 05:17
  • In fact your proposal is equivalent to using CBC-MAC on a "message" which is the MD5 output; this is weak against chosen-plaintext attacks because MD5 is not collision-resistant. HMAC/MD5 is stronger (no known practical attack) _and_ easier (only one cryptographic algorithm to use instead of two, and already implemented in many frameworks). – Thomas Pornin Oct 29 '13 at 10:31
  • Thanks for the point. I know that there have been found some collisions for MD5 but you have to take into account that the possible collision should meet some format, in my case, a URL format. – saturn Oct 29 '13 at 13:13
0

The normal algorithm to use for this is HMAC. You can base a HMAC on any hash algorithm; HMAC-MD5, HMAC-SHA1, whatever you want to use. Calculating an HMAC involves a double application of the hash function, and some other operations. Wikipedia: HMAC

I can't think of any practical attack against the scheme you propose. However, it's possible there is some subtle attack - be it existential forgery or something else. That's why you are well advised to use the standard approach.

paj28
  • 32,906
  • 8
  • 93
  • 130
  • Please, could you elaborate a bit more about the subtle attacks? – saturn Oct 29 '13 at 05:08
  • Sorry, I don't know any specifics. I'm just speculating that there's a risk of subtle attacks, because you're doing something non-standard. – paj28 Oct 29 '13 at 11:16
  • if an IV is used, I can tell you the approach is totally insecure, i.e, IV must not used. – saturn Oct 29 '13 at 14:01
0

Your method is flawed because repeated URL will have same cipher text.

All you have to do is salt the key.

Generate a random salt. XOR it with the SECRET_KEY. Use that result as the encryption key for AES.

Send the SALT and cipher text.

Reciever systems XOR's the recieved SALT with the SECRET_KEY (preshared) and uses that key to decode the cipher text.

No attack is possible because: Salt is just random number. Cipher text will be different with every salt, reguardless of plain text content.

secotmundi
  • 1
  • The method that i have described in not CPA secure for encryption but I am using it for MACing and that is different. My point is that I am not sure the implications of not being CPA secure with the existential forgery attack. – saturn Oct 29 '13 at 07:10