in a project that I am working on we have been tasked with eliminating PGP while providing sufficient security to protect payment files only within the Company's trusted network. We arrived at HMAC SHA256. Assuming that we can keep the key private and refresh the (128 bit) key annually, can someone comment on how difficult it would be to compute the key if an attacker got the plaintext and the hash? The files on average are about 2mb in size.


With regards to the algorithm, HMAC-SHA256 is considered very secure. As with most symmetric algorithms it can probably not be proven secure, but that should not worry you overmuch.

The most important security consideration with HMAC is to use a time consistent compare when verifying the authentication tag. A 256 bit key could be considered for the simple reason that the overhead won't make any difference when ~2MB files are being protected.

It's probably better to focus on other parts of the system security and make sure you implement the key management well.

  • $\begingroup$ Maarten, thanks very much for the reply! I'm not going to pretend to know what a time consistent compare is - my understanding was that the endpoint in our private network that would be authenticating the HMAC hash would (of course) have the same private key and would recompute the HMAC SHA256 hash and then compare newly computed hash to original hash. Is this not correct or am I missing something? $\endgroup$ – Jim-Marshall Apr 20 '15 at 22:49
  • $\begingroup$ No, although you normally talk about secret keys instead of private keys for symmetric algorithms. That last compare should be consistent in time, i.e. the compare should not stop at the first bit/byte that is different. Usually that should be taken care of by a verify function in the API, but please check. $\endgroup$ – Maarten Bodewes Apr 20 '15 at 23:13
  • $\begingroup$ Thanks again Mararten - I should have said secret key and not private key. In your opinion, if I have a 256 bit secret key created with a PRF, and I create an HMAC on a 2mb file and then the file and computed SHA256 HMAC are comprimised, how long should I expect (without the use of quantum computing) my key to remain uncomprimised? $\endgroup$ – Jim-Marshall Apr 21 '15 at 0:04
  • $\begingroup$ The timing attacks are on the HMAC value itself, not on the key. The key can only be found by reversing the hash, which should be impossible. It could be that some side channel attacks are able to find the key value by studying the initial rounds of the hash, but as the running doesn't depend on the values of the bits much, that would be a pretty good trick to pull off. $\endgroup$ – Maarten Bodewes Apr 21 '15 at 0:22
  • 1
    $\begingroup$ if the comparison leaks timing information, an attacker could brute-force one byte at a time to get a correct HMAC for any message with ~4096 (at most 8192) requests. $\endgroup$ – lily wilson Jun 17 '15 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.