1

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.

The Quantum Physicist
  • 211
  • 1
  • 10

1 Answers1

1

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).

Woodstock
  • 1,384
  • 1
  • 13
  • 23
  • 1
    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. – The Quantum Physicist Nov 23 '19 at 20:01
  • @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). – Woodstock Nov 23 '19 at 20:49
  • 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? – Squeamish Ossifrage Nov 23 '19 at 22:05
  • As a theoretic point: there is a loss of entropy in the key hashing, of about 0.827 bit, see this. – fgrieu Nov 24 '19 at 08:10
  • 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 :-) – The Quantum Physicist Nov 24 '19 at 09:20
  • @Squeamish Ossifrage, you execute another DH so that each message can be encrypted with a new symmetric key. So that if any private key is compromised you only reveal the a single message not the entire history. – Woodstock Nov 24 '19 at 09:30
  • @SqueamishOssifrage pls do let me know if Im missing something here, I thought multiple ephem/ephem ECDH exchanges were the fundamental approach used to achieve PFS? – Woodstock Nov 24 '19 at 09:59
  • @Woodstock I recommend avoiding the term ‘(perfect) forward secrecy’ because it's confusing and the loaded word ‘perfect’ doesn't add anything. Instead, I recommend saying when keys can be erased. In this case, ratcheting the key with a KDF after every message lets you erase the old key after every message. So does doing a fresh DH key agreement, but the ratchet is a lot cheaper. – Squeamish Ossifrage Nov 24 '19 at 16:27
  • @SqueamishOssifrage I agree but when ratcheting the symmetric key, if a prior key is broken, one can break future keys. With Ephem/Ephem ECDH, the keys are unrelated. I take your point regarding forward secrecy. I am correct in my understanding that in some systems ECDH is performed on a per message sent basis? – Woodstock Nov 24 '19 at 20:47
  • @Woodstock Suppose you generate the DH secrets from the same PRNG in memory. It's a little hard to imagine that an adversary could find the old DH secret—you must have failed to erase it and the adversary must have a memory disclosure attack—but not the old PRNG state or the new DH secret or the new PRNG state. If there is a compelling security boundary making this scenario plausible, then perhaps injecting fresh key material with a new DH key agreement would thwart such an adversary, but it's not a threat model that's usually worth worrying about. – Squeamish Ossifrage Nov 24 '19 at 23:03
  • @Woodstock Which systems did you have in mind concerning DH per message? There's, say, DNSCurve, but that uses static/static DH and caches the shared secrets to save the cost of recomputing them. There's Signal, but that only does DH infrequently; instead it does a KDF ratchet per message. – Squeamish Ossifrage Nov 24 '19 at 23:04
  • @SqueamishOssifrage, so the context is an enterprise, private app, where band width and computational effort are not concern but P2P privacy is. So in this context doesn't Ephem/Ephem ECDH per message provide the highest level of security? – Woodstock Nov 25 '19 at 09:33
  • @Woodstock Bandwidth and computational effort may well be a concern in ‘enterprise’ applications where things are done at scale. What's important is whether there is a meaningful security boundary between the old and new state. For example, if you've just transitioned to a new device, then sure, it may be worthwhile to do a fresh DH key agreement in case the old device is lost and the key erasure didn't work as well as you'd hoped. But on every message? A priori there's no compelling reason there. – Squeamish Ossifrage Nov 25 '19 at 13:44