6.2 Data Encryption Standards
OmniPact 协议处理的数据分为两类：瞬时通信数据（如 P2P 聊天中的支付详情）和持久化证据数据（如存储在 IPFS 上的合同文件）。针对这两类数据，我们分别设计了加密标准。
6.2.1 ECIES for P2P Data
对于 OTC 交易中的银行卡号、Swift 代码或沟通细节，数据必须在买卖双方之间实现端到端加密 (End-to-End Encryption, E2EE)，且任何第三方（包括 OmniPact 协议节点）均不可见。
我们直接利用以太坊账户已有的 secp256k1 密钥对，采用了 ECIES (Elliptic Curve Integrated Encryption Scheme) 标准。
1. 密钥派生流程 (Key Derivation Workflow)
假设 Alice (买家) 要发送加密信息 $M$ 给 Bob (卖家)：
临时密钥生成: Alice 生成一个临时的、一次性的私钥 和对应的公钥 。
共享秘密计算 (ECDH): Alice 利用 Bob 的公开公钥 $K_{Bob}$ 计算共享点 $S$：
$$S = r \times K_{Bob}$$
(注：Bob 收到后，可利用自己的私钥 $k_{Bob}$ 计算 $S = k_{Bob} \times R$，根据椭圆曲线性质，两者计算出的 $S$ 是相同的。)
密钥扩展 (KDF): 将点 输入密钥派生函数（如 ANSI-X9.63-KDF），生成对称加密密钥 和消息验证密钥 。
加密与封装:
发送: Alice 将数据包 通过中继网络发送给 Bob。
6. 安全性优势
前向保密 (Forward Secrecy): 由于使用了临时密钥 ，即使 Alice 的长期私钥在未来泄露，过去的会话记录也难以被批量解密（若配合 Ratchet 算法）。
无缝体验: 用户无需记忆额外的密码，直接使用 Web3 钱包（MetaMask）签名即可完成解密。
6.2.2 Dual-Key Architecture for Arbitration Evidence
存证数据（Evidence）面临一个独特的挑战：数据必须在平时对公众保密，但在发生争议时，必须能被随机选出的仲裁员解密读取。
为了解决“隐私”与“司法透明”的矛盾，我们设计了 Dual-Key (双层密钥封装) 架构。
1. 混合加密结构 (The Hybrid Structure)
所有大文件（如 PDF、设计图）均使用 AES-256-CBC 对称算法进行加密，生成密文 $Enc_{Data}$。
真正的核心在于：AES 密钥 $K_{sym}$ 该如何存储？
2. 状态一：正常交易期 (The Private State)
在交易创建初期，AES 密钥 $K_{sym}$ 被分别加密并存储在元数据中：
Key A (For Buyer):
Key B (For Seller):
此时，文件存储在 IPFS 上，但只有买卖双方能解开 从而读取文件。对于外界，这就是一堆乱码。
3. 状态二：争议仲裁期 (The Juror Access State)
当买方发起争议（raiseDispute）时，协议强制要求买方提交一个新的密钥封装：
Key C (For Jury):
这里的 并不是单一的私钥（否则会有单点风险），而是一组门限密钥 (Threshold Keys) 或 临时会话公钥。
一旦仲裁员被 VRF 选中，仲裁员客户端会通过 Diffie-Hellman 密钥交换，从发起争议方（或智能合约的秘密共享池）安全地获取 。
这种机制实现了“(Access on Demand)”：仅当争议发生且你被选为法官时，你才有权查看证据。
4. 证据完整性验证 (Integrity Verification)
为了防止一方在发生争议后篡改证据（例如偷偷替换了加密文件），OES 合约在 $S_{lock}$ 阶段就记录了文件的哈希指纹：
仲裁员在解密前，会先校验 IPFS 文件的哈希是否与链上记录匹配。这确保了呈堂证供的原始性 (Originality)。
引入 ECIES 和双钥架构，展示了 OmniPact 如何在去中心化存储（公开）与商业机密（私有）之间构建了一道坚固且灵活的密码学防线。