简介：这是一份面向密码学学习者与安全开发者的IBE基于身份加密系统加密程序源码包，适合研究基于身份密码体制、SM9算法原理及C++工程实现的中高级读者。资源共40个文件，以cpp与h源码文件为核心，配合obj、sbr、pdb等编译中间与调试文件，以及exe可执行程序、lib静态库和dsp、dsw工程文件，压缩包约1.57MB，可直接在VC6环境下打开编译运行。内容围绕zzn、ecn、big等大数运算与椭圆曲线模块展开，并包含ibe_enc主程序与common.ibe、guoshaolong.ibe等参数文件，完整呈现IBE加密流程的代码结构。目前已有1317人学习下载，读者可借此理解双线性对、密钥生成与加解密实现细节，对照源码调试并移植到自己的密码工程项目中。
1. 从一对密钥到一串身份：IBE 加密程序到底解决了什么
如果你维护过内部系统，大概率遇到过这种场景：要给二十个同事发加密文件，传统公钥体系下你得先收集二十份公钥，还得逐个确认「这把公钥真的是他的」。一旦有人换了设备、重装了系统，密钥对重新生成，你手里的公钥就作废了。IBE（Identity-Based Encryption，基于身份的加密）就是冲着这个麻烦来的——它把「公钥」直接换成对方一眼可读的身份标识，比如工号、邮箱前缀、设备编号，加密方不需要提前拿到任何密钥文件，只要知道这个字符串就能加密。这份 IBE 加密程序资源，核心就是把这套「用身份当公钥」的流程做成可运行的代码，覆盖参数生成、私钥提取、加密、解密四个环节。它适合两类人：一类是要在离线环境里做小范围密文分发的运维或后端，另一类是正在啃密码学课程、需要一份能跑通的最小实现来对照论文公式的开发者。下面我按实际拆包和跑通的顺序，把选型理由、参数含义和几个容易翻车的地方讲清楚。
2. 拆开 IBE 的四个环节：主密钥、身份、密文、私钥
2.1 为什么是「四步」而不是「两步」
传统 RSA 只有「生成密钥对 → 加密 → 解密」三步，IBE 多出一个「私钥提取」环节，这不是设计冗余，而是它的安全模型决定的。整个系统里有一个可信的私钥生成中心（PKG），它先跑一次初始化，产出一对主密钥：主公钥公开给所有人用来加密，主私钥自己留着。当某个身份需要解密时，PKG 用主私钥和这个身份字符串算出对应的私钥，再通过安全渠道交给本人。所以完整链路是：初始化 → 提取私钥 → 加密 → 解密。理解这一点很关键，因为后面所有参数配置和排错，几乎都围绕「主私钥不能泄露」和「身份字符串必须完全一致」这两条展开。
常见做法是选一条配对友好的椭圆曲线，比如 BN254 或 BLS12-381，因为 IBE 的数学基础是双线性配对。如果你拿到的实现里出现pairing、G1、G2、GT这些符号，别慌，它们只是配对运算里的几个群，加密和解密就是在这几个群之间做映射。选型上，如果只是做教学验证或内部小工具，BN254 足够；如果对安全强度有要求，优先 BLS12-381，它的安全余量更大。
2.2 初始化：主密钥是怎么生成的
初始化这一步决定了整个系统的安全边界。下面是一段典型的初始化代码，用配对库生成主密钥对：
# 初始化 PKG，生成主密钥对 # curve: 选定的配对友好曲线，教学常用 BN254 from pairing import PairingGroup def setup(curve_name="BN254"): group = PairingGroup(curve_name) # 主私钥：GT 群上的一个随机元素，必须保密 master_secret = group.random_gt() # 主公钥：主私钥与生成元的配对结果，可公开 master_public = group.pair(group.g1, group.g2) ** master_secret return { "group": group, "master_secret": master_secret, # 只留在 PKG 侧 "master_public": master_public, # 分发给加密方 "curve": curve_name }逻辑上，master_secret是随机数，master_public由它推导而来，两者不可逆。参数说明：curve_name决定底层群运算，换曲线意味着所有已生成的密文和私钥全部失效，所以生产环境一旦定下曲线就不要中途更换。master_secret绝对不能写进配置文件或日志，我一般会把它单独放在一个只有 PKG 进程能读的路径下，权限设成 600。
2.3 私钥提取：身份字符串的规范化是重灾区
私钥提取是 IBE 区别于传统公钥体系的关键一步，也是最容易出问题的一步。因为身份字符串直接参与私钥计算，任何大小写、空格、编码差异都会导致解密失败。
# 根据身份字符串提取私钥 # identity: 用户身份，如 "user_1001" 或 "alice@internal" def extract_private_key(setup_result, identity): group = setup_result["group"] master_secret = setup_result["master_secret"] # 关键：身份先做规范化，统一小写并去除首尾空格 normalized = identity.strip().lower() # 将身份哈希到 G1 群上的一个点 identity_point = group.hash_to_g1(normalized) # 私钥 = 身份点 ^ 主私钥 private_key = identity_point ** master_secret return {"identity": normalized, "private_key": private_key}这里strip().lower()是我强烈建议保留的规范化步骤。血泪经验是：加密方写Alice@Internal，提取方写alice@internal，数学上就是两个完全不同的点，解密必然失败，而且报错信息通常很含糊，只告诉你「配对结果不匹配」，排查起来非常费劲。参数上，hash_to_g1的哈希函数要和加密方保持一致，如果实现里允许自定义哈希，两边必须用同一个。
2.4 加密与解密：配对等式怎么对上
加密方拿到主公钥和身份字符串，产出一个密文；解密方拿私钥和密文，通过配对运算还原明文。核心代码如下：
# 加密：输入主公钥、身份、明文 def encrypt(setup_result, identity, message): group = setup_result["group"] master_public = setup_result["master_public"] normalized = identity.strip().lower() identity_point = group.hash_to_g1(normalized) # 随机数 r，每次加密都要重新生成，绝不能复用 r = group.random_zr() # 密文第一部分：明文与配对结果的异或 shared = master_public ** r c1 = group.g1 ** r c2 = message ^ group.hash_to_bytes(shared) return {"c1": c1, "c2": c2, "identity": normalized} # 解密：输入私钥和密文 def decrypt(private_key, ciphertext): group = private_key["group"] # 配对运算还原共享秘密 shared = group.pair(ciphertext["c1"], private_key["private_key"]) message = ciphertext["c2"] ^ group.hash_to_bytes(shared) return message逻辑说明：加密时用主公钥和身份点算出共享秘密，解密时用密文第一部分和私钥通过配对算出同一个共享秘密，两者异或即可还原。参数上，r必须是每次加密独立生成的随机数，复用r会导致相同明文产生相同密文，泄露模式信息。hash_to_bytes的输出长度要和明文对齐，否则异或会截断。
3. 把程序跑起来：环境、依赖与一次完整加解密
3.1 环境准备与依赖安装
这份资源是 Python 实现，依赖一个配对运算库。我一般会在虚拟环境里跑，避免污染系统 Python：
# 创建并激活虚拟环境 python3 -m venv ibe_env source ibe_env/bin/activate # 安装配对库和基础依赖 pip install pairing==0.3.0 pip install pycryptodome # 验证安装 python -c "from pairing import PairingGroup; print('ok')"参数说明：pairing是配对运算的核心库，版本号以资源内 requirements 为准，不要盲目升级，配对库的 API 在不同大版本间变动较大。pycryptodome用于哈希和字节处理。如果安装时报编译错误，通常是缺少gmp开发库，Linux 下装libgmp-dev，macOS 下装gmp即可。
3.2 一次完整的加解密流程
把前面四个环节串起来，跑一遍端到端验证：
from ibe import setup, extract_private_key, encrypt, decrypt # 1. 初始化 PKG pkg = setup(curve_name="BN254") print("主公钥已生成:", pkg["master_public"]) # 2. 为身份 user_1001 提取私钥 identity = "user_1001" key = extract_private_key(pkg, identity) print("私钥已提取，身份:", key["identity"]) # 3. 加密一条消息 plaintext = b"internal report 2024" cipher = encrypt(pkg, identity, plaintext) print("密文第一部分:", cipher["c1"]) # 4. 解密 recovered = decrypt(key, cipher) assert recovered == plaintext, "解密结果与原文不一致" print("解密成功:", recovered.decode())逻辑说明：setup只跑一次，产出的主公钥可以分发给所有加密方；extract_private_key每个身份跑一次，私钥单独交付；encrypt和decrypt是日常操作。参数上，identity在加密和解密两侧必须完全一致，建议在业务层就统一成小写。断言那行是必要的自检，如果这里就失败，说明前面某一步的参数对不上，不用往下查。
3.3 密文与私钥的序列化
实际部署时，密文和私钥需要落盘或走网络传输，必须序列化。群元素不能直接 JSON 化，常见做法是转成十六进制字符串：
# 序列化群元素为十六进制字符串 def serialize_point(point): return point.export().hex() # 反序列化 def deserialize_point(group, hex_str): return group.deserialize(bytes.fromhex(hex_str)) # 密文落盘示例 cipher_record = { "c1": serialize_point(cipher["c1"]), "c2": cipher["c2"].hex(), "identity": cipher["identity"] }参数说明：export()和deserialize()是配对库提供的标准方法，不同库方法名可能不同，以资源内实现为准。注意c2是字节串，直接.hex()即可。序列化后的密文可以存数据库或写文件，但私钥的序列化结果属于敏感数据，传输时必须走加密通道，落盘时要限制权限。
4. 避坑与排查：五个让解密失败的常见原因
4.1 身份字符串大小写或空格不一致
现象：加密和解密都返回成功，但还原出的明文是乱码，或者断言直接失败。原因：加密方用User_1001，解密方用user_1001，哈希到群上得到两个不同的点，配对结果自然对不上。解决：在extract_private_key和encrypt里都做strip().lower()规范化，并且把规范化后的身份写进密文记录，解密时用记录里的身份而不是重新输入。
4.2 随机数 r 被复用
现象：两条不同明文加密后，密文第一部分完全相同。原因：加密函数里r被写成了全局变量或固定值，没有每次重新生成。解决：确保r = group.random_zr()在encrypt函数内部执行，不要提到函数外。这一点在密码学里是硬性要求，复用随机数会直接破坏语义安全。
4.3 曲线参数不匹配
现象：初始化用 BN254，加密方却用 BLS12-381 的主公钥，报群元素类型错误。原因：不同曲线的群元素不能混用，序列化格式也不兼容。解决：把曲线名作为配置项统一管理，初始化、提取、加密、解密四处都从同一个配置读取，禁止硬编码。
4.4 主私钥泄露或误提交
现象：代码仓库里出现master_secret的序列化结果。原因：调试时把主私钥打印或写进了配置文件，提交时忘了删。解决：主私钥只存在于 PKG 进程内存和受保护的密钥文件里，日志里禁止输出。我一般会在.gitignore里加上密钥文件路径，并且在 CI 里加一条扫描规则，命中就阻断合并。
4.5 哈希函数两边不一致
现象：单独测试加密和解密都正常，端到端跑就失败。原因：加密方用的hash_to_g1和解密方实现里的哈希函数不是同一个，或者输出长度不同。解决：把哈希函数作为初始化参数固定下来，写进配置，两边引用同一个实现。如果资源里允许自定义，务必在文档里标注清楚。
5. 进阶用法：批量身份加密与密文校验
5.1 批量身份加密的写法
实际业务里经常要给一批身份同时加密同一份文件。逐个调用encrypt没问题，但每次都要重新哈希身份点，效率不高。可以把身份点缓存起来：
# 批量加密：同一明文发给多个身份 def encrypt_batch(setup_result, identities, message): group = setup_result["group"] master_public = setup_result["master_public"] results = [] for identity in identities: normalized = identity.strip().lower() identity_point = group.hash_to_g1(normalized) r = group.random_zr() shared = master_public ** r c1 = group.g1 ** r c2 = message ^ group.hash_to_bytes(shared) results.append({ "identity": normalized, "c1": c1, "c2": c2 }) return results参数说明：每个身份仍然要独立生成r，不能因为批量就复用。identity_point如果同一身份频繁加密，可以在业务层做一层缓存，但要注意缓存的生命周期，身份变更后必须失效。
5.2 密文完整性校验
IBE 本身不保证密文完整性，如果密文在传输中被篡改，解密可能得到乱码而不报错。常见做法是在密文里附加一个消息认证码：
import hmac import hashlib # 加密时附加 HMAC def encrypt_with_mac(setup_result, identity, message, mac_key): cipher = encrypt(setup_result, identity, message) mac = hmac.new(mac_key, cipher["c2"], hashlib.sha256).hexdigest() cipher["mac"] = mac return cipher # 解密前先校验 def decrypt_with_mac(private_key, ciphertext, mac_key): expected = hmac.new(mac_key, ciphertext["c2"], hashlib.sha256).hexdigest() if not hmac.compare_digest(expected, ciphertext["mac"]): raise ValueError("密文完整性校验失败") return decrypt(private_key, ciphertext)参数说明：mac_key是收发双方共享的对称密钥，和 IBE 的主密钥体系独立。compare_digest用于防时序攻击，不要用==比较。校验放在解密之前，能提前拦截被篡改的密文。
5.3 一个验证习惯
从那以后我每次改完 IBE 相关代码，都会强制走一遍「初始化 → 提取 → 加密 → 解密 → 断言」的端到端脚本，哪怕只改了一行规范化逻辑。因为这套系统的失败模式太隐蔽了，单测覆盖不到身份字符串的边界情况，只有端到端跑通才能确认参数真的对齐。另外，主私钥的存放路径我会在每次部署前手动确认一遍权限，这个动作看起来多余，但能挡住大部分误操作。希望帮到你。
本文还有配套的精品资源，点击获取
