简介这份毕业设计资源交付的是安全多方计算隐私保护系统的完整源码与项目报告核心服务于计算机相关专业高校学生与从业者可直接作为毕业设计、课程设计或项目初期演示的支撑材料也能够帮助初学者理解隐私计算的基本工程实现。压缩包共190个文件、大小2.58MB除Python脚本与C/C、C#源码外还包含JS/CSS前端页面、JSON/INI配置、jpg/png图片以及md/xlsx文档兼顾算法主体、界面展示、配置文件与说明材料。从包内文件构成来看还涉及串口通信、传感器、时钟等模块说明系统具备较完整的软硬件结合基础适合在此基础上快速搭建演示环境或继续扩展功能。项目已经严格测试稳定运行且易复现附有报告和设计文档若需改动功能可在代码基础上二次开发遇到配置或运行问题也可获得远程指导。目前已有35人学习下载对毕业设计选题、课设作业以及隐私保护方向入门具有较高参考价值。1. 安全多方计算隐私保护系统为什么这是毕业设计里最“有得写”的题目安全多方计算Secure Multi-Party ComputationMPC是隐私保护类毕业设计里性价比最高的选题之一。它不要求你发明新算法但要求你真正理解秘密共享、混淆电路和不经意传输如何协同工作并且能把协议工程化。常见场景是多个参与方各自持有私有数据协同完成统计、查询或机器学习推理但除了最终输出谁也不能看到其他人的原始输入。这篇博客围绕“源码项目报告”这条主线讲清楚从密码学选型、最小实现、参数调优到报告写作的完整路径。适合准备毕设、想快速搭出可演示系统的学生也适合想了解MPC落地细节的工程师。你拿到手的源码往往是一堆模块关键是怎么把它讲成自己的东西。2. 安全多方计算的底层积木秘密共享、混淆电路与不经意传输2.1 你的系统先做“半诚实”还是“恶意”在写代码之前先要确定威胁模型。大部分毕设源码默认采用“半诚实”semi-honest模型所有参与方都按协议运行但会好奇尝试从中间消息推断他人隐私。实现半诚实安全只需要秘密共享和简单的一致性校验而“恶意”malicious模型需要防篡改常见做法是加法秘密共享打开结果的承诺commitment和零知识证明代码量会翻倍。选型理由很直接如果你只有两个月先做半诚实然后在报告里明确写出“当前系统在半诚实模型下安全”这是评审老师最看重的边界声明。下表整理了两种模型在代码层面的差异。维度半诚实Semi-honest恶意Malicious主要威胁诚实地输入、好奇地推理参与方可能篡改输入、退出或任意改协议额外机制无靠协议本身消息认证码、公开可验证秘密共享、Beaver三元组校验通信轮数较低往往多出1~2倍适合场景毕设原型、可信机构合作金融黑名单、分布式密钥管理实现成本几周两个月以上2.2 加法秘密共享从一条公式到一段可跑通的代码加法秘密共享是很多MPC协议的起点。假设模数q足够大一个值x被拆成x1和x2满足(x1 x2) mod q x。拥有x1的一方和拥有x2的一方看到的是完全随机的数。要计算x y每一方本地对自己份额做加法即可不需要通信。要计算x * y就需要交互——因为乘法会破坏密钥分布。常见的做法是通过Beaver三元组预生成随机数a,b和ca*b的份额参与方打开x-a和y-b再本地算出乘积份额。这个人工写一遍才能真正理解协议里的“打开”是什么概念。下面是一段可以直接运行的最小加法共享实现不依赖任何库# mpc_simple.py # 两个参与方通过本地生成随机数完成一次加法共享和重构 import secrets def share(value, modulus): # 生成一个随机份额另一个份额 value - 随机份额 (模意义下) s1 secrets.randbelow(modulus) s2 (value - s1) % modulus return (s1, s2) def reconstruct(shares, modulus): return sum(shares) % modulus # 测试共享一个秘密值 42 MOD 10**9 7 alice_share, bob_share share(42, MOD) print(fAlices share: {alice_share}) # 这个值看起来是随机的 print(fBobs share: {bob_share}) # 这个值也是随机的 print(Reconstructed:, reconstruct([alice_share, bob_share], MOD))逻辑说明secrets.randbelow使用密码学安全随机源避免用random模块导致的可预测风险。share函数返回两个份额分别发送给两个参与方。重构时只需要把两个份额相加并取模。这里的模数MOD选择一个大质数可以保证均匀分布。参数说明如果你要共享负数可以先把value转成非负剩余如果要共享浮点数则需要固定点编码不能直接把浮点放进来。代码中的MOD可以增大但注意x y的结果必须落在-MOD/2到MOD/2之间才不会溢出。2.3 混淆电路和不经意传输什么时候需要它们加法秘密共享擅长算术电路但比较、取绝对值、求最大值这些操作用算术电路表达很贵。另一个常见的MPC构造是姚氏混淆电路Garbled Circuit它把布尔电路加密成一张混淆表接收方通过不经意传输Oblivious TransferOT获取自己输入对应的密钥。OT是“发送方有多个消息接收方拿到其中一个发送方不知道选的是哪个”的协议。毕设里如果做“安全比较年龄”“安全求路线距离”用布尔电路比算术表达更自然做“隐私保护求和”“联邦学习梯度聚合”用秘密共享更划算。实现层面绝大多数源码包并不会自己实现OT而是用一个现成的OT扩展库比如LibOTe或otextension。这里给一个调包提示在Python里用socket模拟两个进程的份额传输是不需要OT的只有当你需要实现比较、分支或查表时才需要引入OT。许多毕业设计源码干脆只做“共享-计算-重构”这条链路也能拿高分关键是把边界讲清楚。另外需要区分的是“秘密共享”和“MPC协议”并不是一回事。秘密共享是一种编码手段而MPC协议规定了如何在这些份额上做加法和乘法、何时打开中间结果、如何同步。很多毕设把秘密共享等同于MPC这会在答辩时被追问。正确写法是加法秘密共享是底层编码GMW或BGW协议规定了使用这种编码的完整计算流程。3. 从源码搭建一套可复现的MPC隐私保护系统目录结构与最小实例3.1 源码目录怎么组织才能打高分一份毕业设计源码的目录不是随意放的。评审老师会直接看结构是否清晰所以按“协议层、通信层、应用层”分层是通用做法。常见结构如下secure_mpc/ ├── protocol/ │ ├── __init__.py │ ├── additive_sharing.py # 加法秘密共享 │ ├── beaver_triple.py # Beaver三元组生成 │ └── garbled_circuit.py # 混淆电路可选 ├── network/ │ ├── channel.py # 点对点安全通道封装 │ └── sync.py # 同步和超时控制 ├── apps/ │ ├── secure_sum.py # 安全求和 │ └── secure_average.py # 安全均值 ├── tests/ │ └── test_protocols.py ├── requirements.txt └── README.md每个目录的职责可以先用一个表说明方便答辩时快速讲清架构模块职责典型接口protocol实现秘密共享、Beaver三元组等密码学操作share(), open(), multiply()network建立加密信道、管理同步send(msg), recv(), batch()apps定义业务场景secure_sum(), secure_average()这个结构的好处是协议层不依赖网络层可以用同步函数直接做单元测试网络层只负责字节流不感知MPC协议apps层把用户输入解析成份额最后把打开结果写成CSV或JSON。README里最好写清楚每个模块的类名和约定评委会从README的第一段决定是否继续看。3.2 两方安全求和的最小实例按上面的结构protocol层先放share和reconstructapps层放一个不依赖真实网络也能跑通的两方求和。下面这段代码用本地变量模拟两个参与方交换份额的过程# apps/secure_sum.py # 两个参与方各自持有私有数字安全计算它们的和 import secrets MOD 4294967291 # 2^32 - 5常用32位安全素数 def share(x): s1 secrets.randbelow(MOD) s2 (x - s1) % MOD return s1, s2 def secure_sum_2pc(alice_x, bob_y): a1, a2 share(alice_x) # Alice生成份额a1自留a2发给Bob b1, b2 share(bob_y) # Bob生成份额b1自留b2发给Alice # 双方各自累加收到的份额与自己保留的份额 alice_local (a1 b2) % MOD bob_local (b1 a2) % MOD # 将两个本地部分发给某个结果方或分别在两个参与方手中 return (alice_local bob_local) % MOD if __name__ __main__: print(secure_sum_2pc(23, 19)) # 预期输出42逻辑说明share函数每次都使用secrets.randbelow(MOD)所以份额在对方视角下都是均匀随机数。真实网络部署时把a2发送给Bob、b2发送给Alice的动作替换成TLS socket上的两个send调用。这里为了本地演示直接用变量赋值模拟消息传输。参数说明MOD为明文模数取2^32 - 5是因为它是大于2^32且适合32位运算的最大质数如果你用Python模数大小对速度影响很小但方案如果改成C这个值可以直接复用。3.3 用pytest守住协议层正确性我一般要求项目里必须有两个测试一个测share的闭环一个测两方求和与明文计算结果相等。用pytest写出来非常短# tests/test_additive_sharing.py from protocol.additive_sharing import share, reconstruct MOD 4294967291 def test_share_reconstruct(): original 123456789 shares share(original, MOD) assert reconstruct(shares, MOD) original def test_share_distribution_not_zero(): # 输入0时份额必须表现为随机分布不能一眼看出输入是0 shares share(0, MOD) assert shares[0] ! 0运行pytest tests/ -v后如果两个测试都通过协议层基本可信。第二个测试的逻辑是如果输入为0份额也必须随机不能恒等于0。如果失败大概率是随机数生成器被固定了种子或者模数选择有问题。在报告里写上“协议层经过两个方向单元测试”比写“系统采用MPC保证安全”更有说服力。4. 让“安全多方计算隐私保护系统”可部署通信加密、三个必调参数与排错4.1 通信层不能裸奔用TLS保护中间消息最小系统用socket传明文份额这不符合“隐私保护系统”的定位。半诚实模型假设参与方遵循协议但不假设网络不被窃听因此参与方之间的信道仍然需要加密。常见做法是使用TLS或者至少在应用层用AES-GCM加密消息。在Python里最简单的是用ssl模块包装TCP socket# network/channel.py (片段) import socket, ssl def connect_tls(peer_host, peer_port, cert_path, key_path): context ssl.create_default_context(ssl.Purpose.SERVER_AUTH) context.load_cert_chain(certfilecert_path, keyfilekey_path) raw_sock socket.create_connection((peer_host, peer_port)) return context.wrap_socket(raw_sock, server_hostnamepeer_host)逻辑说明wrap_socket返回的socket已经自动完成握手之后用sendall发bytes即可。这里只展示了客户端连接写法服务器端需要context.wrap_socket(raw_sock, server_sideTrue)。参数说明cert_path和key_path是参与方各自的证书与私钥在毕设环境里可以用自签名证书证书生成命令放在README.md里例如openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem。注意TLS只解决通道机密性不解决参与方篡改协议的问题报告里要写清这一点。4.2 安全多方计算系统的三个必调参数参数含义推荐起点常见坑明文模数modulus算术电路上的值域2^32 - 5取得太小时有溢出取得过大导致分数/浮点编码溢出批量大小batch_size一次网络调用打包的份额数1000太大会提高内存占用太小会增加通信轮数同步超时timeout_sec等待对方消息的最大秒数5设置过小会在高负载下误判对方宕机批量大小这个参数需要单独解释增大批量不会减少MPC协议的通信轮数但会把多轮消息合并成一次网络往返所以对吞吐提升明显、对延迟几乎无益。如果做交互式安全查询批量不能开太大否则用户会明显感到卡顿。一个简单的配置可以这样写config { modulus: 4294967291, batch_size: 1000, timeout_sec: 5 }4.3 常见排错卡住、算错、内存暴涨卡住优先怀疑同步死锁。两方MPC最常见的卡住是A先发后收、B先收后发由于调度不当造成互相等待。解决方式是固定所有参与方按相同顺序发送或者用一个异步消息队列缓冲。算错优先检查模数和负数编码。Python的%结果恒为非负但C的%有符号数可能返回负数如果源码是C跨语言比对时最容易在这里出错。其次是浮点数MPC里不可能直接传IEEE浮点必须编码成定点数否则打开结果会出现微小偏差。内存暴涨常见于预处理阶段一次性生成大量Beaver三元组导致内存被占满。解决办法是把三元组生成放在后台线程按需补充而不是一次性生成全部。出现异常后先用单机多进程场景复现再用strace或Wireshark抓包看消息时序比直接盯着业务代码发呆更高效。5. 项目报告的高分落点威胁模型声明与一份可复现的实验表格5.1 第一张表先写清“协议-安全模型-适用场景”评审老师翻报告时最想看的是你有没有分清楚“协议”和“应用”。我的建议是放一张表把所有用到的协议都在第一列列出来第二列写安全模型第三列写计算类型第四列写通信轮数第五列写适用场景。比如你自己实现了加法秘密共享和混淆电路可以这样写协议安全模型支持计算通信轮数适用场景加法秘密共享半诚实加、乘需要Beaver三元组O(1)/乘法额外1轮安全求和、安全均值布尔混淆电路半诚实任意布尔电路与电路深度相关安全比较、二分决策写完这张表再在正文里明确写“当前实现只保证半诚实安全假设参与方不会合谋”。这句话能让你避开很多后续追问——评审老师如果问“恶意方攻击怎么办”你直接回答“这是后续工作”比含糊其辞好得多。5.2 用一份实验记录填满“系统测试”章节另一个高分开头是不放笼统的“实现了xx功能”而是放一条能复现的命令。例如python apps/secure_average.py --participants 3 --num-elements 10000 --modulus 4294967291这个命令需要程序打印出“总耗时、通信轮数、每轮收到的字节数”。报告里可以附上三行列出的输出再把这些数据整理成表格。重点不是绝对值多大而是你有“从输入到输出”的验证链测试点包括单个共享闭环、两方求和与明文结果一致、三方均值在数值误差范围内。把这些输出存成CSV并在项目仓库中标明运行环境Python版本、操作系统、CPU架构报告里附上commit hash评审老师就能直接复现。本文还有配套的精品资源点击获取 
长河君 · 2026/9/14 13:51:34 · 阅读 1.2k 安全多方计算隐私保护系统：从秘密共享到混淆电路的完整实现指南
简介这份毕业设计资源交付的是安全多方计算隐私保护系统的完整源码与项目报告核心服务于计算机相关专业高校学生与从业者可直接作为毕业设计、课程设计或项目初期演示的支撑材料也能够帮助初学者理解隐私计算的基本工程实现。压缩包共190个文件、大小2.58MB除Python脚本与C/C、C#源码外还包含JS/CSS前端页面、JSON/INI配置、jpg/png图片以及md/xlsx文档兼顾算法主体、界面展示、配置文件与说明材料。从包内文件构成来看还涉及串口通信、传感器、时钟等模块说明系统具备较完整的软硬件结合基础适合在此基础上快速搭建演示环境或继续扩展功能。项目已经严格测试稳定运行且易复现附有报告和设计文档若需改动功能可在代码基础上二次开发遇到配置或运行问题也可获得远程指导。目前已有35人学习下载对毕业设计选题、课设作业以及隐私保护方向入门具有较高参考价值。1. 安全多方计算隐私保护系统为什么这是毕业设计里最“有得写”的题目安全多方计算Secure Multi-Party ComputationMPC是隐私保护类毕业设计里性价比最高的选题之一。它不要求你发明新算法但要求你真正理解秘密共享、混淆电路和不经意传输如何协同工作并且能把协议工程化。常见场景是多个参与方各自持有私有数据协同完成统计、查询或机器学习推理但除了最终输出谁也不能看到其他人的原始输入。这篇博客围绕“源码项目报告”这条主线讲清楚从密码学选型、最小实现、参数调优到报告写作的完整路径。适合准备毕设、想快速搭出可演示系统的学生也适合想了解MPC落地细节的工程师。你拿到手的源码往往是一堆模块关键是怎么把它讲成自己的东西。2. 安全多方计算的底层积木秘密共享、混淆电路与不经意传输2.1 你的系统先做“半诚实”还是“恶意”在写代码之前先要确定威胁模型。大部分毕设源码默认采用“半诚实”semi-honest模型所有参与方都按协议运行但会好奇尝试从中间消息推断他人隐私。实现半诚实安全只需要秘密共享和简单的一致性校验而“恶意”malicious模型需要防篡改常见做法是加法秘密共享打开结果的承诺commitment和零知识证明代码量会翻倍。选型理由很直接如果你只有两个月先做半诚实然后在报告里明确写出“当前系统在半诚实模型下安全”这是评审老师最看重的边界声明。下表整理了两种模型在代码层面的差异。维度半诚实Semi-honest恶意Malicious主要威胁诚实地输入、好奇地推理参与方可能篡改输入、退出或任意改协议额外机制无靠协议本身消息认证码、公开可验证秘密共享、Beaver三元组校验通信轮数较低往往多出1~2倍适合场景毕设原型、可信机构合作金融黑名单、分布式密钥管理实现成本几周两个月以上2.2 加法秘密共享从一条公式到一段可跑通的代码加法秘密共享是很多MPC协议的起点。假设模数q足够大一个值x被拆成x1和x2满足(x1 x2) mod q x。拥有x1的一方和拥有x2的一方看到的是完全随机的数。要计算x y每一方本地对自己份额做加法即可不需要通信。要计算x * y就需要交互——因为乘法会破坏密钥分布。常见的做法是通过Beaver三元组预生成随机数a,b和ca*b的份额参与方打开x-a和y-b再本地算出乘积份额。这个人工写一遍才能真正理解协议里的“打开”是什么概念。下面是一段可以直接运行的最小加法共享实现不依赖任何库# mpc_simple.py # 两个参与方通过本地生成随机数完成一次加法共享和重构 import secrets def share(value, modulus): # 生成一个随机份额另一个份额 value - 随机份额 (模意义下) s1 secrets.randbelow(modulus) s2 (value - s1) % modulus return (s1, s2) def reconstruct(shares, modulus): return sum(shares) % modulus # 测试共享一个秘密值 42 MOD 10**9 7 alice_share, bob_share share(42, MOD) print(fAlices share: {alice_share}) # 这个值看起来是随机的 print(fBobs share: {bob_share}) # 这个值也是随机的 print(Reconstructed:, reconstruct([alice_share, bob_share], MOD))逻辑说明secrets.randbelow使用密码学安全随机源避免用random模块导致的可预测风险。share函数返回两个份额分别发送给两个参与方。重构时只需要把两个份额相加并取模。这里的模数MOD选择一个大质数可以保证均匀分布。参数说明如果你要共享负数可以先把value转成非负剩余如果要共享浮点数则需要固定点编码不能直接把浮点放进来。代码中的MOD可以增大但注意x y的结果必须落在-MOD/2到MOD/2之间才不会溢出。2.3 混淆电路和不经意传输什么时候需要它们加法秘密共享擅长算术电路但比较、取绝对值、求最大值这些操作用算术电路表达很贵。另一个常见的MPC构造是姚氏混淆电路Garbled Circuit它把布尔电路加密成一张混淆表接收方通过不经意传输Oblivious TransferOT获取自己输入对应的密钥。OT是“发送方有多个消息接收方拿到其中一个发送方不知道选的是哪个”的协议。毕设里如果做“安全比较年龄”“安全求路线距离”用布尔电路比算术表达更自然做“隐私保护求和”“联邦学习梯度聚合”用秘密共享更划算。实现层面绝大多数源码包并不会自己实现OT而是用一个现成的OT扩展库比如LibOTe或otextension。这里给一个调包提示在Python里用socket模拟两个进程的份额传输是不需要OT的只有当你需要实现比较、分支或查表时才需要引入OT。许多毕业设计源码干脆只做“共享-计算-重构”这条链路也能拿高分关键是把边界讲清楚。另外需要区分的是“秘密共享”和“MPC协议”并不是一回事。秘密共享是一种编码手段而MPC协议规定了如何在这些份额上做加法和乘法、何时打开中间结果、如何同步。很多毕设把秘密共享等同于MPC这会在答辩时被追问。正确写法是加法秘密共享是底层编码GMW或BGW协议规定了使用这种编码的完整计算流程。3. 从源码搭建一套可复现的MPC隐私保护系统目录结构与最小实例3.1 源码目录怎么组织才能打高分一份毕业设计源码的目录不是随意放的。评审老师会直接看结构是否清晰所以按“协议层、通信层、应用层”分层是通用做法。常见结构如下secure_mpc/ ├── protocol/ │ ├── __init__.py │ ├── additive_sharing.py # 加法秘密共享 │ ├── beaver_triple.py # Beaver三元组生成 │ └── garbled_circuit.py # 混淆电路可选 ├── network/ │ ├── channel.py # 点对点安全通道封装 │ └── sync.py # 同步和超时控制 ├── apps/ │ ├── secure_sum.py # 安全求和 │ └── secure_average.py # 安全均值 ├── tests/ │ └── test_protocols.py ├── requirements.txt └── README.md每个目录的职责可以先用一个表说明方便答辩时快速讲清架构模块职责典型接口protocol实现秘密共享、Beaver三元组等密码学操作share(), open(), multiply()network建立加密信道、管理同步send(msg), recv(), batch()apps定义业务场景secure_sum(), secure_average()这个结构的好处是协议层不依赖网络层可以用同步函数直接做单元测试网络层只负责字节流不感知MPC协议apps层把用户输入解析成份额最后把打开结果写成CSV或JSON。README里最好写清楚每个模块的类名和约定评委会从README的第一段决定是否继续看。3.2 两方安全求和的最小实例按上面的结构protocol层先放share和reconstructapps层放一个不依赖真实网络也能跑通的两方求和。下面这段代码用本地变量模拟两个参与方交换份额的过程# apps/secure_sum.py # 两个参与方各自持有私有数字安全计算它们的和 import secrets MOD 4294967291 # 2^32 - 5常用32位安全素数 def share(x): s1 secrets.randbelow(MOD) s2 (x - s1) % MOD return s1, s2 def secure_sum_2pc(alice_x, bob_y): a1, a2 share(alice_x) # Alice生成份额a1自留a2发给Bob b1, b2 share(bob_y) # Bob生成份额b1自留b2发给Alice # 双方各自累加收到的份额与自己保留的份额 alice_local (a1 b2) % MOD bob_local (b1 a2) % MOD # 将两个本地部分发给某个结果方或分别在两个参与方手中 return (alice_local bob_local) % MOD if __name__ __main__: print(secure_sum_2pc(23, 19)) # 预期输出42逻辑说明share函数每次都使用secrets.randbelow(MOD)所以份额在对方视角下都是均匀随机数。真实网络部署时把a2发送给Bob、b2发送给Alice的动作替换成TLS socket上的两个send调用。这里为了本地演示直接用变量赋值模拟消息传输。参数说明MOD为明文模数取2^32 - 5是因为它是大于2^32且适合32位运算的最大质数如果你用Python模数大小对速度影响很小但方案如果改成C这个值可以直接复用。3.3 用pytest守住协议层正确性我一般要求项目里必须有两个测试一个测share的闭环一个测两方求和与明文计算结果相等。用pytest写出来非常短# tests/test_additive_sharing.py from protocol.additive_sharing import share, reconstruct MOD 4294967291 def test_share_reconstruct(): original 123456789 shares share(original, MOD) assert reconstruct(shares, MOD) original def test_share_distribution_not_zero(): # 输入0时份额必须表现为随机分布不能一眼看出输入是0 shares share(0, MOD) assert shares[0] ! 0运行pytest tests/ -v后如果两个测试都通过协议层基本可信。第二个测试的逻辑是如果输入为0份额也必须随机不能恒等于0。如果失败大概率是随机数生成器被固定了种子或者模数选择有问题。在报告里写上“协议层经过两个方向单元测试”比写“系统采用MPC保证安全”更有说服力。4. 让“安全多方计算隐私保护系统”可部署通信加密、三个必调参数与排错4.1 通信层不能裸奔用TLS保护中间消息最小系统用socket传明文份额这不符合“隐私保护系统”的定位。半诚实模型假设参与方遵循协议但不假设网络不被窃听因此参与方之间的信道仍然需要加密。常见做法是使用TLS或者至少在应用层用AES-GCM加密消息。在Python里最简单的是用ssl模块包装TCP socket# network/channel.py (片段) import socket, ssl def connect_tls(peer_host, peer_port, cert_path, key_path): context ssl.create_default_context(ssl.Purpose.SERVER_AUTH) context.load_cert_chain(certfilecert_path, keyfilekey_path) raw_sock socket.create_connection((peer_host, peer_port)) return context.wrap_socket(raw_sock, server_hostnamepeer_host)逻辑说明wrap_socket返回的socket已经自动完成握手之后用sendall发bytes即可。这里只展示了客户端连接写法服务器端需要context.wrap_socket(raw_sock, server_sideTrue)。参数说明cert_path和key_path是参与方各自的证书与私钥在毕设环境里可以用自签名证书证书生成命令放在README.md里例如openssl req -x509 -newkey rsa:2048 -nodes -keyout key.pem -out cert.pem。注意TLS只解决通道机密性不解决参与方篡改协议的问题报告里要写清这一点。4.2 安全多方计算系统的三个必调参数参数含义推荐起点常见坑明文模数modulus算术电路上的值域2^32 - 5取得太小时有溢出取得过大导致分数/浮点编码溢出批量大小batch_size一次网络调用打包的份额数1000太大会提高内存占用太小会增加通信轮数同步超时timeout_sec等待对方消息的最大秒数5设置过小会在高负载下误判对方宕机批量大小这个参数需要单独解释增大批量不会减少MPC协议的通信轮数但会把多轮消息合并成一次网络往返所以对吞吐提升明显、对延迟几乎无益。如果做交互式安全查询批量不能开太大否则用户会明显感到卡顿。一个简单的配置可以这样写config { modulus: 4294967291, batch_size: 1000, timeout_sec: 5 }4.3 常见排错卡住、算错、内存暴涨卡住优先怀疑同步死锁。两方MPC最常见的卡住是A先发后收、B先收后发由于调度不当造成互相等待。解决方式是固定所有参与方按相同顺序发送或者用一个异步消息队列缓冲。算错优先检查模数和负数编码。Python的%结果恒为非负但C的%有符号数可能返回负数如果源码是C跨语言比对时最容易在这里出错。其次是浮点数MPC里不可能直接传IEEE浮点必须编码成定点数否则打开结果会出现微小偏差。内存暴涨常见于预处理阶段一次性生成大量Beaver三元组导致内存被占满。解决办法是把三元组生成放在后台线程按需补充而不是一次性生成全部。出现异常后先用单机多进程场景复现再用strace或Wireshark抓包看消息时序比直接盯着业务代码发呆更高效。5. 项目报告的高分落点威胁模型声明与一份可复现的实验表格5.1 第一张表先写清“协议-安全模型-适用场景”评审老师翻报告时最想看的是你有没有分清楚“协议”和“应用”。我的建议是放一张表把所有用到的协议都在第一列列出来第二列写安全模型第三列写计算类型第四列写通信轮数第五列写适用场景。比如你自己实现了加法秘密共享和混淆电路可以这样写协议安全模型支持计算通信轮数适用场景加法秘密共享半诚实加、乘需要Beaver三元组O(1)/乘法额外1轮安全求和、安全均值布尔混淆电路半诚实任意布尔电路与电路深度相关安全比较、二分决策写完这张表再在正文里明确写“当前实现只保证半诚实安全假设参与方不会合谋”。这句话能让你避开很多后续追问——评审老师如果问“恶意方攻击怎么办”你直接回答“这是后续工作”比含糊其辞好得多。5.2 用一份实验记录填满“系统测试”章节另一个高分开头是不放笼统的“实现了xx功能”而是放一条能复现的命令。例如python apps/secure_average.py --participants 3 --num-elements 10000 --modulus 4294967291这个命令需要程序打印出“总耗时、通信轮数、每轮收到的字节数”。报告里可以附上三行列出的输出再把这些数据整理成表格。重点不是绝对值多大而是你有“从输入到输出”的验证链测试点包括单个共享闭环、两方求和与明文结果一致、三方均值在数值误差范围内。把这些输出存成CSV并在项目仓库中标明运行环境Python版本、操作系统、CPU架构报告里附上commit hash评审老师就能直接复现。本文还有配套的精品资源点击获取