[Design] Catastrophic enclave failure - Encrypted data recovery #1737
Conversation
WalkthroughThe recent update introduces a protocol for recovering enclave secrets after a catastrophic failure. It employs RandomX-based encryption keys, detailing key derivation, publishing rollups, and a bruteforcing mechanism for recovery. The document also addresses security concerns, details how to motivate participants in the bruteforcing effort, and explores potential applications for the collected bruteforcing funds. Changes
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (invoked as PR comments)
Additionally, you can add CodeRabbit Configration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Review Status
Actionable comments generated: 2
Configuration used: CodeRabbit UI
Files selected for processing (1)
- design/scratchpad/Design_secret_recovery.md (1 hunks)
Additional comments: 4
design/scratchpad/Design_secret_recovery.md (4)
1-8: The introduction clearly outlines the purpose and high-level approach of the protocol. It sets the context for the reader about the trade-off between privacy and speed of recovery, which is a crucial aspect of the design.
10-12: The section on RandomX is informative and provides a good explanation of why it's chosen for this protocol due to its ASIC resistance and suitability for CPU-based execution.
32-40: The security considerations are well thought out, addressing the randomness of the number within the constrained range and the implications of a state actor with significant resources. It's important to ensure that the assumptions made here are validated with empirical data or expert review.
42-55: The incentivization strategy for bruteforcing is innovative, with a decaying reward structure and the possibility of donations. It's crucial to model the economic incentives and decay rates to ensure they align with the desired outcomes and do not introduce unintended consequences.
| # Algorithm | ||
|
|
||
| The sequencer wants to publish a rollup. It picks a random big number `rollup_encryption_seed`. This number is put in the public rollup header that goes on chain. | ||
| To derive the encryption key, the rollup initializes an instance of `RandomX` hasher. The `rollup_encryption_seed` is fed into the hasher as the key that would generate the random hashing bytecode. | ||
| Once the hasher is initialized, the sequencer needs to derive the `constrained input range` for the hasher. This would be done by using `rollup_encryption_seed` as the input for a `keccak256` hash. The resulting hash can be converted to a `uint256` number. | ||
| The converted number is taken as the central point of the `constrained range`. We derieve the range to be `[hashResult-difficulty:hashResult+difficulty]`. | ||
| Now the sequencer picks another random number in the `constrained range`. This number is hashed with `RandomX`. The result is the `encryption_secret`. | ||
|
|
||
| Now the sequencer can use the `encryption_secret` to derieve an AES256 key and encrypt the rollup. Then its published as it would normally; The header contains the `rollup_encryption_seed` and a keccak256 hash of the `encryption_secret`. | ||
|
|
There was a problem hiding this comment.
The algorithm for publishing rollups and deriving encryption keys is well-explained. However, it would be beneficial to include pseudocode or a flowchart for better clarity, especially for complex operations like deriving the constrained input range.
| ## Bruteforcing | ||
|
|
||
| To bruteforce, we have to take the `rollup_encryption_seed` from the header published on chain and derive the `constrained_range` and `RandomX`. Then we have to go through each possible input in the `constrained_range` and hash it with `RandomX`; The result is then hashed through keccak256 and compared the published hash of the `encryption_secret` in the rollup header. This continues until we score a match. The preimage of the keccak256 we have is the `encryption_secret` for the rollup. | ||
|
|
||
| Bruteforcing can be done in parallel. With a special orchestrator it can be also done in parallel across many machines. There are up to date online benchmarks for all CPUs and their hash rate for `RandomX` with the monero default params, which we can reuse. Based on those benchmarks we can come up with the initial `difficulty` in terms of expected CPU duration to bruteforce and then convert the duration into a dollar cost based on cloud pricing for similair VMs. The cost should be something we can afford if we ever wanted to bruteforce, but it can also be higher and community subsidized. | ||
|
|
There was a problem hiding this comment.
The bruteforcing process is described with enough detail to understand the steps involved. It might be helpful to mention any potential optimizations or parallelization limits to set realistic expectations for the recovery time.
|
For me the biggest problem with this is that the value of the brute-forcing to an attacker is hard to predict. We re-introduce some serious MEV-style exploits. If the value of knowing, for example, a random number outcome in some viral game becomes high and people can pay to discover it then it'll be discovered. If we try to price it super-conservatively then we make it super expensive to recover. And what's more I don't think the network would even know if someone had spent the money to crack it? Whereas with other recovery mechanisms we've talked about it has always been very publicly visible when shenanigans are afoot. Plus, probably negligible given it would be rare and tiny scale compared to BTC etc., but be a shame to burn a ton of CPU CO2 to recover the network. That said, I do appreciate any ideas that can help us decentralise some of the protocol stuff, recovery ideas all seem super centralised at the moment. |
Why this change is needed
Please provide a description and a link to the underlying ticket
What changes were made as part of this PR
Please provide a high level list of the changes made
PR checks pre-merging
Please indicate below by ticking the checkbox that you have read and performed the required
PR checks