Let this be a reminder that physical security is a necessary precursor to computer security. And I also hope that Exmo's succession plan executor takes the precaution of staying up late tonight to move all their reserves to new wallets.
If the whole idea of a kneecap-breaking plot fails because transferring the funds requires multiple signers then they arent going to break kneecaps
One of the keys could be controlled by a law office on the other side of the planet with contractual obligations to only sign the hot-wallet-refill transaction with a certain amount when the hot wallet falls below a certain amount and when the exchange requests it. The cold-wallet that they're funding from could itself be funded by a timelocked transaction to guarantee that the cold-wallet isn't emptied out too fast, and an entirely different set of law offices that the exchange doesn't regularly contact control the keys that allow the cold-wallet to be emptied out faster. If the different types of on-chain controls like timelocked transactions aren't enough, then some of the keys could be in tamper-proof hardware-security-modules that further restrict how the keys can be used.
2 of 2, 3 of 5, 7 of 10, etc...
Also, it's a fairly well-known system, so I don't see it being collectively "forgotten" on the timescale of a few decades (it's been around since the late 70's i believe).
I'd love to get it integrated into wallet software, as it's such a safe and reliable way of storing secrets that lets you be as "secure" or as "reliable" as you want with just a slider.
Rather you have a private key p of n bytes. Create two cryptographically random keys k1 and k2 of n bytes each. Derive a key k3=(p XOR k1) XOR k2. k1, k2 and k3 are your distributed keys. To recompute p you need to do p = (k3 XOR k2) XOR k1.
A XOR is trivial to implement and I would expect be reasonably robust.
For me, my biggest threat is loss, followed by theft, so it makes sense to have some redundancy even if it means reducing the security against theft.