【隐私计算】隐语HEU同态加密算法解读

HEU: 一个高性能的同态加密算法库，提供了多种 PHE 算法，

包括ZPaillier、FPaillier、IPCL、Damgard Jurik、DGK、OU、EC ElGamal 以及基于FPGA和GPU硬件加速版本的Paillier版本。

本文我们会基于GPU运行HEU Docker容器，编译打包GPaillier并测试其性能。

算法总览

算法分类

Paillier

Paillier 算法由 Pascal Paillier 在 1999 年提出，参见：算法详情（跳转维基百科）

算法类型	加法同态加密
安全性	IND-CPA 安全，语义安全（Semantic Security）
困难假设	判定性复合剩余假设 decisional composite residuosity assumption (DCRA)
安全强度（Security Strength）	2048 位密钥长度等于或略低于 112 bits 安全强度 3072 位密钥长度等于或略低于 128 bits 安全强度

关于安全强度

目前未有直接的文献表明 DCRA 密钥长度与安全比特位数之间的关联，一般认为的难度 DCRA <= FACTORING（因数分解）<= DLP in $\mathbb{Z}^*_N$ [1]，在 DLP（离散对数难题）中，2048 group size 对应 112 bits，3072 group size 对应 128 bits [2]，因此 Paillier 的安全强度等效或略低于这个数值。

ZPaillier 中的 Z 与数学中表示整数的含义相同，即实现了一套支持整数运算的 Paillier 算法。
- 实现基于的 Paper：
FPaillier 中的 F 表示浮点数，Paillier 算法本身只支持整数，FPaillier 对Paillier 做了扩展，使其可以支持浮点数。
- FPaillier 的算法原理与 Python-Paillier 库类似。
IPCL 全称 Intel Paillier Cryptosystem Library，是 Intel 贡献的一种 Paillier 算法实现，其特点是支持 AVX512-IFMA 指令集和 Intel QAT 硬件加速器加速。
- 实现基于的代码库：pailliercryptolib 。

SchemaType 参数名称	phe.SchemaType.ZPaillier	phe.SchemaType.FPaillier	phe.SchemaType.IPCL
实现算法	Paillier	Paillier	Paillier
稳定性	稳定	稳定	实验性质，仅供测试和评估目的，还在持续完善中
支持的平台	Linux，macOS（Intel & Arm）	Linux，macOS（Intel & Arm）	Linux，macOS（Intel）
是否依赖特定硬件	不依赖	不依赖	不依赖
是否支持硬件加速	不支持	不支持	支持 AVX512-IFMA 指令集和/或 Intel QAT 加速器
相对性能	高	低	高

Okamoto-Uchiyama

Okamoto-Uchiyama 算法由 Tatsuaki Okamoto 和 Shigenori Uchiyama 在 1998 年提出，参见：算法详情（跳转维基百科）

算法类型	加法同态加密
安全性	IND-CPA 安全，语义安全（Semantic Security）
困难假设	p-subgroup assumption
安全强度（Security Strength）	存在争议，相同的密钥长度下 OU 的强度比特与 Paillier 相同或略低，见下文解释

关于安全强度

Paillier 的 $n=pq$ ，而 OU 的 $n=p^2q$ ，当 n 长度相同时两者安全强度是否相同，存在不同的观点。OU 的原始论文 [3] 认为目前最快的因式分解算法是 Field sieve method，这种算法的复杂度只和 n 相关，因此只要对齐 n 就可以得到相同的安全强度。

但也有一些 Paper 认为 OU 的 n 需要比 Paillier 多 500~600 比特两者安全性才相等 [4]，甚至还有文章 [5] 说 n 的分解只与 p 相关。因此如果特别在意安全性，请适当加大 OU 密钥长度。

SchemaType 参数名称	phe.SchemaType.OU
实现算法	Okamoto-Uchiyama
稳定性	稳定
支持的平台	Linux，macOS（Intel & Arm）
是否依赖特定硬件	不依赖
是否支持硬件加速	不支持
相对性能	高

OU 与 Paillier 比较

选择明文攻击 Chosen-Plaintext Attack (CPA)
选择密文攻击 Chosen-Ciphertext Attack (CCA)

OU 的优点：

相同的使用场景下，OU 的计算性能远高于 Paillier。
相同的使用场景下，OU 的密文大小只有 Paillier 的一半。假设密钥长度为 N，则 Paillier 的密文大小为 2N 比特，而 OU 密文为 N 比特。
OU 的安全性与 Paillier 相同，两者都达到了 IND-CPA 安全，且都不满足 IND-CCA 安全。

OU 的缺点：

OU 在学术上的知名度不如 Paillier。
OU 的明文值域空间不明确。假设密钥长度为 N，则 Paillier 的明文值域空间为 $Z_N$ ，而 OU 的明文值域空间为 $Z_p$ ，其中 p 是 private key 中的参数，因此 OU 的值域空间不是公开的。
虽然理论上两者都不满足 IND-CCA 安全定义，但在实际 IND-CCA 场景下 OU 存在已知攻击，而 Paillier 暂未发现有效攻击。

风险提示

虽然 OU 与 Paillier 在学术上的安全级别相同，两者都满足 IND-CPA 安全，且都达不到 IND-CCA 安全，但实际情况是 OU 已经被发现有高效的攻击手段，而 Paillier 尚未发现有效攻击。

OU 明文空间溢出攻击

OU 的明文空间为 $Z_p$ ，即 OU 的密文解密以后存在 mod p 的效果。如果允许攻击者加密一个大于 p 的明文，则容易反推出 p，导致私钥泄漏，具体原理如下：

攻击者选择一个比 p 大的明文： $m_1>p$ ，进行加密，并且能够得到解密结果 $m_2$ 。
显然： $m_1>p,m_2<p$ ，并且： $m_1\equiv m_2\ mod\ p$ 。
通过计算最大公约数 $gcd(m_1-m_2,n)$ 即可得到 p。

OU 在实现时一般做了限制，不允许直接加密大于 p 的明文，但是由于 OU 支持密态加法和明密文乘法，上述溢出攻击仍旧是可能的：

攻击者选择一个接近但是小于 p 的明文 m 加密得到 c。
对该密文 c 执行 t 次密文加法（或一次明密文乘法）满足 $m\ast t>p$ ，然后解密得到 ${m}'$ 。
攻击者获取 ${m}'$ ，利用同余关系即可获取私钥 p。

攻击防御

上述攻击成立的关键有两点，一是攻击者需要能构造出一个大于 p 的密文，二是攻击者需要能获取解密的结果，两者缺一不可，这是一个典型的选择密文攻击（CCA）场景，实际使用 OU 时，应当 避免在 CCA 成立的场景下使用 OU。

(1) 安全使用Case1

对于一些简单的场景，比如 Alice、Bob 两方计算，假设 Alice 有私钥，Bob 为恶意参与方，计算的过程为 Alice 将数据加密后发给 Bob 计算，Bob 把计算结果返回给 Alice，此时，即使 Bob 构造了恶意的密文 c，但是 Bob 拿不到 c 对应的解密结果，Bob 的攻击会造成计算错误，但是密钥不会泄露。

(2) 安全使用Case2

在一些复杂的隐私计算场景中，下一轮的交互取决于上一轮交互的结果，CCA 场景成立也许是不可避免的，但并非说明 OU 就一定无法使用，如果 Alice 有有效的手段阻断攻击，OU 仍旧可以选用。让我们再来回顾一下攻击的过程：Bob 构造的密文 c 对应明文 m，Alice 解密后得到 m′=m mod p，实际的问题是，m′有可能非常大，远超一般业务中使用的 int64 所能表达的范围，因为 Bob 想要构造一个略大于 p 的密文是非常困难的，p 一般非常大，key size 为 2048 时 p 大约为 682bits，Bob 盲猜一个数 m 满足 ${m}'<2^{64}$ ，其概率小于 $2^{-(682-64)}$ ，即盲猜的 m 的高618bits 与 p 完全一样，这个概率是可以忽略不计的，因此可以认为 m′ 仍旧是一个大数，当 Alice 解密发现明文不在合理值域范围时，可以拒绝 Bob 的结果，从而阻止 Bob 的攻击。

所以对于联邦逻辑回归中，一般是在梯度计算的时候，涉及到密文计算，但梯度的值一般是有范围限制的，比如标准化后的特征值取值范围通常是在-3到3之间；归一化后的特征值去值范围在0到1之间；梯度因子 $y'-y$ 的大小，由于 $y'$ 需要进行sigmoid转化，因此 $y'$ 通常在(0, 1)之间，而标签 $y$ 通常为[0,1]，所以梯度因子的范围(-1, 1)，另外，host方加入的随机噪声通常可控，如果恶意设置过大，Guest方解密后可以直接拒绝。从而阻止Host方的攻击。

ElGamal

ElGamal 是一个基于 Diffie–Hellman 密钥交换的非对称加密算法，由 Taher Elgamal 在 1985 年提出[6]。原始的 ElGamal 具有乘法同态性质，其同态性来自于密文块 $mh^r$ 。

在之后的 Generalized ElGamal 算法中，整个密码体制被定义在循环群 G 上，其加密的安全性也取决于 G 上离散对数问题的困难性，为此，用于构建 Generalized ElGamal 的循环群 G 必须满足以下两项要求：

高效性：G 上的计算必须非常快速
安全性：求解 G 上的离散对数问题(DLP)非常困难

以下是一些满足上述要求的具体的 G 的例子：

算法类型	同态特性取决于底层循环群 G 的定义，根据 G 的不同 Elgamal 可能为加法同态、乘法同态或没有同态特性。
安全性	如果定义在 G 上的 Decisional Diffie–Hellman assumption (DDH) 是困难的，则算法是语义安全（Semantic Security）的，不可区分性满足 IND-CPA
困难假设	CDH & DDH
安全强度（Security Strength）	取决于 G

为了获得加法同态特性，以及兼顾计算上的高效性，HEU将循环群选定为椭圆曲线点群（EC Group）作为 ElGamal 底层的 G，因此 HEU 中的 ElGamal 也称为 EC ElGamal。取决于明文到 EC Group 的映射方式，如果映射妥当，则 EC ElGamal 满足加法同态特性。

HEU 实现了 EC ElGamal 算法，这是一种定义在椭圆曲线点群（EC Group）上的 ElGamal 算法，相比其他循环群 G，EC Group 的计算效率更高，使得 EC ElGamal 最终性能表现非常优秀。

另一方面，为了维持加法同态特性，EC ElGamal 将明文映射到 EC Group 的方式为：m′=mG，其中 mm 是明文，m′是映射后的明文，即椭圆曲线上的一个点，G 是 EC Group 的生成元。这是一个典型的单向函数（one-way function），EC ElGamal 解密之后得到 m′ 想要反向计算出真正的明文 mm 是非常困难的，没有直接求解算法，以至于 EC ElGamal 解密非常慢，这是 EC ElGamal 的缺点。

SchemaType 参数名称	phe.SchemaType.ElGamal
实现算法	ElGamal
同态特性	加法同态加密
稳定性	仅供非生产环境使用
支持的平台	Linux，macOS
是否依赖特定硬件	不依赖
是否支持硬件加速	取决于曲线种类的选择。（注：目前所有曲线都不支持硬件加速）
相对性能	高

算法性能

HEU 提供了一个 Benchmark 用以测试每个算法的性能，若要运行 Benchmark 请先 clone HEU 代码库，然后在项目根目录下执行：

# 测试算法在 scalar 运算场景下的性能
# Test the performance of algorithms in scalar computing scenarios
bazel run -c opt heu/library/benchmark:phe -- --schema=zpaillier

# 测试算法在矩阵运算场景下的性能
# Test the performance of algorithms in matrix operation scenarios
bazel run -c opt heu/library/benchmark:np -- --schema=zpaillier

Key size = 2048

表格的项表示单线程1万次计算的总时间，单位 ms。

SchemaType	加密	密文+密文	密文+明文	密文*明文	解密
OU	278	18.1	52.5	529	2458
ZPaillier	8141	70.9	192	1960	86984
FPaillier	151187	230	150529	1692	150580

验证GPaillier性能

https://github.com/secretflow/heu/tree/main/heu/library/algorithms/paillier_gpu

使用须知

该算法为 Paillier 算法的实验性实现，请勿用于生产环境
该算法的性能不佳，请改进此算法
该算法底层依赖 Nvidia CGBN 第三方库，CGBN 属于 NVlabs 的产品，目前已经停止维护，请慎用

Key size = 2048，schema = gpaillier，矩阵(10000，1)的各项性能，单位ms。

SchemaType	加密	密文+密文	密文+明文	密文*明文	解密
GPaillier	2647	75	124	124	2504

GPaillier和ZPaillier性能对比

可修改 heu/library/benchmark/np_bench.cc，调整测试数据大小和秘钥长度。

GPU Docker环境

`docker pull 镜像`

# https://hub.docker.com/r/secretflow/heu-ci/tags
docker pull dockerpull.com/secretflow/heu-ci:latest

`启动docker镜像-gpu`

docker run --gpus all --runtime=nvidia -e NVIDIA_VISIBLE_DEVICES=all -itd secretflow/heu-ci /bin/bash

安装对应版本cuda

# https://developer.nvidia.com/cuda-12-4-0-download-archive?target_os=Linux&target_arch=x86_64&Distribution=Ubuntu&target_version=22.04&target_type=runfile_local
wget https://developer.download.nvidia.com/compute/cuda/12.4.0/local_installers/cuda_12.4.0_550.54.14_linux.run
sudo sh cuda_12.4.0_550.54.14_linux.run

`获取heu代码`

wget https://github.com/secretflow/heu/archive/refs/tags/v0.5.1b0.tar.gz

代码编译打包

ENABLE_GPU= python setup.py bdist_wheel

编译打包失败: eigen拉取超时失败，手动下载并配置本地http服务，配置下载地址。

vim /home/admin/heu-0.5.1b0/third_party/bazel_cpp/repositories.bzl

def _com_github_eigenteam_eigen():
    EIGEN_COMMIT = "66e8f38891841bf88ee976a316c0c78a52f0cee5"
    EIGEN_SHA256 = "01fcd68409c038bbcfd16394274c2bf71e2bb6dda89a2319e23fc59a2da17210"
    maybe(
        http_archive,
        name = "com_github_eigenteam_eigen",
        sha256 = EIGEN_SHA256,
        build_file = "@com_alipay_sf_heu//third_party/bazel_cpp:eigen.BUILD",
        strip_prefix = "eigen-{commit}".format(commit = EIGEN_COMMIT),
        urls = [
            "http://localhost:8080/eigen-66e8f38891841bf88ee976a316c0c78a52f0cee5.tar.gz,
            #"https://gitlab.com/libeigen/eigen/-/archive/{commit}/eigen-{commit}.tar.gz".format(
            #    commit = EIGEN_COMMIT,
            #),
        ],
    )

修改后编译成功: sf_heu-0.5.1b0-cp310-cp310-manylinux2014_x86_64.whl

GPaillier仅支持2048

>> YACL_ENFORCE(key_size == 2048, "GPU Paillier only supports 2048 key_size now");

GPaillier 运行性能测试

bazel run -c opt heu/library/benchmark:np --config=gpu -- --schema=gpaillier