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

Improve this question
$\endgroup$
2
  • $\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
    Commented Feb 5, 2020 at 18:16
  • $\begingroup$ yes thats true. so should i use PBKDF2 or hmac to hash and why $\endgroup$
    – Santhosh
    Commented Feb 5, 2020 at 18:26

1 Answer 1

Reset to default
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$
5
  • $\begingroup$ although timing information is always a bit dangerous due to precision and reset issues what do you mean by this $\endgroup$
    – Santhosh
    Commented Feb 6, 2020 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
    Commented Feb 6, 2020 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 ♦
    Commented Feb 6, 2020 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
    Commented Feb 6, 2020 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 ♦
    Commented Feb 6, 2020 at 5:01

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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