主页 on METEOR

CP-ABE：密文策略属性基加密（Bethencourt-Sahai-Waters 2007）

Mon, 17 Aug 2026 00:00:00 +0000

什么是属性基加密（ABE）？

属性基加密（Attribute-Based Encryption, ABE）是一种基于属性的公钥加密方案。与传统公钥加密（PKI）不同，ABE 不再用「某个用户身份」来标识公钥和私钥，而是用一组属性（Attributes）。

核心思想：加密时指定一个「谁能解密」的策略，解密时用户的私钥包含其拥有的属性。当用户属性满足策略时，即可解密。

ABE 有两种基本范式：

范式	策略在哪	含义
KP-ABE（密钥策略）	私钥中	用户私钥绑定策略，密文携带属性
CP-ABE（密文策略）	密文中	密文绑定策略，用户私钥携带属性

论文背景

ABE 的概念最早由 Sahai 和 Waters（2005） 提出，但他们的方案是 KP-ABE 范式：用户的私钥中包含访问策略，而密文只携带一组属性。

KP-ABE 的问题：数据所有者（加密者）无法控制「谁能访问」。策略是预先嵌入在用户密钥里的，这意味着你必须知道所有合法用户的属性集合才能生成密钥——这对实际场景非常不友好。

Bethencourt、Sahai、Waters（2007） 在论文 “Ciphertext-Policy Attribute-Based Encryption” 中提出了 CP-ABE，将策略与属性的角色完全反转：

✅ 密文携带访问策略（Access Policy）
✅ 用户私钥携带属性集合

这样，数据所有者在加密时就能精确控制「只有满足这个策略的用户才能解密」，而用户只需持有自己的属性密钥即可。

CP-ABE 的核心创新

1. 角色反转

1
2
3
4
5
6
7


KP-ABE（2005）：
 密文 <- 属性集合 {医生, 内科}
 私钥 <- 访问策略「医生 AND 内科」

CP-ABE（2007）：
 密文 <- 访问策略「医生 AND 内科」
 私钥 <- 属性集合 {医生, 内科}

2. 基于 LSSS 的访问结构

论文使用 线性秘密共享方案（LSSS, Linear Secret Sharing Scheme） 来表达任意单调访问结构。

LSSS 的核心：用一个矩阵 M 和一个向量 v 来表示访问策略：

矩阵的每一行对应一个属性
向量 v 是秘密的编码，满足 M * λ = (s, 0, 0, …, 0)
一个属性集合满足策略，当且仅当存在一组系数使对应行线性组合出 v

示例：策略「(A AND B) OR (C AND D)」对应的 LSSS 矩阵：

行	属性	向量
1	A	(1, 0)
2	B	(1, 0)
3	C	(0, 1)
4	D	(0, 1)

3. 双线性配对上的构造

方案基于 双线性配对（Bilinear Pairing） 和 DBDH（Decisional Bilinear Diffie-Hellman） 假设：

加密阶段：将明文与访问策略结合，生成携带策略的密文
密钥生成：根据用户属性集合生成私钥
解密阶段：利用双线性配对验证属性是否满足策略，并恢复明文

方案组成

Setup（系统初始化）

生成系统公共参数 PK 和主密钥 MK：

1
2


PK = (g, e(g,g)^α, {H(i)=g^a_i | i ∈ U})
MK = (α, a_1, ..., a_|U|)

KeyGen（密钥生成）

对用户属性集 S，生成私钥：

1

D_S = {D = g^r * H(σ_j)^r | j ∈ S}, D_tilde = g^r

Encrypt（加密）

给定明文 M 和访问策略 A，生成密文：

1

CT = (A, C = M * e(g,g)^(α*s), C_tilde = g^s, {C_j = g^(a_j*λ_j)})

其中 λ_j 是 LSSS 矩阵对应的秘密共享值。

Decrypt（解密）

用户用私钥 D_S 解密：

检查属性集 S 是否满足策略 A
若满足，找到对应行和系数 {w_j}
通过配对运算恢复共享值
从共享值中恢复明文 M

安全性

论文在 标准模型 下证明了选择性安全（Selective Security），基于 DBDH 假设。

安全性证明使用 归约（Reduction） 技术：假设存在一个能攻破 CP-ABE 的攻击者 A，则可以构造一个解决 DBDH 问题的算法 B，从而矛盾。

应用价值

CP-ABE 在以下场景有重要应用：

场景	说明
云存储访问控制	数据上传时指定策略，云服务商无法绕过策略解密
电子健康记录	按角色和权限属性精细控制病历访问
物联网数据分发	按设备属性加密，满足条件的设备自动解密
数字版权管理	按用户订阅属性控制内容访问

局限与后续发展

论文中的原始方案存在以下限制：

选择性安全：攻击者必须先声明挑战属性集，实际中可能不够强
密文膨胀：密文大小与策略复杂度成正比
密钥托管问题：主密钥持有者可生成任意属性密钥
不支持非单调策略：只能表达单调访问结构（AND/OR），无法表达 NOT

后续改进方向：

双系统加密：达到自适应安全（Adaptive Security）
密钥策略与密文策略的融合：支持更灵活的策略表达
可撤销 ABE：解决密钥托管和用户撤销问题
高效实现：减少双线性配对计算次数

学习心得

这篇论文是属性基加密领域的里程碑之作。从 KP-ABE 到 CP-ABE 的范式反转看似简单，但实现起来需要在双线性配对上做大量精巧的数学构造。特别是将 LSSS 与加密结合的设计，展现了密码学方案设计中「抽象代数工具 + 密码学假设」的经典范式。

理解了这篇论文后，再去看后续的 ABE 变体（如内积 ABE、功能加密等）会顺畅很多——它们大多是在这个基础上做的扩展和加强。

论文原文：Bethencourt, J., Sahai, A., & Waters, B. (2007). Ciphertext-Policy Attribute-Based Encryption. IEEE Symposium on Security and Privacy, 40-53.

论文链接：https://ieeexplore.ieee.org/abstract/document/4223236

属性加密通俗指南：让云上的数据「认人不认脸」

Mon, 17 Aug 2026 00:00:00 +0000

先从一个场景说起

想象你有一份机密文档，放在云盘上。你希望：

公司内部**部门是「研发部」且职级是「经理以上」**的人可以打开
其他人，哪怕知道文件在哪，也打不开

传统加密的做法是：生成一把密码，发给每个符合条件的人。问题来了——如果公司有一天新增了 100 个经理，你得给每个人单独发一把密码；如果有人离职了，你还得逐个通知他「密码作废」并重新加密文件。

这太麻烦了。 属性加密（Attribute-Based Encryption，简称 ABE）就是来解决这个问题的。

什么是属性加密？

一句话概括：ABE 让加密文件「认识属性，不认识具体的人」。

类比：智能门禁

想象一个智能大楼的刷卡门禁：

传统方式	ABE 方式
保安记住每个能进的人是谁，逐个核对	门禁只看「你是不是研发部的经理」这个条件
新人来了要更新名单	只要新人的工牌上有「研发部+经理」属性，自动放行
人走了要从名单删除	只要收回他的工牌（私钥）就行

ABE 就是把这套逻辑搬到了加密世界里：

加密时：你指定一个规则——「只有同时拥有『研发部』和『经理』属性的人才能解密」
解密时：用户用携带自己属性的私钥去尝试解密，属性满足规则就成功，不满足就失败

ABE 的两种流派

ABE 有两种主要范式，它们的核心区别是「规则写在谁身上」：

类型	规则（策略）在哪里	举例
KP-ABE（密钥策略）	用户的私钥里	用户的私钥说：「我能解密『研发部』的文件」，文件只需标注「研发部」即可
CP-ABE（密文策略）	密文里	文件说：「只有『研发部』的人能开」，用户私钥只需携带「研发部」属性

实际中 CP-ABE 更常用——因为文件上传者可以直接指定谁能看，不需要预先知道所有用户的身份。

ABE 怎么用？四个关键角色

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


+--------------------------------------------------+
| 权威机构（Authority） |
| 生成系统参数，根据用户属性发放私钥 |
+------------------------+-------------------------+
 | 发放私钥
 v
+--------------------------------------------------+
| 数据上传者（User A） |
| 用属性规则加密文件 -> 上传到云 |
| 例：「部门=研发 AND 职级>=经理」 |
+------------------------+-------------------------+
 | 加密后的文件
 v
+--------------------------------------------------+
| 云存储服务器 |
| 只存文件，不看内容 |
+------------------------+-------------------------+
 | 下载文件
 v
+--------------------------------------------------+
| 数据下载者（User B） |
| 用自己的私钥（含属性）尝试解密 |
| 属性满足规则 -> 解密成功 |
| 属性不满足 -> 解密失败 |
+--------------------------------------------------+

研究人员都在攻克哪些难题？

上面说的只是 ABE 的理想形态。现实应用中有一堆问题需要解决。两篇综述论文（《基于属性加密技术研究综述》和《云存储环境下属性基加密综述》）系统地梳理了以下方向：

难题一：效率太慢

问题：ABE 的核心运算叫「双线性配对」（Bilinear Pairing），这是一种数学上很安全的运算，但非常耗时。如果访问规则很复杂（比如涉及几十种属性），加密和解密的速度会让人无法接受。

解决方案：

在线/离线拆分（Hohenberger & Waters, 2014）：把计算分成两部分——离线阶段预先算好（不依赖具体数据），在线阶段只做少量计算。就像提前备好食材，炒菜时只加热就行。
密文大小恒定：无论规则多复杂，加密后的文件体积不变。这对网络传输很重要。
快速解密：让解密端（通常是手机等弱设备）的计算量尽量少。
外包解密：把繁重的解密计算交给云服务器做，但云服务器只能帮忙算，看不到最终结果。用户只需要在本地做一次轻量级验证。

通俗理解：就像你去餐厅吃饭，后厨（云）负责切菜炒菜（重计算），你只需在桌上把菜拌匀就能吃（轻验证），餐厅老板看不到你吃的是什么。

难题二：规则被偷看了

问题：在标准 ABE 中，文件的访问规则是明文写在密文里的。任何人下载了文件，虽然打不开内容，但能读到规则——「只有研发部经理能看」——这就泄露了信息。

解决方案：策略隐藏（Policy Hiding）。加密后连规则本身也是加密的，只有符合条件的用户解密后才能看到规则。

通俗理解：传统方式是门上贴着「只有经理能进」；策略隐藏是门什么也不贴，你刷一下卡才知道自己能不能进。

难题三：谁来给用户发属性？

问题：一个公司可能有 HR、财务、研发等多个部门，每个部门有自己的属性体系。如果只有一个权威机构管所有属性，那它就成了万能管理员——能签发任何属性，这是巨大的安全风险。

解决方案：多授权中心（Multi-Authority ABE）。不同的属性由不同的机构签发：

HR 部门管「部门」属性
人力资源部管「职级」属性
用户从多个机构收集自己的属性私钥，拼在一起就能解密

通俗理解：就像你考驾照需要车管所发，身份证需要派出所发，大学文凭需要学校发——各司其职，没有谁能单独给你完整的身份。

难题四：人在江湖，身份会变

问题：员工离职了、转岗了、或者只是临时外借，他的属性需要改变。传统做法是：重新给他签发私钥，同时把所有相关文件重新加密——工作量巨大。

解决方案：属性撤销（Attribute Revocation）。系统支持高效地撤销某个用户的某个属性，而不需要重新加密所有文件。

通俗理解：就像门禁系统里把离职员工的权限一键删除，而不需要把所有门的锁都换掉。

难题五：加密后没法搜索

问题：文件加密上传后，连文件名和内容都是密文。你没法在云端搜索「研发部 2024 预算」这类关键词——搜不了。

解决方案：可搜索属性加密（Searchable ABE）。允许用户在加密数据上执行关键词搜索，服务器帮助过滤，但不知道用户搜了什么，也不知道文件的明文内容。

通俗理解：就像你在图书馆的加密档案室搜书，管理员帮你找到可能匹配的书，但管理员不知道你搜的关键词是什么，也不知道书里写了什么。

难题六：私钥被卖了怎么办？

问题：如果某个用户的私钥被盗，被盗用的用户用它解密了不该看的文件，系统无法知道是谁泄露的。

解决方案：叛徒追踪（Traitor Tracing）。系统能在发现私钥被滥用时，反向追溯到是哪位用户泄露了私钥。

通俗理解：就像图书馆的书被偷了，虽然书上的名字被撕掉了，但书里夹着的追踪墨水能定位到是谁拿走的。

难题七：安全性还不够强

问题：早期 ABE 方案只能证明「选择性安全」（Selective Security）——攻击者必须在攻击前声明目标属性集。这在实际中不够强。

解决方案：

自适应安全（Adaptive Security）：攻击者可以随时选择攻击目标，安全性仍然成立。
双系统加密技术：通过巧妙构造两套加密系统，实现从选择性安全到自适应安全的跨越。

难题八：混合策略

问题：有时候 KP-ABE 和 CP-ABE 各有优势，能否结合？

解决方案：双策略 ABE（Dual-Policy ABE），同时支持密钥策略和密文策略，提供更灵活的访问控制能力。

未来方向展望

两篇综述都指出了以下值得关注的方向：

方向	说明
抗量子 ABE	未来的量子计算机能破解当前的 ABE 方案，需要基于格（Lattice）等抗量子假设重新设计
更细粒度的策略	支持「属性值范围」（如年龄 25~35）而非简单的「有无属性」
联邦学习 + ABE	多方数据在不解密的情况下联合训练 AI 模型
区块链 + ABE	用区块链管理属性签发和撤销，解决单点信任问题
更高效的实现	减少双线性配对次数，让 ABE 能在手机等弱设备上实用

小结

属性加密的核心魅力在于：它把「谁能访问数据」这件事，从人变成了属性。这让数据共享变得前所未有的灵活——你不需要知道具体是谁，只需要定义规则。

但它也带来了复杂的工程挑战：计算效率、策略隐私、多机构协作、身份动态变化、加密后搜索……每一个问题背后都有研究者用精妙的数学在寻找答案。

理解 ABE 的这些核心问题和方案，是进入现代密码学和隐私计算领域的重要一步。

参考文献：

王生玉, 汪金苗, 董清风, 朱瑞瑾. 基于属性加密技术研究综述[J]. 信息网络安全, 2019, 19(9): 76-80.
赵志远, 王建华, 朱智强, 孙磊. 云存储环境下属性基加密综述[J]. 计算机应用研究, 2018, 35(4).
Sahai A, Waters B. Fuzzy Identity-based Encryption[C]. Eurocrypt 2005.
Bethencourt J, Sahai A, Waters B. Ciphertext-Policy Attribute-Based Encryption[C]. IEEE S&P 2007.

Markdown 语法速查手册

Thu, 16 Jul 2026 00:00:00 +0000

Markdown 是一种轻量级标记语言，让你可以用纯文本格式编写文档。以下是常用语法总结。

标题

用 # 号表示标题，一个 # 是一级标题，最多六个。

1
2
3
4


# 一级标题
## 二级标题
### 三级标题
#### 四级标题

文本样式

1
2
3
4
5


**粗体文本**
*斜体文本*
***粗斜体文本***
~~删除线文本~~
`行内代码`

效果：粗体文本、斜体文本、粗斜体文本、~~删除线文本~~、行内代码

列表

无序列表

1
2
3


- 项目一
- 项目二
 - 子项目

效果：

项目一
项目二
- 子项目

有序列表

1
2
3


1. 第一步
2. 第二步
3. 第三步

效果：

第一步
第二步
第三步

链接与图片

1
2


[链接文字](https://example.com)
![图片描述](图片URL)

引用

1
2


> 这是一段引用文字
> 可以多行

效果：

这是一段引用文字可以多行

代码块

用三个反引号包裹代码，可以指定语言实现高亮：

1
2
3
4


```python
def hello():
 print("Hello, World!")
```

效果：

1
2


def hello():
 print("Hello, World!")

表格

1
2
3
4


| 左对齐 | 居中对齐 | 右对齐 |
|:-------|:-------:|-------:|
| 内容1 | 内容2 | 内容3 |
| 内容4 | 内容5 | 内容6 |

效果：

左对齐	居中对齐	右对齐
内容1	内容2	内容3
内容4	内容5	内容6

分割线

用三个或更多 -、* 或 _：

1

---

任务列表

1
2
3


- [x] 已完成
- [ ] 未完成
- [ ] 待办事项

效果：

已完成
未完成
待办事项

脚注

1
2
3


这里有个脚注[^1]

[^1]: 这是脚注内容

数学公式

行内公式用 $...$ ，块级公式用 $$...$$：

1
2
3
4
5


$E = mc^2$

$$
\sum_{i=1}^{n} i = \frac{n(n+1)}{2}
$$

快捷键速查

功能	语法
加粗	`文本`
斜体	`文本`
标题	`# 标题`
链接	`[文字](链接)`
图片	`![描述](URL)`
代码	`代码`
引用	`> 引用`
列表	`- 项目`

掌握这些基本语法就够日常使用了！

Microsoft SEAL 入门：同态加密实战

Thu, 16 Jul 2026 00:00:00 +0000

什么是同态加密？

同态加密（Homomorphic Encryption）是一种特殊的加密方式，允许在密文上直接进行计算，解密后的结果与在明文上计算的结果相同。

简单来说：数据加密后依然可以计算。

Microsoft SEAL 简介

Microsoft SEAL 是微软开发的开源同态加密库，支持以下三种方案：

BFV：支持整数加法和乘法
CKKS：支持近似浮点数运算
BGV：支持整数运算，更适合批处理

快速上手

安装

1
2
3
4


git clone https://github.com/microsoft/SEAL.git
cd SEAL
cmake -S . -B build
cmake --build build

基本使用示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


#include "seal/seal.h"
using namespace seal;

// 创建加密参数
EncryptionParameters params(scheme_type::ckks);
size_t poly_modulus_degree = 8192;
params.set_poly_modulus_degree(poly_modulus_degree);
coeff_modulus_id = CoeffModulus::Create(poly_modulus_degree, {60, 40, 40, 60});

// 创建 SEALContext
auto context = SEALContext::Create(params);

// 创建编码器、加密器、评估器
CKKSEncoder encoder(context);
Encryptor encryptor(context, key_generator.public_key());
Evaluator evaluator(context);
Decryptor decryptor(context, key_generator.secret_key());

// 编码、加密、计算、解密
std::vector<double> input = {0.5, 1.0, 1.5, 2.0};
Plaintext plain;
encoder.encode(input, scale, plain);

Ciphertext encrypted;
encryptor.encrypt(plain, encrypted);

// 在密文上进行加法
evaluator.add_inplace(encrypted, encrypted);

实际应用场景

隐私保护的机器学习：在加密数据上训练模型
安全多方计算：多方协作计算而不泄露各自数据
云计算隐私：将数据加密后上传云端计算

学习心得

同态加密的计算开销很大，但随着硬件加速和算法优化，正在逐步走向实用。SEAL 的文档和示例非常完善，是入门同态加密的好选择。

项目地址：https://github.com/microsoft/SEAL

家用智能灌溉系统设计与实现

Thu, 16 Jul 2026 00:00:00 +0000

研究背景

随着现代生活节奏的加快，许多家庭主人因为工作需要经常出差，导致家中的绿植长时间无人照料。植物因长期缺乏水分和光照，容易出现叶子枯黄、生长不良等问题，严重时甚至会导致植株死亡。

为了解决这一问题，本项目设计了一套家用智能灌溉系统，能够自动监测环境数据并智能控制灌溉，让用户即使不在家也能呵护心爱的绿植。

系统概述

本项目旨在构建一套适合家庭使用的智能灌溉系统，主要功能包括：

实时监测：采集土壤湿度、温度、光照等环境数据
智能灌溉：根据监测数据自动调节灌溉水量和时间
语音控制：集成语音模块，支持语音指令操作
远程操控：通过WiFi将数据上云，支持手机小程序远程控制

系统架构

智能灌溉系统采用三层架构设计：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


┌─────────────────────────────────────────────────────┐
│ 应用层 │
│ 串口屏显示 │ 小程序控制 │ 云平台数据存储 │
├─────────────────────────────────────────────────────┤
│ 网络层 │
│ ESP8266 WiFi │ ZX-D30 蓝牙 │
├─────────────────────────────────────────────────────┤
│ 感知层 │
│ 土壤湿度传感器 │ 温度传感器 │ 光照传感器 │
└─────────────────────────────────────────────────────┘

层级	组件	功能
感知层	土壤湿度传感器、DS18B20温度传感器、BH1750光照传感器	采集环境数据
网络层	ESP8266 WiFi、ZX-D30蓝牙	数据传输与通信
应用层	TJC3224T124串口屏、继电器水泵、云平台小程序	用户交互与控制

硬件设备

系统核心硬件包括：

设备	型号	功能说明
主控芯片	STM32F103C8T6	系统核心，负责数据处理和设备通信
温湿度传感器	DHT11	实时采集环境温湿度
光照传感器	BH1750	监测光照强度
土壤湿度传感器	电容式	检测土壤含水量
语音模块	ASRPRO	实现语音控制功能
WiFi模块	ESP8266	无线网络连接，数据上云
蓝牙模块	ZX-D30	近距离无线通信
串口屏	TJC3224T124	显示系统状态
继电器模块	5V继电器	控制水泵开关
水泵	直流潜水泵	执行灌溉操作

软件设计

系统软件基于 MQTT 协议实现数据上云，用户可通过小程序远程监控和控制灌溉系统。

数据流程

1
2
3


传感器采集 → STM32处理 → ESP8266上传 → 云平台存储 → 小程序显示
 ↓
 语音模块本地控制

主要功能模块

数据采集模块：定时读取各传感器数据
灌溉决策算法：根据土壤湿度自动判断是否灌溉
通信模块：通过MQTT协议与云平台通信
用户界面：串口屏本地显示 + 小程序远程控制

总结与展望

本项目实现了家用智能灌溉系统的基本功能，能够自动监测环境数据并智能控制灌溉。未来可从以下方面继续优化：

AI 算法：引入机器学习，根据植物种类和生长阶段优化灌溉策略
多传感器融合：增加雨滴传感器、水位传感器，实现更精准的控制
能源管理：集成太阳能供电，实现绿色环保
语音交互：升级语音模块，支持更自然的对话交互

本项目为个人学习实践，持续更新中…

libOTe：不经意传输扩展库详解

Wed, 15 Jul 2026 00:00:00 +0000

什么是不经意传输？

不经意传输（Oblivious Transfer, OT）是安全多方计算的基础协议之一。

场景：发送方有两条消息 m0 和 m1，接收方选择接收其中一条。协议保证：

接收方只能获得自己选择的消息
发送方不知道接收方选择了哪条

OT 扩展（OT Extension）

基础 OT 协议通信开销大，OT 扩展技术可以用少量基础 OT 生成大量 OT 实例。

libOTe 简介

libOTe 是俄亥俄州立大学（OSU）密码学组开发的高性能 C++20 OT 扩展库。

支持的协议

半诚实模型：

1-out-of-2 Silent OT
1-out-of-2 Correlated OT
1-out-of-N OT
VOLE（向量不经意线性求值）

恶意模型：

KOS15 协议
Silent OT

特点

高性能：使用 SSE 指令和向量化优化
跨平台：支持 Windows、Linux、macOS
易用：提供简洁的 API 和前端示例

编译与使用

1
2
3


git clone https://github.com/osu-crypto/libOTe.git
cd libOTe
python3 build.py

基本示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


#include "libOTe/TwoChooseOne/TcoOtExtReceiver.h"
#include "libOTe/TwoChooseOne/TcoOtExtSender.h"

// 创建 OT 扩展实例
OttExtReceiver* receiver = new IknpOtExtReceiver();
OttExtSender* sender = new IknpOtExtSender();

// 执行 OT 扩展
sender->genBaseOts(choice);
receiver->genBaseOts(choice);

std::vector<block> messages(128);
sender->send(messages, numOTs, prng, coproto::io);
receiver->receive(messages, choiceBits, numOTs, prng, coproto::io);

在隐私计算中的应用

OT 扩展是许多 MPC 协议的基础组件：

PSI（隐私集合交集）
PIR（隐私信息检索）
安全函数评估（SFE）

项目地址：https://github.com/osu-crypto/libOTe

Vole-PSI：基于向量 OLE 的隐私集合交集

Tue, 14 Jul 2026 00:00:00 +0000

什么是隐私集合交集（PSI）？

隐私集合交集（Private Set Intersection）允许两方在不泄露各自集合内容的前提下，计算出两个集合的交集。

应用场景：

基因数据对比
联合风控
好友推荐
广告转化率统计

Vole-PSI 的创新

Vole-PSI 基于向量不经意线性求值（Vector OLE）构建，相比传统 OT-based PSI 方案：

通信效率更高：向量 OLE 的通信开销与集合大小近似线性
计算更快：利用 OKVS（Oblivious Key-Value Store）减少计算量
支持 Circuit PSI：结果以秘密共享形式输出

技术原理

向量 OLE（Vector OLE）

向量 OLE 是 OT 的推广形式：

发送方输入向量 a，接收方输入标量 b
输出：发送方得到 r，接收方得到 s = a · b + r

协议流程

双方通过 Vector OLE 生成关联的掩码值
使用 OKVS 编码各自集合
通过掩码值匹配交集元素

编译与使用

1
2
3


git clone https://github.com/Visa-Research/volepsi.git
cd volepsi
python3 build.py -DVOLE_PSI_ENABLE_BOOST=ON

前端使用

1
2
3
4
5


# 发送方
./frontend -role sender -set input_sender.txt -output result.txt

# 接收方
./frontend -role receiver -set input_receiver.txt -output result.txt

性能对比

方案	通信开销	计算时间（1M 元素）
ECDH-PSI	O(n)	~10s
OT-based PSI	O(n)	~5s
Vole-PSI	O(n)	~2s

学习心得

Vole-PSI 的代码结构清晰，依赖管理做得很好。通过学习这个项目，我对向量 OLE 和 OKVS 有了更深入的理解。

项目地址：https://github.com/Visa-Research/volepsi