3 ms·
I think in the long term, we'll move away from relying on one algorithm only, like AES or DHKE, but combine them. So for key exchange we will use DH plus ECDH p
by est31 6y ago
I think in the long term, we'll move away from relying on one algorithm only, like AES or DHKE, but combine them. So for key exchange we will use DH plus ECDH plus whatever comes out of the post quantum NIST competition, and use all three as inputs for both parties to a KDF to produce the derived key. Attacks against any one of the algorithms won't turn into feasible attacks onto all of them.
- arberavdullahu 6y agoCombining two algorithms is very hard and when it does it can become insecure(new attacks can be found). Even if you can combine and its secure then it becomes infeasible to use it often as the length of keys, IV, etc. increases
- est31 6y agoI didn't mean deep combination that changes how an algorithm works internally. Of course that would be a stupid idea. The algorithms would still work the same, would use separate random numbers, etc. You'd just combine them at the integration level, treating each algorithm like a black box. Think of two servers first doing DH and then doing ECDH. You'd get two shared keys. This is inefficient because it has more roundtrips than doing the algorithm's steps in parallel, but helps with understanding. These two secrets can then serve as inputs to your KDF which derives multiple secrets for each of the data ciphers you use. E.g. first AES with the first secret then encrypt that with ChaCha20 with the second secret. As long as your KDF is preimage resistant, you can't get from one algo to another. And yes, length of keys and computation do increase. But I argue that this will be a cost worth paying at least in some scenarios. Especially in a time we make our CPUs slower by double digit percentages for all computation in the name of security.