Centralize Root Key Generation on Nexus

[v0lkan]

Reasoning:

• Nexus already had to know the root key; so let it shard it and give it to keepers.
• It will make keepers simple, and less attractive targets for adverseries.
• At no single time (including bootstrapping) compromising a single keeper will be enough to compromise the root key.

Details:

As in anything this decision brings different benefits and liabilitites. The biggest liability is SPIKE Nexus will be a yummier target for the adversaries (if it's not already) and since it will have the responsibility to help keepers keep their shares, that means slightly more performance requirements on Nexus)

Distributed Model:

• Keeper Operations: Keepers temporarily reconstruct the root key during specific operations, increasing the number of instances where the root key exists in memory across the system.
• Attack Surface: This approach potentially broadens the attack surface, as compromising any Keeper during key generation operations could expose the root key. — It's worth noting that it's a highly sophisticated attack vector, and very unlikely to succeed without root access on the keeper and without to-the-nanosecond timing, and without sophisticated memory forensic tools. But stiill it is a theoretical possibililty. — Whereas in the centralized model, keepers are dummy value keepers and they are not as "high value" targets.
  -- Since SPIKE Nexus is a "high value target" already, it's better to harden it further, rather than putting the same level of protection on keepers too. -- Of course, in an ideal world everything can be protected perfectly. But, also, misconfigurations do happen. And even an entire keeper is misconfigured and it broadcasts its share to the entire world, it is not enough to take the system down. -- that is, in this scenario we put more trust and security on Nexus than keepers.

Centralized Model:

• Nexus Operations: The Nexus is solely responsible for key management, including the generation, storage, and utilization of the root key.
• Attack Surface: While the Nexus remains a prime target, the centralized model confines the exposure of the root key to a single, well-protected entity, potentially reducing the overall attack surface. — Besides, Nexus already is a prime target (since it has to use the root key, and hence keep the root key in its memory), so nothing has changed there.

Considerations:

• Security Measures: In both models, implementing robust security protocols for the Nexus is imperative, given its critical role in key management.
• Operational Complexity: The centralized model may simplify operations by reducing the number of entities involved in key reconstruction, thereby decreasing the potential points of failure or compromise.

---

Transitioning to a centralized key management model, where the Nexus exclusively handles key operations, could reduce the overall attack surface by limiting the exposure of the root key to a single, fortified entity. However, this necessitates ensuring that the Nexus is exceptionally secure and resilient to potential attacks.

• Nexus as a Critical Component: In both models, the Nexus is a high-value target due to its access to the root key.
• Attack Surface Dynamics: The centralized model may reduce the overall attack surface by limiting root key exposure to the Nexus, whereas the distributed model increases exposure through multiple Keepers.
• Security Imperatives: Regardless of the model, implementing stringent security measures for the Nexus is essential to safeguard the system's integrity.