1
$\begingroup$

I have a 128 bit Pre-Shared Key. I don't want to use it directly. I'd much rather generated a session key with HKDF(PSK, SALT) = SESSIONKEY.

I'm however under strict size limits for packet size. So I'm looking at the option of a 12 byte (96 bit) salt.

Does this significantly weaken my 128 bit PSK down to 96 bit? What is the true complexity of the resulting SESSIONKEY? I don't think I get to combine them into something greater than 128bit because the salt (derivation seed) will be transmitted in the clear for the other side to use.

Improve this question
$\endgroup$
0
2
$\begingroup$

Does this significantly weaken my 128 bit PSK down to 96 bit? What is the true complexity of the resulting SESSIONKEY?

No it doesn't, key strength remains the same. It's remains at 128 bits. HKDF can even be run without a salt (although it's security proof strongly recommends you to use one).

However, if you use it many times, you might have a higher chance that a SESSIONKEY repeats. How that impacts security depends on the cipher mode and IV usage though:

  • If you use a 16 byte random IV and you'd use, say, AES-EAX then you'd still be as secure. If you'd use deterministic encryption and the each message differs then you'd still be as secure.

  • If the IV is static and you'd be using GCM then you're more likely to be in trouble and all security may be lost.

So the nasty answer is that we cannot really tell, it depends on the use case and threat vectors.

Improve this answer
$\endgroup$
0
$\begingroup$

Does this significantly weaken my 128 bit PSK down to 96 bit? What is the true complexity of the resulting SESSIONKEY?

Even though it doesn't compromise the security of the SESSIONKEY(depending upon the implementation). There are some better ways to generate derived keys. You can take a cue from the ETSI architecture. Please refer to the Key ladder function diagram Figure 1 and page 9 of the below link.

https://www.etsi.org/deliver/etsi_ts/103100_103199/103162/01.01.01_60/ts_103162v010101p.pdf

Improve this answer
$\endgroup$
3
  • $\begingroup$ A generic pointer to a document does not constitute an answer on this site. That document is very use-case specific. Please describe the algorithm, how it relates to the question and how it is better than HKDF with a relatively small salt size. $\endgroup$ – Maarten Bodewes♦ Feb 25 '20 at 12:53
  • $\begingroup$ thanks for the comment. My idea would be to derive a key using key ladder concept. Where both the pre-shared key and salt can be used to derive a key. I will try to post a block diagram which will be in the continuation of this answer. Please let me know if still doesn't match with the answer. $\endgroup$ – Vikash Feb 27 '20 at 8:54
  • $\begingroup$ Please do not use two answer boxes for the same answer, you can simply edit your other answer into this one. $\endgroup$ – Maarten Bodewes♦ Feb 27 '20 at 11:14
0
$\begingroup$

In the continuation of the comment, please find the block diagram where I am mentioning another way of key derivation through a sort of key ladder mechanism. enter image description here

Improve this answer
$\endgroup$
1
  • $\begingroup$ I didn't elaborate this on my initial post. But I said I have size constraints for the packet. In my case I'm on embedded and each crypto operation is expensive. Here, instead of one HKDF you have two AES ops with what appears to be your alternative to an established and recognized KDF. $\endgroup$ – mint branch conditioner Feb 27 '20 at 19:05

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.