1
$\begingroup$

I have read about hmac and PBKDF2.

PBKDF2 - is mainly used for password hashing. It uses hmac and iterates.

I want to hash some sensitive data and send in the response of a request.

Later that hashed sensitive data will be send back with some form data.

So in my case is it safe to use PBKDF2 as hashing tool - to hash any thing like (timestamp+sensitive_info+extra_info) with a SECRET_KEY just similar to hmac

$\endgroup$
  • $\begingroup$ PBKDF2 - its purpose may be for salt-hasing password. But in principle can this be also used like hmac -- i.e as either keyed-hash message authentication code or hash-based message authentication code $\endgroup$ – Santhosh Yedidi Feb 5 at 18:16
  • $\begingroup$ yes thats true. so should i use PBKDF2 or hmac to hash and why $\endgroup$ – Santhosh Yedidi Feb 5 at 18:26
3
$\begingroup$

So in my case is it safe to use PBKDF2 as hashing tool - to hash any thing like (timestamp+sensitive_info+extra_info) with a SECRET_KEY just similar to hmac?

The reason that a Password Based Key Derivation Function or password hash is used is because passwords are generally not considered secure enough. The iterations or work factor of such a PBKDF makes it harder for attackers to use dictionary attacks and the like to retrieve the password value and any derived key from it.

However, if you already have a secure secret key then there is no need to perform PBKDF2. It doesn't depend on the sensitivity of the protected data at all. So if you have a secret key and you just need integrity and authenticity, then you can just use a normal MAC - such as HMAC. If you also need confidentiality then an authenticated cipher such as GCM makes more sense.

Beware that HMAC doesn't have a salt; you may need a nonce or IV value to make your message / ciphertext secure (but this depends on the threat model for your particular use case). If you use a timestamp then this may be part of providing message uniqueness (although timing information is always a bit dangerous due to precision and reset issues).

|improve this answer|||||
$\endgroup$
  • $\begingroup$ although timing information is always a bit dangerous due to precision and reset issues what do you mean by this $\endgroup$ – Santhosh Yedidi Feb 6 at 4:07
  • $\begingroup$ So can you suggest the final code in my case using hmac, secret key and a sensitive data (in my case its always a 6 digit number) which will be secure from ciphertext and any other $\endgroup$ – Santhosh Yedidi Feb 6 at 4:14
  • $\begingroup$ As long as you can canonically encode your data to bytes (so that the fields can be told apart) then you can perform a HMAC over it. Um, what's there to tell? $\endgroup$ – Maarten Bodewes Feb 6 at 4:29
  • $\begingroup$ So if I encode my data like msg ='timestamp+sensitive_info+extra_info'.encode('utf-8) then will the precision and reset issues will be avoided $\endgroup$ – Santhosh Yedidi Feb 6 at 4:39
  • $\begingroup$ The precision and reset issues are specific to the time stamp. They are not avoided by encoding the timestamp. How you encode the fields doesn't matter, as long as you can tell the fields apart. If at least two of the fields have a static size then that should be easy and simple concatenation (of the strings or the byte arrays) should work. $\endgroup$ – Maarten Bodewes Feb 6 at 5:01

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.