fix directory and add en/cn readme
This commit is contained in:
61
en/README.md
Normal file
61
en/README.md
Normal file
@@ -0,0 +1,61 @@
|
||||
# Sentinel Crypt Core
|
||||
|
||||
Sentinel is a cryptographic prototype system for Digital Inheritance. It combines Shamir's Secret Sharing (SSS), AES symmetric encryption, and RSA asymmetric encryption technologies, aiming to solve the problems of secure storage and conditional triggered inheritance of digital assets.
|
||||
|
||||
## Core Features
|
||||
|
||||
1. **Trust Sharding**:
|
||||
* Uses Shamir's Secret Sharing (3-of-2) algorithm to split the user master key (BIP-39 mnemonic) into three shares:
|
||||
* **Device Share**: Stored on the user's device.
|
||||
* **Cloud Share**: Hosted on the Sentinel cloud.
|
||||
* **Physical Share**: Physical inheritance card, kept by the heir.
|
||||
* Any combination of two shares can recover the original key; a single share cannot retrieve any information.
|
||||
|
||||
2. **Vault Layer (Zero-Knowledge)**:
|
||||
* Uses an AES-256 key derived from the mnemonic to encrypt user private data.
|
||||
* Adopts AES-GCM mode to ensure data confidentiality and integrity.
|
||||
* The system cannot decrypt user data without obtaining enough shares (Zero-Knowledge property).
|
||||
|
||||
3. **Gateway Layer**:
|
||||
* Uses an RSA-4096 system public key to re-encrypt (wrap) the user ciphertext.
|
||||
* Implements a "Passive Verification" mechanism: The system uses the private key to strip the outer encryption only after specific trigger conditions are met (e.g., confirmed death or subscription expiration), allowing the heir to attempt recovery.
|
||||
|
||||
## Environment Dependencies
|
||||
|
||||
This project is developed based on Python 3 and depends on the following cryptographic libraries:
|
||||
|
||||
* `pycryptodome`: For AES encryption and PBKDF2 key derivation.
|
||||
* `cryptography`: For RSA encryption and key serialization.
|
||||
* `mnemonic`: For BIP-39 mnemonic generation and processing.
|
||||
|
||||
### Install Dependencies
|
||||
|
||||
```bash
|
||||
pip install pycryptodome cryptography mnemonic
|
||||
```
|
||||
|
||||
## 快速开始
|
||||
|
||||
运行主演示脚本，查看完整的数字遗产传承流程模拟：
|
||||
|
||||
```bash
|
||||
python main_demo.py
|
||||
```
|
||||
|
||||
该脚本将演示以下全流程：
|
||||
1. **初始化**: 生成密钥并进行 SSS 分片。
|
||||
2. **加密**: 用户加密数据，系统进行二次加壳。
|
||||
3. **触发**: 模拟系统判定触发条件，剥离外层加密。
|
||||
4. **恢复**: 演示三种不同的分片组合（如“云端+传承卡”）恢复数据的场景。
|
||||
|
||||
## 项目结构
|
||||
|
||||
* `core/`: 核心加密模块
|
||||
* `sp_trust_sharding.py`: 密钥生成与 Shamir 分片算法实现（基于有限域 $GF(2^{521}-1)$）。
|
||||
* `sp_vault_aes.py`: 用户侧 AES-256-GCM 加密金库实现。
|
||||
* `sp_gateway_rsa.py`: 系统侧 RSA-4096 加密网关实现。
|
||||
* `main_demo.py`: 全流程演示脚本。
|
||||
* `data_flow.md`: 数据流与协议设计的详细文档。
|
||||
|
||||
---
|
||||
*注意：本项目为原型验证代码（PoC），生产环境使用需进一步进行安全审计和密钥管理强化。*
|
||||
49
en/data_flow.md
Normal file
49
en/data_flow.md
Normal file
@@ -0,0 +1,49 @@
|
||||
# Sentinel Protocol Demo Data Flow Overview
|
||||
## 1. Key Sharding Flow: Fragmentation of Identity (Initialization)
|
||||
This is the starting point of the system. Through the SSS (3,2) threshold algorithm, the user's absolute control is transformed into distributed trust.
|
||||
- Input: System randomly generates 12 BIP-39 standard mnemonic words.
|
||||
- Action: Split the Entropy corresponding to the mnemonic words into 3 independent mathematical shares:
|
||||
- Share A (Device): Presumed to be stored in the user's mobile phone security chip.
|
||||
- Share B (Cloud): Presumed to be stored on the Sentinel server.
|
||||
- Share C (Physical): Presumed to be printed on a physical inheritance card and given to the heir.
|
||||
- Verification Point: Demonstrate that the original 12 mnemonic words can be reconstructed through any of the three combinations (A+B), (B+C), (A+C).
|
||||
|
||||
## 2. User Inner Encryption Flow: Establishing a Private Vault (Vault Layer)
|
||||
This is client-side encryption, ensuring "Zero-Knowledge" storage, meaning the system cannot perceive the data content without the shares.
|
||||
- Input: User private data (plaintext) + Mnemonic words recovered in Step 1.
|
||||
- Action:
|
||||
- Derive a symmetric encryption key (AES-256-GCM) from the mnemonic words.
|
||||
- Use this key to encrypt the data, generating Ciphertext 1.
|
||||
- Feature: This step simulates completion on the user's local device; Ciphertext 1 is the primary protection form of user assets.
|
||||
|
||||
## 3. System Outer Wrapping Flow: Double Encapsulation (Gateway Layer)
|
||||
This is the company/platform layer encryption, used to implement "Passive Verification" and "Permission Locking".
|
||||
- Input: Ciphertext 1 + Company generated independent RSA Public Key.
|
||||
- Action:
|
||||
- The system generates a set of RSA public/private key pairs (Company Keys) unrelated to the user.
|
||||
- Use the RSA Public Key to re-encrypt Ciphertext 1, generating Ciphertext 2.
|
||||
|
||||
- Logical Value: The generated Ciphertext 2 now has double security—even if the mnemonic is leaked, it cannot be opened without the company private key; even if the company private key is leaked, it cannot be opened without the mnemonic shares.
|
||||
|
||||
## 4. Decision Trigger Flow: Stripping the System Shell (Trigger/Unlock Layer)
|
||||
|
||||
This is the turning point of the Demo, simulating the system releasing the first layer of lock when "subscription fails" or during "normal access while alive".
|
||||
- Input: Ciphertext 2 + Company RSA Private Key.
|
||||
- Action: Use the private key to decrypt Ciphertext 2, restoring it to Ciphertext 1.
|
||||
- Business Mapping:
|
||||
- Alive Mode: User is active, system private key cooperates in real-time, allowing data to flow to the user.
|
||||
- Inheritance Mode: After death is confirmed, the system permanently releases this private key permission to the data packet.
|
||||
|
||||
## 5. Multi-Scenario Restoration Flow: Final Extraction (Restoration Scenarios)
|
||||
This is the end of the Demo, showing how data eventually returns to human hands in different social scenarios.
|
||||
- Input: Ciphertext 1 restored in Step 4 + Different combinations of shares.
|
||||
- Scenario Simulation:
|
||||
- Scenario 1: Normal access while alive
|
||||
- Combination: Share A (Phone) + Share B (Cloud) --> Recover Mnemonic --> Decrypt Ciphertext 1.
|
||||
- Significance: Proves that the user can view data without the inheritance card while alive.
|
||||
- Scenario 2: Standard inheritance after death
|
||||
- Combination: Share B (Cloud) + Share C (Physical Card) ---> Recover Mnemonic ---> Decrypt Ciphertext 1.
|
||||
- Significance: Simulates the user passing away, and the heir completing the handover relying on the card and the share released by the server.
|
||||
- Scenario 3: Pure testing verification, since the user holds all 12 mnemonic words
|
||||
- Combination: Share A (Phone) + Share C (Physical Card) --> Recover Mnemonic --> Decrypt Ciphertext 1.
|
||||
- Significance: Testing purposes.
|
||||
Reference in New Issue
Block a user