Timeline for Is it OK to just hash a symmetric key to derive an authentication key?
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 25, 2019 at 13:44 | comment | added | Squeamish Ossifrage | @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. | |
| Nov 25, 2019 at 9:33 | comment | added | Woodstock | @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? | |
| Nov 24, 2019 at 23:04 | comment | added | Squeamish Ossifrage | @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. | |
| Nov 24, 2019 at 23:03 | comment | added | Squeamish Ossifrage | @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. | |
| Nov 24, 2019 at 20:47 | comment | added | Woodstock | @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? | |
| Nov 24, 2019 at 16:27 | comment | added | Squeamish Ossifrage | @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. | |
| Nov 24, 2019 at 9:59 | comment | added | Woodstock | @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? | |
| Nov 24, 2019 at 9:30 | comment | added | Woodstock | @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. | |
| Nov 24, 2019 at 9:20 | comment | added | The Quantum Physicist | 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 :-) | |
| Nov 24, 2019 at 8:10 | comment | added | fgrieu♦ | As a theoretic point: there is a loss of entropy in the key hashing, of about 0.827 bit, see this. | |
| Nov 23, 2019 at 22:05 | comment | added | Squeamish Ossifrage | 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? | |
| Nov 23, 2019 at 20:49 | comment | added | Woodstock | @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). | |
| Nov 23, 2019 at 20:01 | vote | accept | The Quantum Physicist | ||
| Nov 23, 2019 at 20:01 | comment | added | The Quantum Physicist | 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. | |
| Nov 23, 2019 at 19:22 | history | answered | Woodstock | CC BY-SA 4.0 |