4

I was wondering if there were any security implications of deriving session keys from a symmetric key using SHA256 in the following manner: $Ks = SHA256(Nonce||K)$, where $Nonce$ is the session specific nonce and $K$ is the pre-shared symmetric key. And $Ks$ will be derived at both ends as mentioned.

As far as I am aware, length extension attacks are not applicable here as being able to append additional data to the input makes no difference. Would $Ks = HMAC(Nonce, K)$ be any different security-wise? What would be an advisable way of going about my requirement?

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Balthazar2012
  • 87
  • 4

1 Answers1

2

HMAC: The version is considered slightly more secure than , assuming it's also based on SHA-256, because the HMAC formulation folds in the key material with 2 rounds of hashing, making it harder to use a chosen plaintext attack on the digest.

SHA-256: SHA-256 should be relatively secure against chosen plaintext attacks, but it's better to be safe than sorry.

You can also achieve a higher level of assurance and forward security provided $K$ is not long-lived, but rather is chained to the immediately previous session.

For some stored value D1:

K2 = HMAC(Nonce,D1)     // session key
D2 = HMAC(Nonce,K2)     // stored material for a future session
authtoken = E(K2,Nonce) // auth token proving client derived K2 correctly

If you want to authenticate the server, you can also pass a token from server to client, thus proving the server knows D1. Something like, 

servtoken = E(K2,authtoken)   // proof server knows D1

Client checks servtoken before sending authtoken. D1 is discarded and replaced with D2. So you have bidirectional authentication and forward security.

e-sushi
  • 17,891
  • 12
  • 83
  • 229
Jeff-Inventor ChromeOS
  • 277
  • 1
  • 8