Encrypted Spaces：一种面向协作应用的加密架构深度解读

背景

云计算彻底改变了协作方式。曾经局限于本地、单用户且私密的工具（如文字处理器、电子表格和设计编辑器），如今已演变为基于中心化后端的多人协作系统。这种基于中心化、可云端访问的服务器架构极大地降低了协作门槛，但也带来了一个核心矛盾：用户必须信任存储和处理敏感数据的服务器。

这种信任模型存在显著风险，主要体现在以下三个方面：

1. 数据暴露风险（Exposure）：存储在服务器上的明文数据可能面临三重威胁：外部攻击者入侵、内部人员越权访问，或被强制要求披露数据的外部势力。
2. 控制权丧失（Loss of control）：数据的共享和保留策略由服务器制定，而非用户。策略可能随时间变更，所谓的“删除”往往并非真正彻底，且用户共享的数据可能被用于外部的推荐算法、排名系统或模型训练。
3. 自我审查（Self-censorship）：由于用户无法确知服务器如何处理其私有数据，往往会在分享时有所保留。敏感对话可能被迫转移至其他渠道，甚至根本不会发生。

对于记者、活动家、患者和社会服务机构而言，这些风险并非理论假设，而是直接决定了他们能安全地说什么、分享什么或构建什么。

核心内容

**Encrypted Spaces（加密空间）**是一项研究计划，旨在探索一种新的协作工具架构。在这种架构中，服务器虽然存储数据，但只能检查和处理用户明确允许的数据部分。一个可信的协作应用程序可以在不可信的服务器上运行，通过精心设计的密码学应用，确保数据机密性，并让用户验证服务器是否行为端正。同时，通过精心的应用设计，用户和开发者无需接触底层的密码学细节。

加密空间的定义与五大特征

一个加密空间是一个共享的、持久化的数据系统，具备以下五个核心特征：

1. 服务器角色转变：服务器作为中心化的数据存储和同步点，但不被信任处理明文用户数据。
2. 应用数据模式定义：应用数据模式（Schema）明确定义了哪些数据是加密的，以及服务器可以看到哪些数据以支持丰富的查询功能。
3. 密码学验证：用户通过验证密码学证明（Cryptographic Proofs），确保服务器行为符合预期。
4. 访问控制与密钥管理：系统强制执行成员资格和访问控制，并处理密钥管理和加密过程。
5. 可追溯性：参与者清楚谁可以读取和修改数据，且所有更改都归属于其作者。

五大组成组件

Encrypted Spaces 由五个组件构成，每个组件解决协作过程中产生的特定需求：

1. 成员状态（Membership State）：管理谁有权访问空间。
2. 可验证数据库与追加式变更日志（Verifiable Database with Append-Only Changelog）：确保数据操作的不可篡改性和可审计性。
3. 密钥管理（Key Management）：处理加密和解密所需的密钥生命周期。
4. 密钥保留系统（Key Retention System）：在需要恢复访问权限时提供机制。
5. 应用定义的操作（Application-Defined Operations）：允许上层应用定义特定的业务逻辑操作。

原型演示：面向不可信基础设施的同步引擎

为了证明该架构的实用性，研究团队正在开发一个原型同步引擎（类似 Firebase 或 Supabase），其底层数据存储于加密空间中。

• 底层实现：底层空间代码负责处理共享加密数据的可验证插入、更新和删除。
• 高层抽象：同步引擎向应用提供高级数据结构的实现（如 Tables、Lists 和 TextAreas）。
• 客户端视角：对客户端而言，这些结构看起来就像本地数据。但在后台，同步引擎通过加密空间支撑这些结构，并协调更新，为客户端提供共享的、同步的视图。

代码示例解读： 原文提供的 Rust SDK 示例展示了开发者如何以熟悉的方式（类似 Firebase/Supabase 的 API 风格）与加密空间交互：

use encrypted_spaces_sdk::Space;
use serde::{Deserialize, Serialize};

#[derive(Serialize, Deserialize)]
struct Project {
    id: Option<i64>,
    name: String,
}

// 1. 打开一个加密空间
let space = Space::new(transport).await?;

// 2. 获取一个表对象
let projects = space.table::<Project>("projects");

// 3. 写入一行数据
let id = projects
    .insert(&Project {
        id: None,
        name: "Internal Tools".into(),
    })?
    .execute()
    .await?;

// 4. 读取数据（支持查询，如 id > known_id）
let new_projects = projects
    .select()
    .where_gt("id", known_id)
    .all()
    .await?;

这一 SDK 表面保持了与主流后端即服务（BaaS）平台开发者预期一致的接口，但在底层提供了密码学验证能力。

关键要点

• 信任最小化：核心目标是构建可以在不可信基础设施上运行的可信协作应用，通过密码学而非信任服务器来保障安全。
• 平衡隐私与功能：通过应用数据模式（Schema）设计，既实现了数据加密保护，又允许服务器执行必要的查询和同步，解决了“完全加密导致无法搜索/协作”与“明文存储导致隐私泄露”之间的矛盾。
• 用户主权回归：将数据共享、保留策略的控制权从服务器交还给用户，防止数据被用于未经授权的算法训练或推荐。
• 开发体验友好：尽管底层涉及复杂的密码学（如零知识证明、多项式承诺等），但 SDK 封装了这些细节，开发者可以使用熟悉的 CRUD 操作接口，无需成为密码学专家。
• 研究性质：Encrypted Spaces 目前仍处于活跃研究阶段，并非最终完成的产品系统。

意义与影响

团队背景与学术支持

该工作由一组研究人员和工程师开发，核心成员包括：

• Michele Orrù：CNRS 助理教授，专注于密码学和减少个人数据长期存储的隐私保护系统，曾参与 arkworks、Tor 等项目。
• Trevor Perrin：独立密码学工程师，Signal 协议联合创始人，Noise 协议框架作者。
• Nora Trapp：哈佛大学 Berkman Klein 中心工程师，前 Signal Foundation 技术负责人，专注于可用密码学。
• Greg Zaverucha：微软研究院密码学家，Signal 私人群组系统共同作者，KZG 多项式承诺方案共同发明人（广泛用于现代零知识系统）。

该研究得到了微软研究院密码学组和哈佛大学 Berkman Klein 中心互联网与社会应用社交媒体实验室的密切合作与支持。

行业影响

1. 重塑协作安全标准：为高敏感人群（记者、活动家、医疗领域）提供了技术可行的安全协作方案，可能改变这些领域的数据处理规范。
2. 推动“隐私优先”的基础设施：Encrypted Spaces 提供了一种中间层架构，使得现有的云基础设施可以在不修改服务器代码的情况下，通过客户端和协议层的加密来增强安全性。
3. 开源与生态建设：研究团队正在构建围绕这一理念更广泛的研究星座，并邀请开发者参与原型测试和后续工作，有望催生新的隐私保护型协作工具生态。

Encrypted Spaces 代表了从“信任服务器”向“验证服务器”范式转变的重要一步，为下一代隐私保护的协作应用奠定了架构基础。