核心需求
- 文件加密上傳，服務端不可直接讀取明文。
- 支持上傳、下載、查詢、刪除、修改。
- 用戶登錄認證體系。
文件加密存儲方案：分塊加密 + 索引元數據
- 客戶端分塊：大文件按固定塊（如 4MB）分割。
- 派生密鑰：用戶密碼經 PBKDF2/Argon2 派生主密鑰，再為每個文件生成隨機文件密鑰（DEK），DEK 用主密鑰加密存儲。
- 塊級加密：每塊用 AES-GCM（或 ChaCha20-Poly1305）加密，產生密文塊 + 認證標籤。
- 命名去重（秒傳）：塊 ID 使用內容哈希（SHA-256/Blake3）。上傳前查詢服務端是否已存在該哈希塊，存在則跳過上傳（秒傳）。
- 元數據索引：客戶端維護文件元數據（文件名、大小、塊哈希列表、加密參數），加密後上傳至服務端數據庫/對象存儲。
服務端存儲結構
| 表/Bucket | 關鍵字段 |
|---|
users | uid, salt, pwd_hash_verifier, pub_key (可選) |
file_chunks | chunk_hash (PK), encrypted_data, ref_count |
file_metadata | fid, uid, enc_dek, name, size, chunk_hash_list (JSON), created_at |
用戶認證體系
- 必須有用戶系統：隔離數據空間、權限控制、审計追蹤。
- 數據庫存儲：推薦 SQLite（輕量）或 MySQL/PostgreSQL（多併發）。存儲：用戶名、鹽值、密碼驗證器（如 Argon2 輸出）、可選公鑰（支持非對稱登錄）。
- Token 機制：登錄簽發 JWT（含 uid、exp），後續請求攜帶 Authorization Header。
關鍵流程時序
上傳：
Client → 計算塊哈希 → 查詢服務端缺失塊 → 加密缺失塊 → 上傳塊 + 元數據
下載：
Client → 獲取元數據 → 並發下載塊 → 解密驗證 → 合併文件
技術選型建議
- 加密庫：
Tink (Google), Bouncy Castle, SQLCipher（若本地庫加密）。
- 網絡：
OkHttp + Retrofit，支持斷點續傳。
- 數據庫：
Room (SQLite) 或 GreenDAO。
- 服務端：Spring Boot + MinIO/S3 兼容對象存儲。
避坑指南
- **不要**在服務端解密，零知識原則：服務端只存密文與哈希。
- **不要**用 ECB 模式，必須用認證加密（AEAD）。
- **不要**硬編碼密鑰，所有密鑰均從用戶密碼派生或隨機生成並加密存儲。
- 大文件分塊上傳需處理網絡中斷重試、校驗完整性。
採用「客戶端加密 + 塊級去重 + 元數據索引 + 用戶體系」架構，能構建安全、高效、可擴展的網盤雛形，滿足畢設核心創新點要求。
