1
$\begingroup$

I'm using xsalsa20poly1305 for encryption in my program from libsodium. The recommended size for chunks is 4 kB. In that case, poly1305 will have authentication only for the the individual 4k chunks. Not the whole message.

I would like to authenticate the whole message again with poly1305 or HMAC-SHA256 or whatever. It's well known that reusing the same key for encryption and authentication is a bad idea. Please correct me if I'm wrong there.

My question is: Is it OK to calculate SHA-256 or SHA-512 of my current key and use it as the key for authentication (in an open-source project where everyone will know the algorithm I'm using)?

Please note that in my application, it's absolutely not possible to have more than one symmetric key, because that key is derived from ECDH.

$\endgroup$

1 Answer 1

1
$\begingroup$

Yes this is "OK".

Please correct me if I'm wrong there.

You are correct.

It's effectively ratcheting the original key.

However there may be a more elegant solution such as using static keys for auth and ephemeral keys for key agreement (i.e. use Ephemeral-Ephemeral Diffie-Hellman for each new message).

$\endgroup$
13
  • 1
    $\begingroup$ Let me try to guess what "ephemeral-ephemeral" means. Besides my original key pair A, which I ECDH'ed with the other party's key pair B to create our symmetric key, I do another ECDHE to create a new symmetric key between a new public/private key pair C and B? If my guess is right, the cost of this is that I'll have to share the new public key as well. That's the only drawback I'm seeing. $\endgroup$ Commented Nov 23, 2019 at 20:01
  • $\begingroup$ @Quantum yup. You got it. It’s a fresh pub/priv pair every message/whatever. The cost is distribution of the public keys. But it provides Perfect Forward Secrecy. (Each message is discretely protected). $\endgroup$
    – Woodstock
    Commented Nov 23, 2019 at 20:49
  • $\begingroup$ Why would you want to pay the cost of another DH public-key operation for every message after you've already established an ephemeral shared secret? $\endgroup$ Commented Nov 23, 2019 at 22:05
  • $\begingroup$ As a theoretic point: there is a loss of entropy in the key hashing, of about 0.827 bit, see this. $\endgroup$
    – fgrieu
    Commented Nov 24, 2019 at 8:10
  • $\begingroup$ Just to be clear, I'm already using ECDHE to get the first key, A. So I personally find it an overkill to do another ECDHE just for the authentication, especially that I'm in an application where storage size matters. However, I appreciate the idea that I can do that. It really didn't occur to me :-) $\endgroup$ Commented Nov 24, 2019 at 9:20

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.