diff --git a/paper/chapters/appden01.tex b/paper/chapters/appden01.tex
index 551a99e..5198f56 100644
--- a/paper/chapters/appden01.tex
+++ b/paper/chapters/appden01.tex
@@ -1,8 +1,6 @@
 %% 附录页
 \chapter{附录A\ \ \ \ 英文文献翻译}
 
-% \begin{document}
-
 \section{英文原文}
 
 \begin{center}
@@ -158,8 +156,6 @@ Some of the useful properties of this $(k, n)$ threshold scheme
 
 A different (and somewhat less efficient) threshold scheme was recently developed by G.R. Blakley [2].
 
-% \end{document}
-
 \section{中文翻译}
 
 \begin{center}
diff --git a/paper/chapters/chapter01.tex b/paper/chapters/chapter01.tex
index 97ef2b8..12949bb 100644
--- a/paper/chapters/chapter01.tex
+++ b/paper/chapters/chapter01.tex
@@ -1,14 +1,12 @@
 \chapter{引言}
-
+\vspace{-2cm}
 \section{研究背景和意义}
-
 随着数字经济的快速发展，数据要素化已成为推动经济社会发展的重要驱动力。
 在分布式环境下，数据的安全流通和共享变得愈发重要，
 尤其是在涉及多个参与节点的场景中，如何保证数据传输和存储过程的安全性成为亟待解决的关键问题。
 
 如何结合分布式技术完成数据的安全共享一直是热门研究方向，
-自从2008年Nakamoto
-\cite{nakamoto2008bitcoin}
+自从2008年Nakamoto\upcite{nakamoto2008bitcoin}
 （中本聪）发表了一篇《比特币：一种点对点的电子现金系统》后，
 吸引了无数来自不同学术领域的学者的关注。
 
@@ -26,26 +24,140 @@
 
 \subsection{国外研究现状}
 
-在国外，代理重加密技术的研究始于Blaze\cite{blaze1998divertible}等人1998年提出的概念。
-近年来，随着分布式系统的普及，国际学术界对分布式环境下的数据安全授权展开了深入研究。主要包括：
+在国外，代理重加密技术的研究始于Blaze\upcite{blaze1998divertible}等人1998年提出的概念。
+该研究首次引入了能够在不泄露明文或密钥的情况下，
+将加密数据从一个接收者转换到另一个接收者的密码学机制。
+Blaze等人设计了基于ElGamal加密体系的代理重加密方案，
+奠定了该领域的理论基础。他们引入了单向性和双向性的概念，
+其中单向代理重加密仅允许从一个用户到另一个用户的单向转换，
+而双向则支持双向转换。该研究的突破性贡献在于证明了代理功能可以被赋予转换能力，
+而无需访问原始加密密钥，这在分布式系统中具有重要意义。
+随后，Ateniese等人\upcite{ateniese2006improved}于2006年对该技术进行了改进，
+提出了基于双线性映射的代理重加密方案，解决了原始方案中的安全性和效率问题。
+他们的方案实现了选择性授权功能，使委托者能够更精确地控制代理的重加密能力。
+此后，Canetti和Hohenberger\upcite{canetti2007chosen}进一步研究了代理重加密的安全性定义，
+提出了在选择密文攻击下安全的代理重加密方案，为该技术的实际应用奠定了更坚实的安全理论基础。
 
-1）基于属性的代理重加密方案，实现了更细粒度的访问控制
+近年来，随着分布式系统的普及，国际学术界对分布式环境下的数据安全授权展开了深入研究。
+分布式系统的特点是数据存储和计算分散在多个节点上，这种架构虽然提高了系统的可扩展性和容错性，
+但也带来了复杂的安全挑战，特别是在数据访问控制方面。
+在这种背景下，代理重加密技术因其独特的能够在不暴露原始数据的情况下实现安全数据共享的特性，
+成为研究热点。研究人员围绕分布式环境的特殊需求，对代理重加密技术进行了多方面的创新和扩展。
 
-2）门限代理重加密技术，提高了系统的容错性和可靠性
+基于属性的代理重加密方案是当前研究的重要方向之一，
+该方案将基于属性的加密(Attribute-Based Encryption, ABE)与代理重加密技术相结合，
+实现了更细粒度的访问控制。与传统的基于身份的方案不同，
+基于属性的代理重加密允许数据所有者根据接收者的属性集合定义访问策略，
+只有满足特定属性组合的用户才能解密数据。
+例如，Liang等人\upcite{liang2009provably}进一步研究了支持非单调访问结构的代理重加密技术，
+增强了系统的表达能力。他们在密文策略属性基加密(CPABE)的基础上进行了创新，
+该技术允许发送者基于由属性间的(OR, AND)门构成的布尔函数表示的访问策略分发消息。
+接收者只有在其属性满足密文访问策略时才能成功解密。
+Yu等人\upcite{yu2010achieving}则探讨了基于属性代理重加密在云环境中的应用，
+提出了一种支持属性撤销的方案，解决了动态环境下的安全问题。
+这类方案的优势在于能够实现基于数据特性和用户属性的精细化访问控制，
+非常适合复杂的组织结构和多层级授权场景，特别是在大规模分布式系统中。
 
-3）基于格密码的代理重加密方案，为抵抗量子计算攻击提供了可能
+门限代理重加密技术是另一个重要的研究方向，该技术通过引入$(t, n)$门限机制，
+要求至少$t$个授权代理共同参与才能完成重加密过程，显著提高了系统的容错性和可靠性。
+在传统的代理重加密方案中，单个代理的妥协可能导致整个系统的安全崩溃。
+而门限机制通过分散信任，有效缓解了单点故障和内部攻击的风险。
+这种机制特别适用于高安全要求的分布式系统，如金融交易系统、医疗数据共享平台等。
+此外，门限代理重加密还能有效防止代理的勾结攻击，因为即使部分代理（少于$t$个）合谋，
+也无法获取足够信息进行未授权的重加密。近期研究还探索了基于秘密共享的自适应门限机制，
+可根据网络状态和安全威胁级别动态调整门限参数，进一步增强了系统弹性。
+
+基于格密码的代理重加密方案是为应对量子计算威胁而发展起来的重要技术路线。
+随着量子计算技术的快速发展，传统基于数论难题（如离散对数和大整数分解）
+的密码系统面临被量子算法如Shor算法高效破解的风险。
+而格密码学基于格中的最短向量问题(SVP)和最近向量问题(CVP)等难题，
+被认为具有抗量子计算攻击的潜力。
+Singh等人\upcite{singh2014lattice}首次提出了基于学习有错(Learning With Errors, LWE)
+问题的代理重加密方案，该方案具有严格的安全证明和良好的效率。
+Xagawa和Tanaka\upcite{xagawa2010proxy}则基于环上学习有错(Ring-LWE)
+问题构建了更加高效的方案，减少了密钥大小和计算复杂度。
+这些基于格的方案不仅提供了量子安全性，还常具有更好的计算效率和更小的通信开销，
+使其成为后量子时代分布式系统安全保障的有力候选技术。
+特别地，这类方案在需要长期安全保障的应用场景（如长期医疗记录、政府档案等）
+中具有重要价值，因为这些数据往往需要在几十年内维持机密性，
+而这期间量子计算技术很可能取得突破性进展。
 
 \subsection{国内研究现状}
 
-国内在数据安全授权领域的研究主要集中在以下方面：
+国内学者在数据安全授权领域的研究已取得显著进展，但相较于国际前沿研究仍存在一定差距。
+通过对国内相关文献的梳理和分析，可以发现当前国内研究主要集中在国密算法应用、
+区块链授权机制以及特定领域安全共享方案三个方向。
+这些研究为解决数据安全授权问题提供了具有中国特色的本土化解决思路，
+对推动我国数据安全与隐私保护技术发展具有重要意义。
 
-1）国密算法在代理重加密中的应用研究
+在国密算法在代理重加密中的应用研究方面，
+国内学者主要围绕SM2、SM3和SM4等国家商用密码算法展开了系列深入研究。
+杨勇等\upcite{yangyong2023}提出了一种基于国密算法的智慧社区数据安全传输、
+存储及融合使用系统，该系统充分利用国密算法的安全特性，实现了数据在采集、
+传输、存储和使用全生命周期的安全保护。
+系统通过集成SM2椭圆曲线公钥密码算法进行身份认证与密钥协商，
+采用SM3密码杂凑算法保证数据完整性，并结合SM4分组密码算法实现高效数据加密，
+有效解决了智慧社区场景下数据安全共享难题。
+该研究不仅展示了国密算法在特定应用场景的实用价值，
+同时也为国密算法与现代信息系统的深度融合提供了典型案例。
+李兆斌等\upcite{lizhaobin2023}则探索了无证书密码体制与代理重加密的结合，
+提出了一种基于无证书的门限条件代理重加密方案。
+该方案摒弃了传统公钥基础设施（PKI）中复杂的证书管理流程，
+通过引入门限机制将代理重加密权力分散到多个参与方，避免了单点故障和权力滥用问题。
+方案中采用的条件代理重加密技术允许数据所有者精细控制重加密条件，
+使得数据共享过程更加灵活可控。理论分析和实验结果表明，
+该方案在保证安全性的同时，有效降低了系统管理成本，提高了分布式数据共享效率。
+虽然这些研究在理论上证明了国密算法在代理重加密领域的可行性，
+但在实际应用过程中仍面临密钥生命周期管理复杂、系统兼容性不足以及与异构系统互操作等技术挑战。
 
-2）基于区块链的分布式授权机制研究
+基于区块链的分布式授权机制研究是近年来国内学者关注的研究热点。
+郭庆等\upcite{guoqing2023}设计了一种基于代理重加密的区块链数据受控共享方案，
+该方案巧妙结合了区块链的不可篡改特性与代理重加密的安全特性，
+构建了一种去中心化的数据共享框架。方案中采用SM2算法构建代理重加密机制，
+通过智能合约实现授权规则的自动执行和访问控制，并利用区块链分布式账本记录数据共享全过程，
+确保授权操作的透明性和可追溯性。安全性分析表明，该方案能够有效抵抗选择性密文攻击、
+重放攻击和中间人攻击等多种威胁，保护数据在共享过程中的机密性和完整性。
+性能评估结果显示，在保证安全性的同时，该方案具有可接受的计算和通信开销，
+适用于实际应用场景。
+吴宇和陈丹伟\upcite{wuyu2024}进一步探索了区块链与代理重加密技术的深度融合，
+提出了一种基于Shamir秘密共享的增强型数据安全共享架构。
+该架构引入了密钥分片和门限重构机制，将用户加密密钥分散存储于多个授权节点，
+只有当授权节点数量达到预设门限值时才能重构完整密钥，
+显著提高了系统抗攻击能力和容错性。研究团队还设计了基于智能合约的自动化授权管理模块，
+实现了数据访问权限的精细化控制和动态调整。这类研究充分利用了区块链技术的去中心化、
+不可篡改和可追溯特性，为数据授权提供了新的技术路径。
+然而，区块链技术本身的性能瓶颈、能耗问题以及与现有系统的集成难度，
+仍然制约着这类方案的大规模实际应用。
 
-3）面向特定领域的数据安全共享方案研究
+面向特定领域的数据安全共享方案研究是国内学者针对行业需求开展的应用性研究。
+李雪莲等\upcite{lixiang2022}提出了一种支持属性和代理重加密的区块链数据共享方案，
+该方案针对物联网等数据密集型应用场景，构建了一种兼顾安全性和灵活性的数据共享框架。
+方案创新性地结合了属性加密和代理重加密技术，支持基于数据访问者属性的细粒度访问控制，
+同时利用代理重加密实现安全高效的密文转换。在区块链层面，
+研究团队设计了一种改进的共识机制和数据存储结构，有效降低了系统存储开销并提高了交易处理速度。
+该方案特别关注了移动终端设备的资源限制问题，通过计算任务分配优化和轻量级密码算法应用，
+实现了对资源受限设备的有效支持。实验评估表明，
+该方案在通用物联网平台上具有良好的性能表现和可扩展性，
+为物联网环境下的安全数据共享提供了一种实用解决方案。这些面向特定领域的研究虽然针对性强，
+能够满足特定场景的安全需求，但普遍存在可扩展性不足、通用性较差的问题，
+难以适应复杂多变的跨域应用场景，制约了技术成果的推广应用。
 
-然而，目前的研究仍存在一些不足，如计算效率有待提高、安全性证明不够完备等问题。
+尽管国内在数据安全授权领域已取得一定研究成果，但仍存在诸多不足和挑战。
+首先，在计算效率方面，现有方案普遍存在计算开销大、处理延迟高的问题，
+尤其是在处理大规模数据集和高并发访问场景时表现不佳。
+以郭庆等\upcite{guoqing2023}提出的方案为例，虽然在安全性方面表现出色，
+但区块链存储和共识过程的高延迟限制了其在实时数据共享场景中的应用。
+其次，在安全性证明方面，许多研究缺乏严格的形式化安全性分析和证明，
+难以保证方案在各种复杂攻击模型下的安全性。
+李雪莲等\upcite{lixiang2022}和吴宇等\upcite{wuyu2024}的研究虽然进行了安全性分析，
+但大多局限于特定攻击模型，未能提供全面的安全性保证。
+此外，国内研究在理论创新和基础研究方面投入不足，
+多数工作集中在对国外已有技术的改进和应用，原创性研究相对匮乏。
+例如，李兆斌等\upcite{lizhaobin2023}提出的无证书门限条件代理重加密方案虽有一定创新，
+但核心技术路线仍沿袭了国际已有研究框架。最后，
+现有研究普遍缺乏对实际部署环境的充分考虑，与现实业务流程和系统架构的适配性不足，
+缺乏对性能、可用性和经济性的综合权衡，导致从理论到实践的转化效率低下，
+难以在实际应用中发挥预期效果。
 
 \section{主要内容和工作安排}
 
@@ -61,4 +173,5 @@
 
 第5章为总结与展望，总结研究成果并提出未来的研究方向。
 
-本研究预期在保证数据安全性的同时，实现高效的分布式数据授权管理，为解决数据要素化背景下的数据安全流通问题提供新的技术方案。
+本研究预期在保证数据安全性的同时，实现高效的分布式数据授权管理，
+为解决数据要素化背景下的数据安全流通问题提供新的技术方案。
diff --git a/paper/chapters/chapter02.tex b/paper/chapters/chapter02.tex
index 6cfa83c..dec32a9 100644
--- a/paper/chapters/chapter02.tex
+++ b/paper/chapters/chapter02.tex
@@ -9,7 +9,8 @@
 
 \subsection{基本原理}
 
-在代理重加密系统中，通常涉及三个角色：数据拥有者(Alice)、数据接收者(Bob)和代理服务器。其工作流程如下：
+在代理重加密系统中，通常涉及三个角色：数据拥有者(Alice)、数据接收者(Bob)和代理服务器。
+其工作流程如下：
 
 \begin{enumerate}
 	\item Alice首先使用自己的公钥对数据M进行加密，产生密文C
@@ -23,7 +24,7 @@
 \section{Shamir密码共享方案}
 
 Shamir密码共享方案其核心思想是通过多项式插值来达到一个目的，由Adi Shamir
-\cite{Shamir1979How}
+\upcite{Shamir1979How}
 在1979年提出。其定义如下：
 
 $(t,n)$-Shamir是一种方法，使得一个秘密$S$可以被分割为$n$个片段$\{s_1,\ldots,s_n\}$，
@@ -64,12 +65,39 @@ $n$是总片段数量。Shamir密码共享方案的原理基于数学中的多
 
 这个例子展示了Shamir密码共享方案的基本原理和实际应用。
 
-该方案的安全性基于：
-\begin{itemize}
-	\item 任意$t-1$个或更少的点无法确定一个$t-1$次多项式
-	\item 多项式的系数（除$a_0$外）是随机选择的
-	\item 在有限域上进行运算可以进一步增强安全性
-\end{itemize}
+该方案的安全性建立在几个关键密码学原理之上，这些原理共同构成了一个坚实的安全理论基础。
+首先，从数学角度来看，Shamir秘密共享方案利用了多项式插值的基本特性：
+任意$t-1$个或更少的点无法唯一确定一个$t-1$次多项式。这一特性源自代数学中的基本定理，
+即确定一个$t-1$次多项式需要且仅需要$t$个不同点的信息。当攻击者仅掌握少于阈值$t$的份额时，
+根据插值理论，存在无穷多个不同的$t-1$次多项式通过这些已知点，每个多项式在$x=0$处的值
+（即截距$a_0$）可能各不相同。因此，即使攻击者具备无限的计算能力，
+在纯数学层面上也面临着本质的信息不足，无法从已知份额中推导出原始秘密。
+这种不确定性不是源于计算复杂度，
+而是来自数学原理本身，提供了信息论意义上的安全保证。
+
+其次，方案中多项式系数（除表示秘密的$a_0$外）的随机选择机制进一步增强了系统安全性。
+在实际部署中，这些系数通过密码学安全的随机数生成器产生，确保了足够的熵值和不可预测性。
+随机选择的多项式系数使得每次秘密共享过程产生的份额分布呈现出完全随机的特性，
+任何特定份额集合与原始秘密之间不存在统计相关性。这意味着，
+即使攻击者获取了多次共享同一秘密所产生的不同份额集合，
+也无法通过统计分析或概率推断获得关于原始秘密的任何有用信息。
+随机性作为密码学的核心要素，在此方案中有效地消除了可能的模式和规律，防止了基于历史数据的推断攻击。
+
+此外，在有限域上进行多项式计算为方案提供了额外的安全保障。
+通过选择合适大小的素数域$GF(p)$或扩展域$GF(2^m)$，
+系统可以确保计算过程中的所有中间值和最终份额都限制在有限范围内，
+便于表示和存储。有限域的代数结构使得所有运算都具有模运算特性，
+产生的份额在数学上表现为离散且均匀分布，没有特殊值或模式可供攻击者利用。
+特别是当使用足够大的域（如256位或更大的素数域）时，穷举搜索变得完全不可行，
+即使使用最先进的计算设备也无法在可接受的时间内枚举所有可能的秘密值。
+有限域算术还提供了精确计算的保证，避免了浮点运算可能带来的精度问题和信息泄漏，
+确保方案在理论和实现层面都保持高度安全。
+
+这三个核心原理相互补充，形成了一个多层次的安全体系。
+信息论安全性确保了在数学原理层面的不可破解性；随机系数选择提供了统计学意义上的安全保证；
+而有限域运算则在实现层面上消除了可能的安全漏洞。
+这种多维度的安全设计使得该方案能够在各种实际应用场景中提供可靠的秘密保护，
+即使在面对具备强大计算能力的对手时依然保持其安全特性。
 
 \section{非对称/公钥密码算法}
 
@@ -89,7 +117,7 @@ $n$是总片段数量。Shamir密码共享方案的原理基于数学中的多
 
 这类算法的安全性基于大整数分解问题的难度。
 RSA算法的安全性依赖于将两个大质数的乘积进行因式分解的计算复杂度。
-目前已知的最高效算法仍需要超多项式时间\cite{Lenstra1990GNFS}，这保证了在足够大的密钥长度下的安全性。
+目前已知的最高效算法仍需要超多项式时间\upcite{Lenstra1990GNFS}，这保证了在足够大的密钥长度下的安全性。
 RSA广泛应用于数字签名、密钥交换和数据加密等场景。
 
 \subsection{基于离散对数}
@@ -108,64 +136,146 @@ DSA（数字签名算法）主要用于生成数字签名，而Diffie-Hellman则
 是基于椭圆曲线的公钥密码算法，支持数字签名、密钥交换和数据加密功能。
 
 \section{杂凑算法}
-杂凑算法（也称散列算法或哈希算法）是将任意长度的输入数据转换为固定长度输出的单向函数。
+杂凑算法（也称散列算法或哈希算法）是现代密码学中的核心基础构件，
+其本质是一种数学变换过程，能够将任意长度的输入数据映射转换为固定长度输出的单向函数。
+这种变换过程具有确定性特征，即相同的输入始终产生相同的输出结果。
+杂凑算法的设计理念源于信息压缩理论和随机映射原理，旨在创建一种高效且安全的数据处理机制。
+从密码学角度而言，杂凑函数作为原始数据的"数字指纹"，提供了一种验证信息完整性的有效手段，
+无需保留或传输完整的原始数据。
+杂凑算法的数学模型可表示为一个函数$H: \{0,1\}^* \rightarrow \{0,1\}^n$，
+其中$\{0,1\}^*$代表任意长度的二进制串，而$\{0,1\}^n$表示固定长度为$n$比特的输出集合。
+这种映射关系决定了输入空间远大于输出空间的基本特性，从而导致理论上必然存在碰撞
+（不同输入产生相同输出）。但优秀的杂凑算法设计使得在实际应用中寻找这些碰撞变得极其困难，
+即使使用最先进的计算设备也难以实现。
 
-理想的杂凑算法应满足以下特性：
-\begin{itemize}
-	\item 单向性：由杂凑值无法逆向推导出原始输入
-	\item 抗碰撞性：难以找到具有相同杂凑值的两个不同输入
-	\item 雪崩效应：输入的微小变化会导致输出的显著变化
-\end{itemize}
+理想的杂凑算法应当满足多项严格的安全特性，这些特性共同构成了评判杂凑算法安全性的基本标准。
+首先，单向性（不可逆性）是最为基础的要求，其密码学定义为：对于给定的杂凑值$h$，
+在计算上不可行找到任何消息$m$使得$H(m) = h$。这种特性确保了即使杂凑函数本身是公开的，
+攻击者也无法从杂凑值反向推导出原始数据。
+单向性的实现通常依赖于复杂的非线性变换和不可恢复的信息丢失过程，
+使得任何逆向计算尝试都面临组合爆炸的困境。其次，抗碰撞性包含两个层次的安全要求：
+弱抗碰撞性（又称第二原像抵抗性）指的是给定消息$m_1$，
+在计算上不可行找到不同的消息$m_2 \neq m_1$使得$H(m_1) = H(m_2)$；强抗碰撞性则更为严格，
+要求在计算上不可行找到任意两个不同消息$m_1$和$m_2$，使得$H(m_1) = H(m_2)$。
+强抗碰撞性一般通过生日攻击方法进行理论测试，为应对此类攻击，
+现代杂凑算法的输出长度通常需要达到至少160位以上。
+最后，雪崩效应（又称扩散特性）要求输入数据的微小变化（如单个比特的改变）
+应当导致输出杂凑值的大规模随机化变化（理想情况下约有一半的输出比特发生改变）。
+这一特性确保了杂凑函数对输入的高度敏感性，使得任何有针对性的微调攻击变得极其困难。
 
-常见的杂凑算法包括：
-\begin{itemize}
-	\item MD5：输出128位杂凑值，现已被证明存在安全缺陷\cite{Wang2004Collisions}
-	\item SHA家族：包括SHA-1（160位）、SHA-2（224/256/384/512位）和SHA-3系列
-	\item SM3：中国商用密码杂凑算法标准，输出256位杂凑值
-\end{itemize}
+现代密码学领域中存在多种被广泛应用的杂凑算法，它们在安全性、性能和设计理念上各有特点。
+MD5（消息摘要算法第5版）由Ron Rivest于1991年设计，输出128位杂凑值，
+曾经被广泛应用于软件完整性验证和密码存储。然而，随着计算能力的提升和密码分析技术的发展，
+MD5已被证明存在严重的安全缺陷。2004年王小云教授等研究人员成功构造了MD5的碰撞攻击方法，
+证明了其抗碰撞性的彻底失效\upcite{Wang2004Collisions}。
+该研究不仅在密码学理论研究领域产生了重大影响，还促使各大安全系统加速淘汰MD5算法。
+SHA（安全杂凑算法）家族由美国国家安全局设计并由美国国家标准与技术研究院（NIST）标准化，
+包括多个演进版本。SHA-1输出160位杂凑值，设计于1995年，但目前已被证明不安全；
+SHA-2系列包括SHA-224、SHA-256、SHA-384和SHA-512，分别产生相应位数的输出，
+目前仍被认为是安全的；SHA-3（原名Keccak）采用了与前代算法完全不同的海绵结构设计，
+于2015年正式标准化，提供了更高级别的安全性保证和设计多样性。
+而SM3算法是中国商用密码杂凑算法标准，由国家密码管理局于2010年发布，
+输出256位杂凑值，其内部结构与SHA-256相似但具有针对性的安全增强，
+目前在中国的金融、电子政务等领域得到广泛应用。
 
-杂凑算法广泛应用于数字签名、消息认证码、数据完整性校验和密码存储等场景。
+杂凑算法作为密码学工具箱中的多功能组件，在信息安全领域有着广泛而重要的应用场景。
+在数字签名系统中，杂凑算法被用于生成待签名数据的固定长度摘要，
+这不仅提高了签名过程的效率（签名算法只需处理短小的杂凑值而非可能庞大的原始数据），
+还增强了系统安全性。消息认证码（MAC）技术则将杂凑函数与密钥结合，
+创建了一种能够同时验证数据完整性和来源真实性的机制，
+如广泛使用的HMAC（基于杂凑的消息认证码）结构。在数据完整性校验领域，
+杂凑算法提供了高效可靠的验证手段，被应用于文件传输验证、软件分发和区块链交易确认等场景。
+特别值得一提的是密码存储应用，现代系统普遍采用杂凑函数对用户密码进行单向变换后再存储，
+通常还会结合随机盐值和多轮迭代等技术（如PBKDF2、Bcrypt等算法）以增强抵抗彩虹表和暴力破解的能力。
+此外，杂凑算法还在伪随机数生成、承诺方案、
+密钥派生函数和内容寻址存储等多个前沿技术领域发挥着关键作用，持续推动信息安全技术的发展与创新。
 
 \section{对称密码算法}
-对称密码算法（英语：Symmetric-key algorithm）使用相同的密钥进行加密和解密操作。
-与非对称加密相比，对称加密计算效率更高，
-但密钥分发和管理存在挑战。对称密码主要分为分组密码和流密码两大类。
+对称密码算法（英语：Symmetric-key algorithm）是密码学的核心基础技术，
+其本质特征在于加密与解密过程使用完全相同的密钥。这种对称性使得算法在数学设计上相对简洁，
+在计算效率方面具有显著优势。从历史发展来看，对称密码可追溯至最早的加密系统，
+如古典的凯撒密码、维吉尼亚密码等，但现代对称密码算法在设计理念、
+安全强度和应用范围上已有质的飞跃。现代对称密码通过复杂的置换、替代和扩散操作，
+将明文信息转换为在数学上难以区分于随机数据的密文，确保在不知道密钥的情况下，
+即使拥有完整的密文和算法细节，攻击者也无法恢复原始信息。
+
+对称密码与非对称（公钥）密码相比，其主要优势在于计算效率显著更高，通常快100至1000倍。
+这种效率优势源于对称算法多采用简单位操作（如异或、循环移位等）和查表操作，
+这些操作在通用处理器和专用硬件上均能高效执行。然而，对称密码也面临着固有的限制，
+最突出的是密钥分发和管理问题。由于加密方和解密方必须共享完全相同的密钥，
+如何在不安全信道上安全地传递初始密钥成为一个根本性挑战，
+这一问题通常需要引入公钥密码技术或预共享密钥机制来解决。此外，在多用户环境中，
+对称密码还面临密钥数量随用户数平方级增长的可扩展性问题，
+以及密钥泄露影响范围较广的风险控制问题。基于应用特点和技术实现方式，
+现代对称密码主要分为分组密码和流密码两大类，各自针对不同应用场景进行了优化设计。
 
 \subsection{分组密码算法}
-分组密码将明文分割成固定长度的数据块，然后对每个块进行加密处理。主要特点包括：
+分组密码是对称密码的主要分支，其基本工作原理是将需要加密的明文数据分割成固定长度的数据块
+（称为分组），然后对每个块应用相同的变换函数进行加密处理。
+分组密码的安全性通常建立在香农提出的混淆与扩散原则之上，
+通过多轮迭代的非线性变换实现对密文的高度随机化。分组密码的主要特点在于其结构化的数据处理方式，
+首先，这类算法严格以固定大小的块为单位进行加密，常见的分组大小包括64位和128位，
+这种规则的结构有助于设计整体安全性分析和实现优化。其次，在相同密钥控制下，
+相同的明文块必然产生相同的密文块，这种确定性特征决定了分组密码本身缺乏状态记忆，
+需要额外的机制防止相同模式的泄露。为解决这一问题，分组密码通常需要配合多种工作模式使用，
+如最简单的电子密码本模式（ECB）、密码块链接模式（CBC）、计数器模式（CTR）
+以及认证加密模式（如GCM、CCM）等，这些模式通过不同的链接和反馈机制，实现对长数据的安全处理，
+同时增强了算法的随机性和安全性。
 
-\begin{itemize}
-	\item 以固定大小的块为单位进行加密
-	\item 相同的明文块在相同密钥下产生相同的密文块
-	\item 需要配合工作模式使用（如ECB、CBC、CTR等）以处理超出块大小的数据
-\end{itemize}
+现代密码学史上涌现了多种重要的分组密码算法，
+它们在设计理念和安全强度上代表了不同时期的技术发展水平。数据加密标准（DES）
+是最早被广泛采用的现代分组密码，由IBM设计并于1977年成为美国联邦标准，
+采用56位密钥和64位分组大小。DES的核心是Feistel网络结构，通过16轮的置换和替代操作实现加密。
+尽管DES在设计上具有开创性，但由于其密钥长度限制，现已不再被认为是安全的，
+现代计算设备可通过暴力搜索在数小时内破解DES加密。为延长DES的使用寿命，
+三重DES（3DES）通过级联三个DES操作（加密-解密-加密）实现了更高的安全性，
+有效密钥长度可达112位或168位，但其运算速度明显低于单重DES，且结构复杂度增加了实现难度。
 
-代表算法：
-\begin{itemize}
-	\item DES：56位密钥，64位分组，现已不再安全
-	\item 3DES：基于DES的三重加密，提高安全性但速度较慢
-	\item AES：分组大小128位，支持128/192/256位密钥长度
-	\item SM4：中国商用分组密码标准，128位分组和密钥长度
-\end{itemize}
+高级加密标准（AES，原名Rijndael）作为DES的官方后继者，由NIST于2001年标准化，
+已成为当今最广泛使用的分组密码。AES采用了128位分组大小，支持128/192/256位密钥长度，
+基于代换-置换网络（SPN）结构而非Feistel网络。AES的每轮操作包括字节替代（SubBytes）、
+行移位（ShiftRows）、列混合（MixColumns）和轮密钥加（AddRoundKey）四个步骤，
+密钥长度决定了迭代轮数（10/12/14轮）。AES凭借其卓越的安全性、性能和实现灵活性，
+在全球密码应用中占据主导地位，并已获得包括硬件指令集（如Intel的AES-NI）在内的广泛优化支持。
+SM4作为中国商用分组密码标准，具有128位分组和密钥长度，采用32轮非线性迭代结构，
+在设计上兼顾了安全性和实现效率，已在中国金融、电子政务等领域广泛应用。
 
 \subsection{流密码算法}
-流密码算法产生一个伪随机密钥流，通过与明文逐位（通常是按位异或）组合来生成密文。主要特点：
+流密码算法代表了对称密码的另一种重要范式，其核心理念是生成一个与明文等长的伪随机密钥流
+（keystream），通过与明文进行简单的逐位或逐字节组合操作（通常是按位异或）来实现加密。
+从理论上讲，流密码可以视为一种实现维纳密码（one-time pad）的近似方法，
+通过密码学安全的伪随机数生成器代替理想但不实用的真随机序列。
+流密码的主要技术特点首先体现在其处理单位的灵活性上，这类算法能够逐位或逐字节处理数据，
+无需如分组密码那样等待积累完整的数据块，极大地降低了加密延迟。
+其次，流密码的加密和解密操作通常完全相同，都是将密钥流与数据进行异或操作，
+这种对称性简化了算法实现。由于无需复杂的分组处理和大量的非线性变换，
+流密码特别适合实时性要求高或硬件资源受限的应用场景，如移动通信、物联网设备和高速网络加密。
 
-\begin{itemize}
-	\item 逐位或逐字节处理数据，无需分组
-	\item 加密和解密操作相同
-	\item 适合实时性要求高或硬件资源受限的场景
-\end{itemize}
+在流密码发展历程中，多种算法因其独特的设计和应用价值获得了广泛关注。
+RC4作为最早被广泛应用的软件流密码之一，由Ron Rivest于1987年设计，
+曾在SSL/TLS、WEP（无线加密协议）等多个安全协议中扮演重要角色。
+RC4的核心是一个基于256字节状态表的密钥调度算法和伪随机生成算法，
+其设计极其简洁，使其在软件实现上效率极高。然而，随着密码分析技术的进步，
+RC4被发现存在多种统计偏差和相关性弱点，目前已不再被认为是安全的，
+多数现代安全协议已禁用RC4。ChaCha20作为Salsa20家族的改进版本，
+由Daniel J. Bernstein设计，是现代高性能流密码的代表。
+ChaCha20采用了ARX（加法-循环移位-异或）设计原则，结合了简单指令和复杂状态混合，
+在现代处理器上表现出色，同时保持了较高的抗差分密码分析能力。
+ChaCha20已被纳入TLS 1.3标准中，成为Web安全的重要组成部分，尤其在移动和嵌入式环境中日益流行。
+ZUC（祖冲之算法）作为中国商用流密码标准，专为4G/5G移动通信安全设计
+，结合了线性反馈移位寄存器（LFSR）和非线性函数F，平衡了硬件实现效率与安全强度，
+已在全球移动通信网络中得到广泛应用。
 
-代表算法：
-\begin{itemize}
-	\item RC4：曾广泛应用于SSL/TLS、WEP等协议，但现已被证明存在多种安全问题
-	\item ChaCha20：现代高性能流密码，被用于TLS 1.3和许多安全通信场景
-	\item ZUC：中国商用流密码标准，用于4G/5G移动通信安全
-\end{itemize}
-
-流密码算法通常具有更高的加密速度和更低的实现复杂度，
-特别适合对吞吐量要求高或资源受限的环境，如无线通信和嵌入式系统。
+总体而言，流密码算法因其固有的高效性特征，在特定应用场景中具有显著优势。
+与分组密码相比，流密码通常能够实现更高的加密速度，
+这主要归功于其简化的运算过程和流水线友好的结构设计。在实际应用中，
+流密码每秒可处理的数据量通常是同等安全级别分组密码的数倍甚至数十倍。
+同时，流密码通常具有更低的实现复杂度，尤其适合资源受限环境，如设计高效的硬件实现时，
+流密码往往需要更少的硅面积和更低的功耗。这些特性使流密码成为无线通信、卫星链路、
+视频流加密等对吞吐量要求高的应用场景的首选，同时也是智能卡、RFID标签、
+传感器网络等资源严重受限的嵌入式系统的理想选择。然而，
+流密码在使用时也需特别注意初始化向量（IV）的管理和密钥重用问题，
+不当的实现可能导致严重的安全漏洞，如WEP协议中的RC4应用就因IV重用问题导致了完全破解。
 
 \section{国密算法}
 
@@ -173,174 +283,256 @@ DSA（数字签名算法）主要用于生成数字签名，而Diffie-Hellman则
 
 \subsection{SM2公钥密码算法}
 
-SM2算法是我国基于椭圆曲线密码体制自主研发的公钥密码算法，包含以下三个主要功能：
-
-\begin{itemize}
-	\item SM2-1：数字签名算法
-	\item SM2-2：密钥交换协议
-	\item SM2-3：公钥加密算法
-\end{itemize}
-
+SM2算法是我国基于椭圆曲线密码体制自主研发的公钥密码算法。
 相比于传统RSA签名算法，SM2的主要优势在于：
 \begin{itemize}
 	\item 安全性基础：SM2基于椭圆曲线上的离散对数问题(ECDLP)，而RSA基于整数分解问题(IFP)
-	\item 密钥长度：SM2可以用更短的密钥实现与RSA相同的安全强度\cite{nist800-57r5}
-	\item 计算效率：在同等安全级别下，SM2的椭圆曲线运算比RSA的大整数模幂运算更高效\cite{hankerson2006guide}
+	\item 密钥长度：SM2可以用更短的密钥实现与RSA相同的安全强度\upcite{nist800-57r5}
+	\item 计算效率：在同等安全级别下，SM2的椭圆曲线运算比RSA的大整数模幂运算更高效\upcite{hankerson2006guide}
 \end{itemize}
 
 % 或者也可以将两个引用合并成一个：
-这些优势已在多项研究中得到证实\cite{nist800-57r5,hankerson2006guide}。
+这些优势已在多项研究中得到证实\upcite{nist800-57r5,hankerson2006guide}。
 
 \subsection{SM3密码杂凑算法}
 
-SM3哈希算法是密码体系的重要组成部分，是一种将任意长度的消息$M$映射为定长字符串$H(M)$的单向散列函数，
-$H(M)$称为$M$的消息摘要。我国基于对SHA-256中的压缩函数进行自主研发并取得重大突破，
-国产哈希算法SM3随之诞生。与SHA-256相似，SM3算法同样适用于数字签名、消息认证及随机数生成等场景，
-且其安全性略高于SHA-256\cite{SM3StandardGroup2013}，国家密码管理局规定SM2算法中的哈希算法为SM3。
+SM3密码杂凑算法是我国自主研发的密码学标准，作为密码体系的重要组成部分，
+其核心功能是将任意长度的消息$M$映射为固定长度为256比特的字符串$H(M)$，
+这一字符串被称为消息$M$的摘要或杂凑值。SM3算法源于对SHA-256算法压缩函数的深入研究和创新改进，
+通过引入新的设计理念，在保持高效性的同时提升了安全强度。与国际主流的SHA-256算法相比，
+SM3在抗碰撞性和抗差分分析能力方面具有一定优势，这使得SM3成为我国商用密码应用的首选哈希算法。
+根据国家密码管理局的规定，SM2公钥密码算法中默认采用SM3作为标准哈希函数。
 
-SM3算法对长度为$l$比特的消息$M$，经过填充和迭代压缩，最终输出一个256比特的杂凑值。算法主要包含以下步骤：
+SM3算法的应用范围广泛，主要用于数字签名中的消息摘要生成、消息认证码的构造、
+伪随机数生成器的设计以及完整性校验等多种密码应用场景。此外，在电子政务、金融交易、
+云计算安全等领域，SM3也发挥着不可替代的作用。该算法通过精心设计的填充机制和迭代压缩结构，
+确保了即使输入消息发生微小变化，输出的杂凑值也会呈现出显著差异，
+体现了优秀哈希函数应具备的雪崩效应特性。
 
 \subsubsection{填充过程}
-设有长度为$l$比特的消息$M$：
-\begin{enumerate}
-	\item 首先将比特"1"添加至消息$M$末尾
-	\item 添加$k$个"0"，其中$k$是满足公式$(l + 1 + k) \bmod 512 \equiv 448$的最小非负整数
-	\item 添加一个64位比特串，表示$l$的值
-	\item 填充后的消息$M$比特长度为512的倍数
-\end{enumerate}
+
+SM3算法的填充过程是确保输入消息长度标准化的关键步骤。对于任意长度为$l$比特的原始消息$M$，
+首先在其末尾添加一个"1"比特，这一步骤标记了原始消息的结束位置，为后续处理奠定基础。
+接着，算法会在"1"比特之后添加$k$个"0"比特，
+其中$k$的值需满足等式$(l + 1 + k) \bmod 512 \equiv 448$，且为满足该等式的最小非负整数。
+这种设计确保填充后的消息长度在模512的意义下恰好比448多1比特，
+为存储消息长度信息预留了64比特空间。
+
+填充的最后一步是添加一个64位的比特串，该比特串是原始消息长度$l$的二进制表示。
+将消息长度作为填充的一部分，可以有效防止长度扩展攻击，增强算法的安全性。
+经过完整的填充过程后，消息$M$的总比特长度成为512的整数倍，这样设计的目的是便于后续的分组处理，
+使每个分组大小统一为512比特，符合压缩函数的输入要求。填充机制的设计兼顾了安全性与实现效率，
+是SM3算法整体结构的重要组成部分。
 
 \subsubsection{迭代压缩过程}
-分为以下两个主要步骤：
-
-1. 消息分块与扩展：
-\begin{itemize}
-	\item 将填充好的消息$M$按每512比特分成$n$个组，其中$M = M^{(1)} || M^{(2)} || ... || M^{(n)}$
-	\item 将上述分组按消息扩展算法扩展成132个消息字$W_j$，用于压缩函数$CF$
-\end{itemize}
-
-2. 压缩与输出：
-\begin{itemize}
-	\item 对分组后的消息$M$进行$n$次迭代压缩
-	\item $V_i = CF(V_{i-1}, M^{(i)})$，其中$i = 1,2,...,n$
-	\item $CF$为压缩函数，通过最终的迭代值得到一个256比特的杂凑值
-\end{itemize}
 
+SM3算法的核心在于其迭代压缩过程，该过程可分为消息分块与扩展、压缩与输出两个主要阶段。
+在消息分块与扩展阶段，首先将经过填充处理的消息$M$按每512比特划分为$n$个分组，
+表示为$M = M^{(1)} \parallel M^{(2)} \parallel \ldots \parallel M^{(n)}$，
+其中$\parallel$表示消息连接操作。对于每个512比特的分组$M^{(i)}$，
+SM3采用精心设计的消息扩展算法将其扩展为132个32位消息字$W_j$（其中$j=0,1,\ldots,131$）。
+这些扩展后的消息字分为两部分：$W_0$至$W_{67}$用于主要的压缩计算，
+而$W'_0$至$W'_{63}$（即$W_{68}$至$W_{131}$）作为辅助变量参与运算，共同构成压缩函数$CF$的输入。
 
+在压缩与输出阶段，SM3算法对分组后的消息进行$n$次迭代压缩操作。迭代过程始于初始值$V_0$，
+该值为SM3算法预定义的常量。对于每个分组$M^{(i)}$，执行压缩函数$V_i = CF(V_{i-1}, M^{(i)})$，
+其中$i = 1,2,\ldots,n$。压缩函数$CF$内部实现了复杂的非线性变换、逻辑运算和位移操作，
+通过多轮迭代增强了算法的混淆性和扩散性。经过$n$次迭代后，
+最终的$V_n$即为原始消息$M$的256比特杂凑值。
+这种基于迭代结构的设计使SM3算法能够高效处理任意长度的输入消息，同时保证输出杂凑值的密码学强度，
+为各类应用提供了可靠的数据完整性和认证服务。
 
 \subsection{SM4分组密码算法}
 
-SM4是一种对称密钥分组密码算法，是SMS4算法的标准化版本。其主要特征如下：
+SM4是一种对称密钥分组密码算法，是中国商用密码标准的核心组成部分。该算法由中国密码学家设计开发，
+于2012年正式由国家密码管理局颁布为国家标准（GB/T 32907-2016），并逐渐获得国际认可。
+SM4算法是SMS4算法的标准化版本，最初设计用于无线局域网产品中提供数据保密性服务，
+后来广泛应用于国内金融、政务和商业领域的信息安全保障。
 
 \subsubsection{基本参数}
-\begin{itemize}
-	\item 分组大小：128位
-	\item 密钥长度：128位
-	\item 加密轮数：32轮
-\end{itemize}
+
+SM4算法采用固定的分组大小和密钥长度，具有较高的安全性。其分组大小为128位（16字节），
+这意味着每次加密操作处理128位的明文数据，生成相同长度的密文输出。
+算法使用的密钥长度同样为128位，在当前计算能力下提供足够的密钥空间抵抗暴力破解攻击。
+SM4采用32轮迭代结构进行加密，每轮使用由主密钥派生的不同轮密钥，确保充分的混淆和扩散效果。
+这些参数设计使SM4算法在安全性与性能之间达到良好平衡，既能抵抗已知的密码分析攻击，
+又能保证在各种硬件平台上的高效实现。
 
 \subsubsection{算法结构}
-\begin{itemize}
-	\item 采用"置换-置换"(SP)网络结构，区别于传统的"置换-替代"(SPN)结构
-	\item 包含非线性变换函数（S盒）：将4字节输入转换为4字节输出
-	\item 线性变换：用于增强加密强度
-	\item 轮函数：每轮使用$F$函数处理数据块和轮密钥
-\end{itemize}
+
+SM4算法采用"置换-置换"(SP, Substitution-Permutation)网络结构，
+这是一种区别于传统"置换-替代"(SPN, Substitution-Permutation Network)结构的设计。
+在传统SPN结构中，通常先进行非线性替代（S盒），然后进行线性变换；
+而SM4的SP结构则采用了两次不同类型的置换操作组合，使其具有独特的密码学特性。
+SM4算法包含一个重要的非线性变换函数（S盒），该S盒将4字节（32位）输入转换为4字节输出，
+是算法安全性的关键组成部分。S盒设计具有高度非线性，以抵抗差分和线性密码分析攻击。
+
+除非线性变换外，SM4还包含线性变换操作，通过位移和异或等运算实现比特位的扩散，增强加密强度。
+这种线性变换确保单一比特的变化能迅速扩散到整个数据块中，提高算法抵抗统计分析的能力。
+SM4的轮函数是其核心组成部分，每轮使用$F$函数处理数据块和轮密钥。
+$F$函数结合了非线性S盒变换和线性变换，通过异或运算将轮密钥引入计算过程，
+实现了良好的混淆和扩散效果。轮函数的迭代应用确保了即使明文中的微小变化也会导致密文的显著不同，
+体现了雪崩效应的密码学特性。
 
 \subsubsection{密钥处理}
-\begin{itemize}
-	\item 密钥扩展：从128位主密钥生成32个轮密钥
-	\item 轮密钥加：通过异或运算将轮密钥与数据块结合
-\end{itemize}
+
+SM4算法的密钥处理包括两个主要方面：密钥扩展和轮密钥加。
+密钥扩展是一个从128位主密钥生成32个轮密钥的过程，每个轮密钥用于一个加密轮。
+这一过程采用递归方式进行，通过固定的系统参数（FK）和常量（CK）与主密钥进行复杂运算，
+生成互不相同的轮密钥序列。密钥扩展算法确保生成的轮密钥具有足够的随机性和复杂性，
+防止通过分析轮密钥间关系推导出主密钥。
+
+轮密钥加是将轮密钥与数据块结合的过程，SM4通过异或（XOR）运算实现这一操作。
+在每轮加密中，当前轮的密钥与经过非线性变换的数据进行异或，产生新的中间值用于下一轮计算。
+这种设计使得密钥信息充分融入加密过程，确保即使攻击者获得部分轮中的数据，也难以推导出密钥信息。
+SM4的密钥处理机制简洁而高效，既保证了算法的安全性，又便于硬件实现和优化。
 
 \subsubsection{工作模式}
-SM4支持多种标准工作模式：
-\begin{itemize}
-	\item ECB（电子密码本模式）
-	\item CBC（密码分组链接模式）
-	\item CTR（计数器模式）
-	\item 其他标准分组密码工作模式
-\end{itemize}
+
+SM4作为分组密码算法，支持多种标准工作模式，以适应不同应用场景的安全需求。
+ECB（Electronic CodeBook，电子密码本模式）是最简单的工作模式，直接对每个数据块独立加密，
+适用于加密随机数据或短消息，但不推荐用于长文本或有规律数据的加密。
+CBC（Cipher Block Chaining，密码分组链接模式）通过引入前一密文块与当前明文块异或的机制，
+实现数据块间的关联，增强安全性，适合加密需要完整性保护的大量数据。
+
+CTR（Counter，计数器模式）将分组密码转变为流密码使用，通过加密递增的计数器值生成密钥流，
+与明文异或得到密文，具有并行处理能力和随机访问特性，适合高吞吐量应用场景。除上述主要模式外，
+SM4还支持CFB（Cipher Feedback，密码反馈模式）、OFB（Output Feedback，输出反馈模式）和
+GCM（Galois/Counter Mode，伽罗瓦/计数器模式）等其他标准分组密码工作模式。
+这些多样化的工作模式使SM4算法能够灵活应对不同应用场景的安全需求，
+从而在国家密码体系中发挥重要作用。
 
 \subsection{混合加密机制}
-
 \subsubsection{基本原理}
-由于公钥密码算法是基于复杂的代数计算，其计算效率远低于对称密码算法。
-因此，在需要加密大量数据时，直接使用公钥密码进行加密并不是最优选择。
-为解决这一问题，现代密码学中普遍采用KEM/DEM混合加密机制：
+公钥密码算法作为非对称密码体系的核心组成部分，其安全性建立在数学难题之上，
+如离散对数问题、整数分解问题或格问题等。这类算法在提供高强度安全保障的同时，
+由于涉及复杂的代数运算和高阶数学计算，导致其计算效率显著低于对称密码算法。
+在密码学的实际应用场景中，尤其是需要加密大量数据的环境下，
+若直接采用公钥密码体制进行全程加密，将会引发严重的性能瓶颈问题，
+导致系统处理能力大幅下降，无法满足现代信息系统对高效率处理的需求。
+例如，RSA 算法的加解密操作涉及大整数幂模运算，
+其计算复杂度远高于 AES 等对称加密算法中的简单位操作和替代变换。
+实验数据表明，在相同硬件环境下，公钥密码算法的加解密速度通常比对称密码算法慢数百至数千倍，
+这种效率差异在资源受限的环境（如物联网设备、移动终端等）中尤为明显。
 
-\begin{itemize}
-	\item KEM (Key-Encapsulation Mechanism)：密钥封装机制
-	\item DEM (Data-Encapsulation Mechanism)：数据封装机制
-\end{itemize}
+为了克服这一根本性局限并充分发挥两类密码算法的各自优势，
+现代密码学在实际应用中采用了一种优化的混合架构，
+即 KEM/DEM (Key-Encapsulation Mechanism/Data-Encapsulation Mechanism) 混合加密机制。
+该机制将密码系统划分为两个功能互补的组件：
+密钥封装机制（KEM）负责安全地传输或建立加密所需的对称密钥，
+而数据封装机制（DEM）则利用该对称密钥高效地加密实际数据。
+这种设计理念源于密码学中的"分而治之"策略，通过功能分离和专门化处理，
+实现了安全性与效率的最优平衡。在 KEM 组件中，虽然公钥算法的计算开销较大，
+但由于其仅处理长度有限的密钥材料（通常为 128 至 256 比特），
+因此性能影响得到有效控制；而在 DEM 组件中，
+对称算法的高效特性使得大量数据的加密处理能够快速完成，从而确保了整体系统的性能表现。
 
 \subsubsection{工作机制}
-KEM/DEM混合加密方案的工作流程如下：
+KEM/DEM 混合加密方案在实际应用中遵循一套精心设计的工作流程，
+其详细步骤可分为加密和解密两个关键阶段。在数据加密阶段，
+系统首先通过密码学安全的随机数生成器产生一个高质量的随机会话密钥，
+该密钥通常具有足够的熵值以抵抗暴力攻击，长度根据后续使用的对称加密算法而定，
+如 AES-256 则需要 256 比特的密钥长度。这一随机生成的会话密钥仅用于当前通信会话，
+确保了密钥材料的新鲜性和唯一性，有效防止重放攻击和密钥重用带来的安全风险。
 
-1. 数据加密过程：
-\begin{itemize}
-	\item DEM使用对称加密算法加密原始数据
-	\item 随机生成用于对称加密的会话密钥
-	\item KEM使用公钥加密算法对会话密钥进行加密
-\end{itemize}
+随后，系统将 DEM 组件与刚生成的会话密钥结合，
+选择适当的对称加密算法（如 AES、SM4 或 ChaCha20 等）对原始明文数据进行加密处理。
+在此过程中，可以配合适当的工作模式（如 GCM、CCM 或 EAX 等认证加密模式）
+同时保障数据的机密性和完整性。对称加密操作完成后，产生的密文将等待传输，
+而用于生成该密文的会话密钥则需要安全传递给接收方。此时，KEM 组件发挥作用，
+系统使用接收方的公钥通过非对称加密算法（如 RSA、椭圆曲线或后量子算法如 Kyber）
+对会话密钥进行加密封装，形成密钥密文。最终，数据密文和密钥密文共同组成完整的加密消息，
+通过不安全信道传输给接收方。
 
-2. 数据解密过程：
-\begin{itemize}
-	\item 接收方首先使用私钥解密得到会话密钥
-	\item 使用恢复的会话密钥解密获得原始数据
-\end{itemize}
+在数据解密阶段，接收方首先使用自己的私钥对接收到的密钥密文进行解密操作，
+从而恢复出发送方使用的会话密钥。这一步骤体现了 KEM 的核心价值：安全地实现密钥交换。
+获取会话密钥后，接收方再使用该密钥和相同的对称算法及参数设置，
+对数据密文进行解密操作，最终恢复出原始明文信息。整个解密过程严格遵循加密的逆向顺序，
+确保密码系统的正确性和一致性。
 
 \subsubsection{优势特点}
-KEM/DEM混合加密机制具有以下优势：
+KEM/DEM 混合加密机制通过巧妙结合公钥密码与对称密码的特性，展现出多方面的技术优势，
+使其成为现代安全通信的基石。在效率方面，该机制实现了计算资源的最优分配，
+将计算密集型的公钥密码操作限制在短小的会话密钥处理上，
+而将高速高效的对称密码算法用于大量数据的加密，从而显著提升了整体系统的处理能力。
+实际性能测试表明，与纯公钥加密相比，混合加密方案能够提供数百倍甚至千倍的速度提升，
+特别是在处理大型文件或高带宽通信时，这种优势尤为明显。例如，在加密 1GB 数据时，
+纯 RSA 加密可能需要数小时完成，而采用 AES 对称加密仅需几秒钟，
+混合方案的总耗时仅比纯对称加密略长，但安全性得到显著提升。
 
-\begin{enumerate}
-	\item 效率提升
-	      \begin{itemize}
-		      \item 大量数据使用高效的对称加密
-		      \item 仅对短小的会话密钥使用公钥加密
-		      \item 显著提高整体加解密效率
-	      \end{itemize}
+在安全性保障方面，混合加密机制在理论上继承了两种密码体制的安全优势，
+形成了防护层次更深的安全架构。一方面，公钥密码算法确保了会话密钥交换过程的安全性，
+有效解决了密钥分发这一传统密码学的核心难题；另一方面，
+对称密码算法通过高强度的数据变换保障了明文信息的机密性。
+更为重要的是，由于每次通信会话均使用新生成的随机会话密钥，
+即使某次通信的密钥被攻击者获取，也不会危及其他通信场景的安全，
+实现了会话隔离。若系统配置得当，还可支持前向安全性，
+确保当前密钥泄露不会危及先前通信的安全性。
 
-	\item 安全性保障
-	      \begin{itemize}
-		      \item 结合对称加密和非对称加密的安全优势
-		      \item 即使会话密钥泄露也不影响其他通信场景
-		      \item 支持前向安全性
-	      \end{itemize}
-
-	\item 通信优化
-	      \begin{itemize}
-		      \item 减少加密数据的传输量
-		      \item 降低网络带宽占用
-		      \item 提高通信效率
-	      \end{itemize}
-\end{enumerate}
+在通信优化层面，混合加密机制通过精细化的加密处理策略，
+有效降低了加密数据的冗余度和传输量。由于公钥加密算法通常会导致密文膨胀
+（如 RSA 加密会使输出长度等于密钥模数长度），若直接用于大量数据将造成显著的传输开销；
+而混合方案中，这种膨胀仅限于会话密钥的加密结果，数据本身在对称加密下几乎不产生额外膨胀。
+这一特性在带宽受限的网络环境中尤为重要，能够有效降低网络资源占用，
+提高通信效率，减少传输延迟，从而增强用户体验和系统响应能力。
 
 \subsubsection{应用场景}
-混合加密机制在以下场景中具有广泛应用：
+混合加密机制凭借其卓越的安全性和效率特性，已在现代信息安全体系中获得广泛应用。
+在安全通信协议领域，如 TLS/SSL 协议族中，混合加密是核心安全机制。
+当用户浏览器与网站建立安全连接时，首先通过非对称密码完成身份认证和会话密钥协商，
+随后的数据传输则采用协商好的会话密钥和对称算法进行加密。
+这一机制使得 HTTPS 能够在保障安全的同时，提供接近 HTTP 的性能体验，
+支撑了全球范围内的安全电子商务和敏感信息交换。
 
-\begin{itemize}
-	\item 安全通信协议（如TLS/SSL）
-	\item 数据加密传输
-	\item 文件加密存储
-	\item 密钥交换协议
-\end{itemize}
+在数据加密传输场景中，混合加密为点对点通信提供了理想的安全框架。
+现代即时通讯应用如 Signal、WhatsApp 等均采用类似机制实现端到端加密，
+确保消息内容仅对通信双方可见。在这类应用中，长期身份密钥用于验证通信方身份并安全地协商临时会话密钥，而实际消息内容则使用高效的对称加密进行保护。这种设计不仅保障了通信安全，还支持高频率的消息收发和多媒体内容传输。
+
+在文件加密存储方面，混合加密同样发挥着不可替代的作用。
+当用户使用 PGP 或 GPG 等工具加密敏感文件时，系统会自动生成随机会话密钥，
+用对称算法加密文件内容，再用接收方的公钥加密会话密钥。
+这种机制使得大型文件的加密处理变得高效可行，同时保持了公钥体系的安全特性，
+如支持多接收方和身份验证等。类似地，在云存储平台的客户端加密方案中，
+混合加密被广泛采用，确保数据在离开用户设备前已被加密，仅持有正确密钥的授权用户能够访问原始内容。
+
+在密钥交换协议领域，混合加密思想同样得到了应用和发展。例如，
+在基于 Diffie-Hellman 的密钥交换协议中，通信双方通过公开交换信息导出共享的会话密钥，
+随后使用该密钥和对称算法进行数据加密。这一过程从本质上看，
+仍然遵循着 KEM/DEM 的基本思路：利用非对称机制安全地建立共享密钥，
+再利用对称机制高效地保护数据。现代密钥管理基础设施也普遍采用类似架构，
+以平衡安全需求与性能要求。
 
 \subsubsection{具体实现}
-在实践中，KEM/DEM 混合加密机制通常采用以下算法组合：
-1. KEM (密钥封装机制) 实现选择：
-\begin{itemize}
-	\item 基于椭圆曲线的算法：SM2、ECIES、ECDH 等
-	\item 基于整数分解的算法：RSA-OAEP、RSA-KEM 等
-	\item 基于格的后量子算法：CRYSTALS-Kyber、NTRU 等
-	\item 基于配对的算法：IBE-KEM (基于身份的加密)
-\end{itemize}
+在实际系统部署中，KEM/DEM 混合加密机制可通过多种算法组合实现，
+根据具体应用场景的安全需求和性能约束进行灵活选择。
+密钥封装机制（KEM）负责安全地传递会话密钥，其实现通常基于成熟的公钥密码算法。
+在传统密码学范畴内，基于椭圆曲线的算法如 SM2、ECIES 和 ECDH
+等因其较短的密钥长度和较高的运算效率而受到广泛青睐。
+这类算法基于椭圆曲线离散对数问题的难解性，在提供同等安全强度的情况下，
+相比基于整数分解问题的算法拥有更小的计算和存储开销。
+例如，160 比特的椭圆曲线密钥安全性约等同于 1024 比特的 RSA 密钥，
+这一特性使其特别适合资源受限环境。
 
-2. DEM (数据封装机制) 实现选择：
-\begin{itemize}
-	\item 分组密码及其工作模式：SM4-GCM、AES-GCM、ChaCha20-Poly1305 等
-	\item 结合 AEAD (认证加密与关联数据) 模式确保机密性和完整性
-	\item 针对高性能需求的流密码或轻量级分组密码：SNOW、AEGIS 等
-\end{itemize}
+基于整数分解的算法如 RSA-OAEP 和 RSA-KEM 等，虽然计算开销相对较大，
+但因其广泛部署的基础设施和成熟的安全分析，仍在多种系统中扮演重要角色。
+RSA-OAEP（最优非对称加密填充）在传统 RSA 加密基础上增加了随机填充机制，
+有效抵抗了多种已知攻击。随着量子计算技术的发展，后量子密码学日益受到关注，
+基于格的算法如 CRYSTALS-Kyber 和 NTRU 等被设计为能够抵抗量子计算机攻击的替代方案。
+美国国家标准与技术研究院（NIST）正在推进后量子密码标准化进程，
+以应对未来可能出现的量子威胁。此外，基于配对的算法如基于身份的加密（IBE-KEM）
+在特定应用场景中提供了密钥管理的简化方案，使用户身份信息直接作为公钥，
+省去了复杂的证书管理过程。
+
+数据封装机制（DEM）侧重于高效处理大量数据，通常选择性能卓越的对称密码算法。
+分组密码及其工作模式是当前最主流的选择，如 SM4-GCM、AES-GCM 和 ChaCha20-Poly1305 等。
+这些算法组合不仅提供了高强度的保密性，还通过 AEAD（认证加密与关联数据）
+模式集成了数据完整性和真实性保护。GCM（伽罗瓦计数器模式）作为一种高效的认证加密模式，
+支持数据加密的同时生成认证标签，可有效防止密文篡改攻击，已成为现代安全协议的标准配置。
+在高性能计算环境下，系统可能优先选择经过硬件加速的算法，如采用 AES-NI 指令集的 AES 实现；
+而在内存和计算资源有限的嵌入式系统中，轻量级算法如 PRESENT、SIMON 或 SPECK 等可能更为适合。
+对于对延迟特别敏感的应用，如高频交易或实时通信，
+流密码或优化的 AEGIS 等算法族可提供极低的处理延迟和高吞吐量，
+满足严格的时间约束要求。
 
 \section{本章小结}
 
diff --git a/paper/chapters/chapter03.tex b/paper/chapters/chapter03.tex
index e38141b..63ee13f 100644
--- a/paper/chapters/chapter03.tex
+++ b/paper/chapters/chapter03.tex
@@ -1,213 +1,622 @@
 \chapter{系统设计与实现方案}
 \section{总体设计}
-随着数字经济和分布式系统的发展，数据安全流通和共享日益重要。
-本系统结合门限密码学与代理重加密技术，提出了一种面向分布式环境的代理重加密解决方案。
-该方案具有以下主要特点：
+分布式环境下数据安全共享已成为数字经济发展的关键挑战与机遇。随着云计算、区块链、
+物联网等技术的广泛应用，数据作为核心生产要素的价值日益凸显，
+然而数据安全流通与共享面临诸多技术障碍。传统密码学体系在分布式场景下暴露出密钥管理复杂、
+授权控制僵化、计算效率有限等问题，无法满足现代数据共享生态的灵活性与安全性需求。
+本系统通过创新性地结合门限密码学与代理重加密技术，构建了一种适应分布式环境的安全数据共享架构，
+实现了数据价值流动与隐私保护的平衡。
 
-\begin{itemize}
-	\item 基于国密算法，确保系统的安全性和合规性
-	\item 采用分布式架构，支持多节点协同工作
-	\item 实现高效的数据授权和共享机制
-	\item 保证数据隐私和完整性
-\end{itemize}
+本方案的核心技术创新在于将门限密码学的分布式信任机制与代理重加密的授权转换能力有机融合，
+形成了一个既保障数据机密性又支持灵活授权的安全框架。在该框架中，
+数据所有者无需直接向被授权方透露原始密钥，而是通过可信代理节点集合执行密文转换，
+实现了"数据不动、密钥不共享"的安全共享范式。特别地，
+本系统采用国家密码管理局认证的商用密码算法（即"国密算法"）作为基础密码组件，
+不仅确保了系统的安全强度，还满足了国内关键信息基础设施的合规要求。
+国密算法（如SM2、SM4、SM3等）在密码学理论基础和工程实现上均已成熟，
+其安全性已经过充分论证和广泛验证，为系统提供了坚实的安全基础。
 
+本系统的分布式架构设计充分考虑了现代数据生态的复杂性和动态性，通过多节点协同工作机制，
+有效规避了中心化系统的单点故障风险和性能瓶颈问题。系统中的代理节点群采用分布式共识协议进行协调，
+每个节点仅持有部分重加密密钥，任何单一节点的妥协都不会危及整体系统安全。
+这种设计不仅提高了系统的容错性和可用性，还通过负载均衡和并行处理能力，
+实现了处理大规模并发请求的能力，满足企业级应用和大数据环境的性能要求。
+分布式架构还具备良好的可扩展性，系统可根据实际需求动态调整节点数量和分布，
+适应不同规模和复杂度的应用场景。
 
-系统整体架构包含以下主要组件：
+在数据授权与共享机制方面，本系统实现了基于密码学的细粒度访问控制和高效授权流程。
+通过代理重加密技术，数据所有者能够在不解密原始数据的情况下，
+直接生成针对特定接收方的重加密转换密钥，实现了一次加密多次授权的高效模式。
+系统支持基于属性、角色和上下文的复合授权策略，能够灵活应对各类复杂的数据共享场景。
+授权过程中的所有操作均留有密码学证据，支持后期审计和追溯，形成了完整的责任链条。
+此外，系统还实现了授权的时效性控制和动态撤销机制，
+使数据所有者能够全程掌控数据的生命周期和使用范围，有效防止数据泄露和未授权使用。
 
-\begin{itemize}
-	\item 数据拥有方：负责数据的加密和密钥管理
-	\item 数据请求方：负责数据的解密和使用
-	\item 代理节点：执行重加密操作
-	\item 中心服务器：管理节点信息和协调通信
-	\item 数据存储：保存加密数据和相关元信息
-\end{itemize}
+数据隐私和完整性保护是本系统的核心安全目标。通过多层次的密码学保护措施，
+系统确保了数据在存储、传输和处理全生命周期中的安全性。首先，所有敏感数据均经过强加密后存储，
+即使存储系统被攻破，攻击者也无法获取有意义的信息。其次，
+数据的完整性通过数字签名和密码学哈希链进行保护，任何未授权的修改都将被即时检测。
+再者，系统实现了安全多方计算的部分功能，支持在密文状态下进行特定的数据分析和处理，
+减少了数据暴露的机会。最后，系统采用零知识证明技术验证授权资格，
+使得身份认证和权限检查过程不泄露额外信息，进一步增强了隐私保护能力。
+
+本系统的架构由五个核心组件有机组成，形成了一个完整的数据安全共享生态。
+数据拥有方作为原始数据的控制者，负责定义数据安全策略、执行初始加密和管理授权关系，
+通过用户友好的接口工具，即使非技术专业人员也能轻松管理复杂的数据共享关系。
+数据请求方作为被授权的数据使用者，能够在不获取原始密钥的情况下，
+通过系统提供的解密工具访问授权数据，同时系统确保请求方仅能访问被授权的数据部分，
+实现了最小权限原则。代理节点群构成系统的核心功能层，负责执行重加密变换操作，
+每个节点仅持有部分重加密密钥，需要多个节点协作才能完成完整的重加密过程，
+这种门限机制有效防止了单点故障和内部威胁。中心服务器扮演协调者角色，管理系统元数据、
+节点信息和通信协议，但不接触敏感数据或密钥材料，降低了安全风险。
+数据存储组件采用安全分布式存储技术，支持多种后端存储系统集成，
+通过密文索引技术实现了高效检索与隐私保护的平衡。
+这五大组件通过标准化的接口和安全通信协议紧密协作，共同构建了一个安全、高效、
+可扩展的数据共享平台。
 
 
 \section{核心算法设计}
 \subsection{算法设计}
 
-基于国密算法的分布式代理重加密技术共包含6个核心算法，以下详细说明各算法的设计。
-假设数据持有方为Alice，接收方为Bob，代理重加密节点为node。
+基于国密算法的分布式代理重加密技术是一种融合了门限密码学与国密标准的创新性密码机制，
+该技术旨在解决数据共享过程中的安全与隐私保护问题。本节详细阐述系统的六个核心算法设计，
+包括其数学基础、安全性分析与实现细节。在以下阐述中，我们假设数据持有方为Alice，
+数据接收方为Bob，分布式代理重加密节点为node，并通过严格的密码学理论与实践相结合，
+构建一套完整的密码学协议框架。
 
 \subsubsection{算法框架概述}
 
+本算法框架基于门限密码学理论与国密算法标准，通过分布式代理节点实现安全的重加密操作，
+有效规避了单点信任问题。系统采用混合加密结构，结合SM2、SM3和SM4等国密算法，
+既保证了安全性，又兼顾了效率。框架主要由六个算法构成，形成了一个完整的密码学协议体系：
+
 \begin{enumerate}
 	\item \textbf{密钥生成算法} ($\mathsf{KeyGen}$)：
-	      \begin{itemize}
-		      \item 输入：系统参数
-		      \item 输出：Alice和Bob的公私钥对 $(pk_A,sk_A)$和$(pk_B,sk_B)$
-		      \item 功能：生成用户的公私钥对
-	      \end{itemize}
+
+	      密钥生成算法是分布式代理重加密系统的基础，负责为通信双方Alice和Bob创建安全的公私钥对。
+	      该算法基于SM2椭圆曲线密码算法实现，其安全性基于椭圆曲线离散对数问题(ECDLP)的计算困难性。
+	      在国密标准中，SM2采用的椭圆曲线参数为256位，提供约128位的安全强度，足以抵抗现有的计算能力。
+
+	      算法执行过程首先初始化系统参数，包括选择合适的椭圆曲线$E$、基点$G$以及阶$n$。
+	      对于每个用户，算法随机选择一个私钥$sk \in Z_n^*$，然后计算相应的公钥$pk = sk \cdot G$。
+	      具体地，对于Alice，生成私钥$sk_A$和公钥$pk_A = sk_A \cdot G$；
+	      对于Bob，生成私钥$sk_B$和公钥$pk_B = sk_B \cdot G$。
+
+	      值得注意的是，私钥生成过程中使用了高质量的随机数生成器，确保私钥的不可预测性。
+	      同时，系统还实现了密钥的安全存储与管理机制，防止密钥泄露。此外，为提高系统安全性，
+	      可以设置密钥定期更新策略，减少长期使用同一密钥带来的风险。
 
 	\item \textbf{重加密密钥生成算法} ($\mathsf{ReKeyGen}$)：
-	      \begin{itemize}
-		      \item 输入：
-		            \begin{itemize}
-			            \item Alice的私钥 $sk_A$
-			            \item Bob的公钥 $pk_B$
-			            \item 代理服务器节点数量 $n$
-			            \item 门限值 $t$
-		            \end{itemize}
-		      \item 输出：重加密密钥集合 $\{rk_i\}_{i=1}^n$
-		      \item 说明：$i$ 指代每个代理服务器节点的编号
-	      \end{itemize}
+
+	      重加密密钥生成算法是实现代理重加密功能的核心，它允许Alice创建特殊的转换密钥，
+	      使代理节点能够在不获知明文的情况下将Alice加密的密文转换为Bob可解密的形式。
+	      该算法融合了门限密码学与SM2算法，实现了密钥的安全分发与重构。
+
+	      算法接收Alice的私钥$sk_A$、Bob的公钥$pk_B$、代理服务器节点数量$n$和门限值$t$作为输入。
+	      在密钥生成过程中，首先计算基础重加密密钥$rk_{A \rightarrow B} = sk_A^{-1} \cdot sk_B \cdot G$。
+	      然后，使用Shamir $(t,n)$门限秘密共享方案将此密钥分割为$n$份。
+	      具体地，选择一个$t-1$次多项式$f(x) = rk_{A \rightarrow B} + a_1x + a_2x^2 + \cdots + a_{t-1}x^{t-1}$，
+	      其中$a_1, a_2, \ldots, a_{t-1}$是随机选择的系数。对于每个节点$i$，
+	      计算其重加密密钥片段$rk_i = f(i)$。
+
+	      这种设计确保了即使部分代理节点（少于$t$个）被攻破，攻击者也无法重构完整的重加密密钥，
+	      从而保障了系统的安全性。同时，通过分布式架构，系统避免了单点故障问题，
+	      提高了整体的可靠性与容错能力。
 
 	\item \textbf{加密算法} ($\mathsf{Encrypt}$)：
-	      \begin{itemize}
-		      \item 输入：
-		            \begin{itemize}
-			            \item Alice的公钥 $pk_A$
-			            \item 明文 $m$
-		            \end{itemize}
-		      \item 输出：密文 $c$
-		      \item 实现细节：
-		            \begin{itemize}
-			            \item 采用混合加密机制
-			            \item 使用SM4实现对称加密
-			            \item 对称密钥在加密过程中随机生成
-			            \item 使用SM3实现密钥派生函数KDF
-			            \item 公钥加密保护对称密钥
-		            \end{itemize}
-	      \end{itemize}
+
+	      加密算法负责将Alice的明文信息转换为密文形式，是整个系统的重要组成部分。
+	      该算法采用混合加密机制，结合了对称加密与公钥加密的优势，既保证了安全性，
+	      又提高了处理效率。
+
+	      具体实现中，算法首先随机生成一个会话密钥$k$，然后使用SM4对称加密算法和该密钥对明文$m$进行加密，
+	      得到密文部分$c_1 = \mathsf{SM4}_k(m)$。SM4采用128位密钥长度和128位分组大小，
+	      提供足够的安全强度。随后，使用SM3哈希算法实现密钥派生函数KDF，对会话密钥进行处理，
+	      增强安全性。最后，使用Alice的公钥$pk_A$通过SM2算法对处理后的会话密钥进行加密，
+	      得到密文的另一部分$c_2 = \mathsf{SM2}_{pk_A}(k)$。最终密文$c = (c_1, c_2)$包含这两部分组成。
+
+	      这种混合加密方案充分利用了对称加密的高效性和公钥加密的安全密钥交换能力，
+	      特别适合大量数据的加密处理。同时，通过引入随机会话密钥，即使对相同明文多次加密，
+	      也会产生不同的密文，有效防止了统计分析攻击。
 
 	\item \textbf{解密算法} ($\mathsf{Decrypt}$)：
-	      \begin{itemize}
-		      \item 输入：
-		            \begin{itemize}
-			            \item Alice的私钥 $sk_A$
-			            \item 密文 $c$
-		            \end{itemize}
-		      \item 输出：明文 $m$
-		      \item 过程：
-		            \begin{itemize}
-			            \item 首先用私钥解密得到对称密钥
-			            \item 再用对称密钥解密获得明文
-		            \end{itemize}
-	      \end{itemize}
+
+	      解密算法是加密算法的逆过程，允许Alice使用其私钥对密文进行解密，恢复原始明文信息。
+	      该算法同样采用混合解密机制，先解密会话密钥，再使用会话密钥解密数据。
+
+	      算法接收Alice的私钥$sk_A$和密文$c = (c_1, c_2)$作为输入。首先，
+	      使用私钥$sk_A$和SM2解密算法对$c_2$进行解密，
+	      恢复会话密钥$k = \mathsf{SM2}_{sk_A}^{-1}(c_2)$。然后，
+	      使用该会话密钥和SM4解密算法对$c_1$进行解密，得到原始明文$m = \mathsf{SM4}_k^{-1}(c_1)$。
+
+	      在实际实现中，解密过程还包括密钥完整性验证和数据有效性检查，
+	      以防止篡改和伪造攻击。此外，系统还实现了安全的内存管理机制，
+	      确保解密后的明文和会话密钥不会在内存中长时间保留，减少信息泄露的风险。
 
 	\item \textbf{重加密算法} ($\mathsf{ReEnc}$)：
-	      \begin{itemize}
-		      \item 输入：
-		            \begin{itemize}
-			            \item 重加密密钥片段 $rk_i$
-			            \item 密文 $c$
-		            \end{itemize}
-		      \item 输出：重加密密文 $c'$
-		      \item 执行：代理服务器节点进行重加密运算
-	      \end{itemize}
+
+	      重加密算法是代理节点执行的核心操作，允许在不解密密文的情况下，
+	      将Alice的密文转换为Bob可解密的形式。这一算法实现了数据共享的安全机制，
+	      同时保护了数据持有方的隐私。
+
+	      算法接收重加密密钥片段$rk_i$和密文$c = (c_1, c_2)$作为输入。
+	      重加密过程主要针对密文中的公钥加密部分$c_2$进行处理，
+	      而保持对称加密部分$c_1$不变。具体地，
+	      代理节点使用其持有的重加密密钥片段$rk_i$对$c_2$进行变换，
+	      得到部分重加密结果$c_{2,i}' = \mathsf{ReEnc}_{rk_i}(c_2)$。
+
+	      在分布式环境中，当至少$t$个代理节点完成重加密操作后，
+	      这些部分结果可以通过拉格朗日插值法合并，
+	      得到完整的重加密密文$c' = (c_1, c_2')$。这种设计确保了即使部分代理节点不可用或被攻击，
+	      系统仍能正常运行，提高了整体的鲁棒性。同时，由于重加密过程中不需要解密原始密文，
+	      代理节点无法获知明文内容，有效保护了数据隐私。
 
 	\item \textbf{重加密密文解密算法} ($\mathsf{ReDecrypt}$)：
-	      \begin{itemize}
-		      \item 输入：
-		            \begin{itemize}
-			            \item Bob的公钥 $pk_B$
-			            \item Bob的私钥 $sk_B$
-			            \item Alice的公钥 $pk_A$
-			            \item 重加密密文 $c'$
-		            \end{itemize}
-		      \item 输出：明文 $m$
-	      \end{itemize}
+
+	      重加密密文解密算法是系统的最后一个核心组件，
+	      允许数据接收方Bob使用自己的私钥解密经过重加密的密文，
+	      获取原始明文信息。该算法完成了整个安全数据共享流程。
+
+	      算法接收Bob的公私钥对$(pk_B, sk_B)$、Alice的公钥$pk_A$以及重加密密文$c' = (c_1, c_2')$作为输入。
+	      解密过程首先使用Bob的私钥$sk_B$对重加密后的$c_2'$部分进行处理，
+	      恢复出会话密钥$k = \mathsf{ReDecrypt}_{sk_B}(c_2', pk_A)$。
+	      然后，使用该会话密钥和SM4解密算法对$c_1$进行解密，得到原始明文$m = \mathsf{SM4}_k^{-1}(c_1)$。
+
+	      为确保解密过程的安全性，系统实现了完整性检验机制，
+	      验证重加密密文的有效性和完整性。此外，为防止重放攻击，
+	      系统还可以在密文中嵌入时间戳或随机挑战值。在实际应用中，
+	      系统还可以结合访问控制机制，确保只有授权用户才能执行解密操作，
+	      进一步增强数据共享的安全性。
+
 \end{enumerate}
 
-\subsubsection{算法安全性考虑}
+通过以上六个核心算法的紧密配合，基于国密算法的分布式代理重加密技术实现了安全、
+高效的数据共享机制。该系统不仅满足了密码学安全性要求，
+还考虑了实际应用中的效率和易用性因素，为数据安全共享提供了一套完整的解决方案。
 
-系统的安全性基于以下几个方面：
-\begin{itemize}
-	\item 基于国密算法SM2、SM3、SM4的密码学安全性
-	\item 门限机制提供的分布式安全保障
-	\item 混合加密机制的效率与安全性平衡
-	\item 重加密过程中的数据保密性
-\end{itemize}
+\subsubsection{算法安全性考虑}
+系统安全性的基础建立在多层次的防护机制之上，通过算法选择、架构设计和协议实现等方面的综合考量，
+形成了完整的安全保障体系。作为密码系统，其安全性必须经受理论分析和实践验证的双重检验，
+不仅关注算法本身的密码学强度，还需考虑实现环境、应用场景和攻击模型等多方面因素。
+
+基于国密算法SM2、SM3、SM4的密码学安全性构成了系统的第一道防线。
+SM2椭圆曲线密码算法采用256位密钥长度，其安全性基于椭圆曲线离散对数问题(ECDLP)的计算难度。
+在当前计算能力下，破解SM2需要超过$2^{128}$次运算，远超现有计算资源的可行范围。
+SM2算法的设计参数经过精心选择，采用特定的椭圆曲线参数和基点，有效抵抗了包括MOV降阶攻击、
+小子群攻击在内的多种已知攻击方法。SM3密码杂凑算法输出256位杂凑值，
+其压缩函数采用了类似SHA-2的结构但增加了设计创新，如扩展消息词的非线性变换和反馈结构，
+增强了抗碰撞性和抗差分分析能力。根据当前分析，找到SM3的完整碰撞需要$2^{128}$级别的计算复杂度，
+而寻找原像则需要$2^{256}$级别的复杂度，提供了足够的安全边际。
+SM4分组密码通过32轮非线性迭代结构，实现了良好的混淆和扩散特性，
+已被证明能够有效抵抗线性密码分析和差分密码分析等经典攻击方法。
+这三种算法已通过国家密码管理局的安全评估和认证，在理论安全性和工程实现上均达到了较高水平。
+
+门限机制为系统提供了分布式信任架构，从根本上改变了传统密码系统的单点信任模型。
+通过$(t,n)$门限方案，系统实现了"分布式信任、
+集体决策"的安全理念——只有当至少$t$个授权代理节点协作时，重加密操作才能被正确执行。
+这种机制首先提高了系统抵抗外部攻击的能力，因为攻击者需要同时攻破多个独立节点才能获取完整密钥，
+显著增加了攻击成本。其次，门限机制有效防范了内部威胁，即使存在恶意内部人员，
+只要其控制的节点数量少于阈值$t$，系统整体安全性仍能得到保障。从信息论角度看，
+门限密码方案的安全性基于：任意$t-1$个或更少的点无法确定一个$t-1$次多项式；
+多项式的系数（除$a_0$外）是随机选择的；在有限域上进行运算可以进一步增强安全性。
+系统实现中特别注意了安全随机数的生成、门限参数的选择以及节点间安全通信等关键因素，
+确保门限机制在理论和实践层面的安全性一致。
+
+混合加密机制在保障系统安全性的同时，实现了计算和存储效率的优化。
+该机制遵循"密钥封装机制/数据封装机制"(KEM/DEM)设计范式，结合了对称加密和非对称加密的各自优势。
+具体而言，系统使用高效的SM4对称加密算法处理大量原始数据，
+而仅对短小的会话密钥使用计算密集型的SM2非对称加密。
+这种设计不仅显著提高了系统处理大规模数据的能力，还通过密钥分层管理增强了安全性。
+安全分析表明，混合加密机制的整体安全强度由其最弱环节决定，
+在本系统中各组件的安全参数经过精心配置，确保安全强度的均衡和充分。
+特别是，系统为每个加密数据对象生成独立的随机SM4密钥，并通过密钥派生函数增加了密钥熵源，
+有效防止了密钥重用和相关密钥攻击。混合加密还支持前向安全性，即使某次会话的密钥泄露，
+也不会危及其他通信场景的安全性，限制了安全事件的影响范围。
+
+重加密过程中的数据保密性是系统安全设计的核心考量。代理重加密技术允许第三方（代理）
+在不知道明文内容的情况下，将使用一个公钥加密的密文转换为使用另一个公钥加密的密文。
+在本系统中，重加密过程始终在密文域进行，原始数据和明文密钥在任何时候都不会在代理节点上出现。
+重加密转换密钥的设计确保了代理可以执行密文转换，但无法推导出用户的私钥或解密数据内容。
+系统采用单向代理重加密方案，即转换只能从委托者到被委托者单向进行，
+防止未授权的反向信息流动。此外，重加密密钥具有一次性使用特性，
+每次授权使用独立派生的重加密密钥，即使某次授权的重加密密钥泄露，
+也不会影响其他授权关系的安全性。系统还实现了密钥革新机制，允许定期或在安全事件后更新密钥材料，
+提供长期运行环境下的持续安全保障。
+
+通过这些多层次、相互补充的安全机制，系统构建了深度防御的安全架构，
+即使在部分组件受到攻击的情况下，整体安全目标仍能保持。
+系统安全性的设计不仅考虑了当前已知的攻击方法，
+还预留了足够的安全边际以应对未来可能出现的新型攻击技术，
+体现了前瞻性和可持续性的安全理念。
 
 \subsection{关键技术}
-系统采用了以下关键技术：
+本系统的安全框架建立在多种先进密码学技术的协同应用基础上，形成了一套完整的密码学防护体系。
+作为系统的技术核心，这些密码学组件相互配合，各司其职，共同构建了一个安全可靠的数据共享环境。
+系统采用的关键技术涵盖了现代密码学的多个重要领域，从基础密码算法到高级密码协议，
+形成了层次分明的安全架构。
 
-\begin{itemize}
-	\item SM2椭圆曲线密码算法：用于非对称加密
-	\item SM3哈希算法：确保数据完整性
-	\item SM4分组密码：实现高效的对称加密
-	\item 门限密码技术：支持分布式密钥管理
-	\item 混合加密机制：结合对称和非对称加密优势
-\end{itemize}
+SM2椭圆曲线密码算法作为系统的非对称加密基础，在身份认证、
+密钥交换和数字签名等核心安全功能中发挥关键作用。SM2算法基于椭圆曲线密码体制，
+采用256位密钥长度，安全强度等同于3072位RSA，但计算效率和存储开销显著优于后者。
+在本系统中，SM2主要用于生成用户密钥对、保护重加密转换密钥、实现安全的身份认证和授权证明。
+相比国际通用的ECDSA和ECDH，SM2在算法结构上进行了特定优化，并集成了签名、
+加密和密钥交换功能，简化了系统设计。SM2的密钥生成过程采用确定性随机数生成算法，
+增强了系统在各类环境中的安全稳定性，尤其适合分布式节点的一致性要求。
+
+SM3密码杂凑算法在系统中承担数据完整性保护和密码派生的核心功能。
+作为一种高安全强度的密码杂凑算法，SM3输出256位杂凑值，
+设计上结合了SHA-2系列的成熟架构和独特的安全增强机制，
+可有效抵抗包括生日攻击在内的多种密码分析方法。在本系统实现中，
+SM3被广泛应用于数据签名验证、完整性校验、密钥派生和随机数生成等多个安全环节。
+特别是在分布式环境下，SM3用于生成数据的唯一标识符，构建密码学证据链，
+确保即使在复杂的网络环境中，数据传输和转换过程的完整性也能得到严格保障。
+系统还利用SM3构建了基于哈希的消息认证码（HMAC-SM3），
+在不引入额外密钥的情况下提供数据源认证功能。
+
+SM4分组密码算法作为系统高效数据加密的主力组件，负责对大量原始数据进行保护。
+SM4采用128位分组和密钥长度，32轮非线性迭代结构，在安全性和性能之间取得了良好平衡。
+系统中的SM4实现采用GCM（伽罗华计数器模式）操作模式，提供认证加密与关联数据（AEAD）功能，
+同时保障数据的机密性、完整性和真实性。相比AES等国际算法，
+SM4在国内密码硬件（如密码卡、安全芯片）上通常能获得更好的硬件加速支持，
+在保证安全性的同时提升了系统处理大量数据的能力。
+系统设计中特别考虑了SM4在各类计算平台上的优化实现，包括针对现代处理器指令集
+（如SIMD、AVX）的高效软件实现和面向专用硬件的优化版本，
+确保即使在资源受限环境中也能提供满意的加密性能。
+
+门限密码技术是本系统分布式安全架构的理论基础，通过数学方法将密钥或密码操作分散到多个参与方，
+形成分布式信任机制。系统采用$(t,n)$门限方案，要求至少$t$个（$t \leq n$）
+授权参与者协作才能完成关键密码操作，任何少于阈值$t$的参与者集合无法获取有效信息或执行受保护功能。
+在重加密密钥管理方面，系统实现了基于多项式插值的Shamir秘密共享机制，
+将重加密转换密钥分片存储在不同代理节点上。门限机制不仅防止了单点攻击风险，
+还提升了系统的容错性和可用性，即使部分节点失效或遭受攻击，
+系统整体仍能保持正常运行。此外，系统还融合了主动安全的门限签名和门限解密协议，
+支持在不重构完整密钥的情况下协作完成签名和解密操作，从而最大限度减少密钥暴露的风险。
+
+混合加密机制通过巧妙结合对称和非对称加密算法，实现了安全性和效率的最优平衡。
+在本系统中，混合加密遵循"数据加密密钥"和"密钥加密密钥"的两级密钥结构：
+首先使用高效的SM4对称算法加密大量原始数据；然后使用SM2非对称算法保护SM4会话密钥。
+这种设计充分发挥了对称加密的高效率和非对称加密的密钥管理优势，
+显著提升了系统处理大规模数据的能力。在实际操作中，系统为每个数据对象生成随机的SM4密钥，
+确保即使同一用户的不同数据也使用不同的加密密钥，增强了系统的前向安全性。
+混合加密机制还支持"一次加密，多次授权"的高效数据共享模式，
+数据拥有方只需向代理节点提供重加密转换密钥，无需重新加密原始数据即可实现对新接收方的安全授权，
+大幅降低了数据共享的计算和通信开销。
+
+上述关键技术通过精心设计的系统架构有机集成，形成了一个安全、高效、
+可扩展的分布式数据共享解决方案。每项技术都针对特定安全需求进行了优化配置，
+共同构建了多层次、纵深防御的安全体系，为系统提供了坚实的技术基础。
 
 \section{实现细节}
 基于国密算法的分布式代理重加密技术共包含6个算法，分别为密钥对生成算法$KeyGen$、
 重加密密钥生成算法$ReKeyGen$、加密$Enc$、解密算法$Dec$、重加密算法$ReEnc$、
 重加密密文解密算法$ReDec$。
 
-假设数据持有方为Alice，接收方为Bob，代理重加密节点为node，具体算法框架如下：
-
-$KeyGen$：Alice和Bob随机生成各自公私钥对$(pk_A,sk_A)$和$(pk_B,sk_B)$；
-
-$ReKeyGen$：输入Alice的私钥$sk_A$，Bob的公钥$pk_B$，所有代理服务器节点数量$n$和门限$t$，
-输出重加密密钥集合$rk$。这里的$i$指的是代理服务器节点的$ID$；
-
-$Enc$：输入Alice的公钥$pk_A$和明文$m$，输出密文$ct$；这里并不是直接使用$pk_A$加密明文$m$，
-因为会导致性能过低问题，在底层加密时，使用的是对称加密算法，
-在本文中使用$SM4$实现对称加密算法。其对称密钥是在加密过程中随机产生，
-对称加密密钥由公钥加密保护；生成对称密钥时，需要用到密码哈希函数构建的密钥派生函数$KDF$，
-本文中使用$SM3$算法实现该$KDF$函数；
-
-$Dec$：输入Alice的私钥$sk_A$和密文$ct$，输出明文$m$；这里是加密算法的逆过程，
-即用$sk_A$解密得到对称加密密钥，再解密密文；
-
-$ReEnc$：代理服务器节点输入重加密密钥片段$rk_i$和密文$ct$，输出重加密密文$ct'$；
-
-$ReDec$：输入Bob的公钥$pk_B$和私钥$sk_B$，A的公钥$pk_A$，重加密密文$ct'$，输出明文$m$。基于国密算法的分布式代理重加密实现流程如图所示。
-
-密钥对生成算法$KeyGen$步骤如下：
-
+\subsection{开发环境}
+首先我们进行开发环境的搭建。
 \begin{enumerate}
-	\item 选择适当的椭圆曲线参数和基点G
-	\item 随机生成私钥$sk$
-	\item 计算公钥$pk = sk * G$
-	\item 输出密钥对$(pk,sk)$
+	\item 安装基础依赖，检查并安装clang、make、cmake工具。如图\ref{fig:dependencies}所示
+	      \begin{figure}[H]
+		      \centering
+		      \includegraphics[width=0.95\textwidth]{images/chapters/dependencies.png}
+		      \caption{安装基础依赖}
+		      \label{fig:dependencies}
+	      \end{figure}
 \end{enumerate}
 
-重加密密钥生成算法$ReKeyGen$步骤如下：
+\subsection{代码实现}
+\begin{itemize}
+	\item 定义变量类型
+	      \begin{itemize}
+		      \item \begin{lstlisting}
+            point = Tuple[int, int]
+            capsule = Tuple[point, point, int]
+            \end{lstlisting}
+		      \item 选择一个素数的循环群，是群的生成元。
+		            该软件系统选择我国商用密码选定的素数域椭圆曲线的参数，如图\ref{fig:sm2_parameter}所示：
+		            \begin{figure}[H]
+			            \begin{center}
+				            \includegraphics[width=0.95\textwidth]{images/chapters/sm2_parameter.png}
+			            \end{center}
+			            \caption{国密SM2椭圆曲线参数}\label{fig:sm2_parameter}
+		            \end{figure}
+	      \end{itemize}
+	\item 定义椭圆曲线上的运算
+	      \begin{lstlisting}
+          multiply(a: point, n: int) -> point: # 椭圆曲线上的倍点运算
 
-\begin{enumerate}
-	\item 输入Alice的私钥$sk_A$和Bob的公钥$pk_B$
-	\item 选择随机数$r$作为重加密密钥
-	\item 计算$rk = r * sk_A * pk_B$
-	\item 输出重加密密钥$rk$
-\end{enumerate}
+          add(a: point, b: point) -> point: # 椭圆曲线上，两个点的加法运算
 
-加密算法$Enc$步骤如下：
+          inv(a: int, n: int) -> int: # 椭圆曲线上，求a关于素数p的逆元运算
 
-\begin{enumerate}
-	\item 输入公钥$pk$和消息$m$
-	\item 生成随机会话密钥$k$
-	\item 使用$SM4$对称加密消息: $c_1 = SM4_k(m)$
-	\item 使用公钥加密会话密钥: $c_2 = pk * k$
-	\item 输出密文$(c_1,c_2)$
-\end{enumerate}
+          Z_q = (0, sm2p256v1.N - 1)
 
-解密算法$Dec$步骤如下：
+          g = (sm2p256v1.Gx, sm2p256v1.Gy)
 
-\begin{enumerate}
-	\item 输入私钥$sk$和密文$(c_1,c_2)$
-	\item 使用私钥恢复会话密钥: $k = c_2/sk$
-	\item 使用会话密钥解密消息: $m = SM4^{-1}_k(c_1)$
-	\item 输出明文$m$
-\end{enumerate}
+          U = multiply(g, random.randint(0, sm2p256v1.N - 1))
+          \end{lstlisting}
 
-重加密算法$ReEnc$步骤如下：
+	\item 哈希函数
+	      \begin{lstlisting}
+          hash2(double_G: Tuple[point, point]) -> int: G^2 -> Z_q
 
-\begin{enumerate}
-	\item 输入重加密密钥$rk$和密文$(c_1,c_2)$
-	\item 重新加密会话密钥: $c_2' = rk * c_2$
-	\item 输出重加密密文$(c_1,c_2')$
-\end{enumerate}
+          hash3(triple_G: Tuple[point, point, point]) -> int: G^3 -> Z_q
 
-重加密密文解密算法$ReDec$步骤如下：
+          hash4(triple_G: Tuple[point, point, point], Z_q:int) -> int: G^3*Z_q -> Z_q
 
-\begin{enumerate}
-	\item 输入Bob的私钥$sk_B$和重加密密文$(c_1,c_2')$
-	\item 恢复会话密钥: $k = c_2'/sk_B$
-	\item 解密消息: $m = SM4^{-1}_k(c_1)$
-	\item 输出明文$m$
-\end{enumerate}
+          hash5(id:int, D:int) -> int:
+
+          hash6(triple_G: Tuple[point, point, point]) -> int:
+        \end{lstlisting}
+\end{itemize}
+
+\subsection{python库调用与类型定义}
+GmSSL是由我国自主开发的国产商用密码开源库，实现了对国密算法、标准和安全通信协议的全面功能覆盖，
+支持包括移动端在内的主流操作系统和处理器，支持密码钥匙、密码卡等典型国产密码硬件，
+提供功能丰富的命令行工具及多种编译语言编程接口。本算法中使用了其中的SM2,SM3,SM4函数。
+如图\ref{fig:gmssl}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/gmssl.png}
+	\end{center}
+	\caption{库引用与类型定义}\label{fig:gmssl}
+\end{figure}
+
+定义国密标准的SM2类参数和曲线上的生成元$g$, $U$。
+如图\ref{fig:sm2_python_parameter}所示。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/sm2_python_parameter.png}
+	\end{center}
+	\caption{国密标准的SM2类参数}\label{fig:sm2_python_parameter}
+\end{figure}
+
+
+\subsection{国密算法椭圆曲线上的加法、倍乘、求逆元}
+通过利用雅各比坐标系，将椭圆曲线上的点从仿射坐标转换为射影坐标表示，
+减少了点运算中的模逆运算次数，从而显著提高了椭圆曲线上点的计算效率。
+如图\ref{fig:sm2_methods}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/sm2_methods.png}
+	\end{center}
+	\caption{SM2椭圆曲线的加法、倍乘、求逆}\label{fig:sm2_methods}
+\end{figure}
+
+\subsection{hash函数}
+hash2(),hash3(),hash4()函数分别接受包含两个椭圆曲线点的元组、
+三个椭圆曲线点的元组、三个椭圆曲线点的元组和一个整数$Z_q$作为输入。
+然后使用SM3哈希函数初始化。遍历$double_G$中的每个点并对其坐标进行哈希处理，
+hash4()需要再对整数$Z_q$进行哈希处理。最后返回处理后的整数哈希值。
+如图\ref{fig:hashes}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/hashes.png}
+	\end{center}
+	\caption{hash2(),hash3(),hash4函数}\label{fig:hashes}
+\end{figure}
+
+\subsection{密钥派生函数}
+KDF()函数首先接受一个椭圆曲线点$G$作为输入。然后使用SM3哈希函数进行初始化，
+遍历$G$的坐标并对其进行哈希处理。将哈希输出转换为大整数并模$sm2p256v1.N$取值。
+最后使用一个128位的掩码来获取哈希输出的前128位，返回处理后的整数哈希值。
+如图\ref{fig:kdf}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/kdf.png}
+	\end{center}
+	\caption{KDF()函数}\label{fig:kdf}
+\end{figure}
+
+\subsection{密钥封装函数}
+首先生成随机整数$r,u$，在椭圆曲线上计算$E,V$。然后计算$s=(u + r \cdot \text{hash2}((E, V))) \bmod \text{sm2p256v1.N}$。
+计算共享秘密$\text{pk}_A \cdot (r + u)$，然后使用KDF函数从该共享秘密派生出共享密钥$K$。
+构造封装体$\text{capsule}$，封装体由$(E,V,s)$组成。最后函数返回一个元组，其中包含派生的共享密钥和封装体。
+如图\ref{fig:encapsulate}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/encapsulate.png}
+	\end{center}
+	\caption{密钥封装函数}\label{fig:encapsulate}
+\end{figure}
+
+\subsection{密钥对生成函数}
+首先初始化SM2密钥对生成器，调用generate\_key()方法来生成密钥对。
+从生成的公钥中提取$x$和$y$坐标，并将它们从字节转换为整数；提取生成的私钥，
+并将其从字节转换为整数。最后返回一个元组，其中包含公钥（作为坐标对）和私钥（作为整数）。
+如图\ref{fig:generate_key_pair}所示：
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/generate_key_pair.png}
+	\end{center}
+	\caption{密钥对生成函数}\label{fig:generate_key_pair}
+\end{figure}
+
+\subsection{加密函数}
+首先，函数通过Encapsulate(pk)方法进行封装，将公钥与随机性结合，产生一个共享的秘密$K$和一个公开的封装体capsule。
+然后验证密钥长度，确保从封装体中得到的秘密密钥$K$的长度确实为 16 字节。如果不是，将抛出一个错误。
+设置一个固定的初始化向量iv，然后使用SM4对称加密算法（在CBC模式下）与密钥$K$和iv进行初始化。
+这里，DO\_ENCRYPT是一个指示加密操作的常量。使用初始化后的SM4加密实例对消息$m$进行加密。
+最后函数返回一个元组，其中包含公开的封装体和加密后的数据。
+
+加密函数使用了混合加密方案：首先使用非对称加密（封装）产生一个共享的秘密，然后使用该秘密进行对称加密。
+这种方式结合了非对称加密的安全性和对称加密的效率。
+如图\ref{fig:enc}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/enc.png}
+	\end{center}
+	\caption{加密函数}\label{fig:enc}
+\end{figure}
+
+\subsection{解封装函数}
+该函数的目的是使用私钥$\text{sk}_A$解封提供的封装体$\text{capsule}$，以恢复原始的共享密钥。
+首先从封装体$\text{capsule}$中提取$E,V,s$。然后在椭圆曲线上计算$(E+V)^{\text{sk}_A}$，
+最后使用KDF函数对其解密，得到共享密钥$K$。
+如图\ref{fig:decapsulate}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/decapsulate.png}
+	\end{center}
+	\caption{解封装函数}\label{fig:decapsulate}
+\end{figure}
+
+\subsection{解密函数}
+该函数的目的是使用私钥$\text{sk}_A$解密密文$C$。
+首先从加密数据$C$中提取封装体$\text{capsule}$和加密的数据$\text{enc\_Data}$。
+然后使用$\text{Decapsulate}$函数和私钥$\text{sk}_A$解封$\text{capsule}$以恢复共享的秘密密钥$K$。
+使用恢复的密钥$K$和固定的初始化向量$\text{iv}$，然后初始化$\text{SM4}$对称解密算法（在$\text{CBC}$模式下）。
+使用初始化后的$\text{SM4}$解密实例解密$\text{enc\_Data}$，函数返回解密后的数据$\text{dec\_Data}$。
+
+解密函数先解封了一个封装体以恢复对称密钥$K$，然后使用这个密钥解密提供的加密数据。
+这是混合加密方案的一个典型应用，结合了非对称加密的安全性和对称加密的效率。
+如图\ref{fig:dec}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/dec.png}
+	\end{center}
+	\caption{解密函数}\label{fig:dec}
+\end{figure}
+
+\subsection{hash5()函数}
+该函数的目的是利用两个整数$\text{id}$和$D$生成一个哈希值。首先初始化 SM3 哈希算法实例。
+然后将整数$\text{id}$转换为 32 字节的字节串，并更新哈希算法；将整数$D$转换为 32 字节的字节串，
+并更新哈希算法。完成哈希计算并获取结果作为字节串。将字节串的哈希结果转换为整数，
+并进行模运算以确保结果在$\text{sm2p256v1.N}$范围内。函数返回计算得到的哈希值。
+如图\ref{fig:hash5}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/hash5.png}
+	\end{center}
+	\caption{hash5()函数}\label{fig:hash5}
+\end{figure}
+
+\subsection{hash6()函数}
+该函数的目的是从一个包含三个点的元组$\text{triple\_G}$生成一个哈希值。首先初始化 SM3 哈希算法实例。
+然后对于$\text{triple\_G}$中的每个点$i$，再对该点中的每个坐标执行以下操作：将坐标转换为 32 字节的字节串，
+并更新哈希算法。完成哈希计算并获取结果作为字节串。将字节串的哈希结果转换为整数，
+并进行模运算以确保结果在$sm2p256v1.N$范围内。最后函数返回计算得到的哈希值。
+如图\ref{fig:hash6}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/hash6.png}
+	\end{center}
+	\caption{hash6()函数}\label{fig:hash6}
+\end{figure}
+
+\subsection{多项式函数}
+该函数计算了一个关于的多项式的值，其中多项式的系数在$f\_modulus$列表中。
+然后，它对结果进行了模$sm2p256v1.N$运算。
+如图\ref{fig:polynomial}所示：
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/polynomial.png}
+	\end{center}
+	\caption{多项式生成函数}\label{fig:polynomial}
+\end{figure}
+
+\subsection{重加密密钥生成函数}
+随机生成一个整数$x_A$作为临时私钥。使用这个临时私钥计算其对应的公钥$X_A$。
+通过哈希函数$\text{hash3()}$得到$d$然后使用公钥、私钥和$d$来计算$r_0$，
+它是多项式的第一个系数。其余的系数随机生成。
+而$D$是Alice和Bob的公钥之间的另一个Diffie-Hellman密钥交换的结果。
+
+计算KF这部分的逻辑循环对$N$次循环，每次都会为KF列表生成一个新条目。
+每次迭代都会随机生成一个值$y$，并计算与之相关的公钥$Y$。通过hash5计算$s\_x$得出哈希值。
+然后计算$U_1$。将所有这些值打包为一个元组kFrag，并添加到KF列表中。
+如图\ref{fig:generate_rekey}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/generate_rekey.png}
+	\end{center}
+	\caption{重加密密钥生成函数}\label{fig:generate_rekey}
+\end{figure}
+
+\subsection{capsule检查函数}
+该函数的目的是验证所提供的capsule是否有效。在密钥封装机制(KEM)中，
+验证胶囊的有效性是关键的一步，以确保密钥的正确性和完整性。
+
+首先解包胶囊，通过结构化赋值，将胶囊元组的三个组成部分提取为变量$E$,$V$,$s$。
+然后使用哈希函数hash2()计算$E$和$V$的哈希值，结果存储在$h2$中。
+验证等式$g^s=V\cdot E^{\text{hash2}(E,V)}$是否成立。如果成立，则将flag设置为True，否则设置为False。
+最后函数返回一个布尔值flag来表示胶囊是否有效。
+如图\ref{fig:check_capsule}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/check_capsule.png}
+	\end{center}
+	\caption{检查函数}\label{fig:check_capsule}
+\end{figure}
+
+\subsection{重封装算法}
+首先输入参数kFrag和capsule，提取元组的内容:从kFrag中提取出id，rk，
+$X_A$，$U_1$；从capsule中提取出$E$，$V$，$s$。然后使用Checkcapsule()函数验证提供的胶囊的有效性。
+如果胶囊无效，函数会抛出一个错误。否则计算$E_1$和$V_1$。
+最后使用$E_1$，$V_1$，id，$X_A$创建一个新的元组cfrag，并作为返回值。
+如图\ref{fig:reencapsulate}所示：
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/reencapsulate.png}
+	\end{center}
+	\caption{重封装算法}\label{fig:reencapsulate}
+\end{figure}
+
+\subsection{重加密函数}
+ReEncrypt()是重加密函数，接受一个密钥片段kFrag和一个由胶囊与加密数据组成的密文元组作为输入。
+在函数内部，首先从C提取出胶囊和加密数据。然后，使用ReEncapsulate()函数处理kFrag和胶囊，生成cFrag。
+最后，该函数返回一个包含cFrag和原始加密数据的重加密密文元组。
+如图\ref{fig:reenc}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/reenc.png}
+	\end{center}
+	\caption{重加密函数}\label{fig:reenc}
+\end{figure}
+
+\subsection{重加密密文聚合函数}
+该函数的功能是将一个由cFrag和ct (enc\_Data)
+组成的重加密密文片段元组列表转化为一个包含两个元素的列表：
+第一个元素是所有cFrag的列表，第二个元素是第一个元组的ct值。
+如图\ref{fig:mergecfrag}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/mergecfrag.png}
+	\end{center}
+	\caption{重加密密文聚合函数}\label{fig:mergecfrag}
+\end{figure}
+
+\subsection{重封装解封函数}
+DecapsulateFrag()是一个重封装解封函数，它接受B的私钥sk$_B$，B和A的公钥pk$_B$，pk$_A$，
+以及一个包含密文片段的列表cFrags作为输入参数。在函数内部，
+首先从cFrags中提取出各自的信息并存放到四个列表Elist，Vlist，idlist，$X_A$list中。
+然后，函数计算pk$_A$与sk$_B$在椭圆曲线上的乘积，并基于此生成$D$值。
+接下来，它生成一个名为s$_X$的列表，其中每个元素都是基于idlist列表的每个id得到的。
+然后函数进一步计算多个系数b并存储在bis列表中。使用这些系数，计算出$E_2$，$V_2$的值。
+后续，在椭圆曲线上进行更多的点乘操作以计算$X'_a$和$d$值。
+最后，函数在椭圆曲线上将$E_2$，$V_2$相加并乘$d$值，
+然后使用KDF函数从结果中派生出密钥$K$，并返回该密钥。
+如图\ref{fig:decapsulatefrag}所示：
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/decapsulatefrags.png}
+	\end{center}
+	\caption{重封装解封函数}\label{fig:decapsulatefrag}
+\end{figure}
+
+\subsection{重加密解密函数}
+DecryptFrags()是重加密解密函数，它使用B的私钥sk$_B$、B和A的公钥pk$_B$，
+pk$_A$以及一个包含密文片段的列表cfrags作为输入。在函数内部，首先从cfrags中提取密文片段，
+得到capsules和enc$_{Data}$。然后使用DecapsulateFrags()函数从capsules中解封装出密钥K。
+然后，将此密钥转换为16字节的字节串。最后使用SM4的CBC模式以及提取出的密钥来初始化解密算法，
+并解密enc$_{Data}$生成重加密解密数据dec$_{Data}$。如果在解密过程中遇到错误，
+函数会捕获并打印错误消息，并设置解密数据dec$_{Data}$为一个空字节串。
+最后，返回解密后的数据dec$_{Data}$。
+如图\ref{fig:decryptfrags}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/decfrags.png}
+	\end{center}
+	\caption{重加密解密函数}\label{fig:decryptfrags}
+\end{figure}
 
 \subsection{系统流程}
 
@@ -218,46 +627,146 @@ $ReDec$：输入Bob的公钥$pk_B$和私钥$sk_B$，A的公钥$pk_A$，重加密
 	\item 代理节点执行重加密操作
 	\item 数据请求方接收并解密数据
 \end{enumerate}
+系统流程图如图\ref{fig:system_flow}所示：
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/system_flow.png}
+	\end{center}
+	\caption{系统流程图}
+	\label{fig:system_flow}
+\end{figure}
+
 
 \subsection{关键模块}
+本系统的功能实现依赖于多个专用模块的协同工作，每个模块负责特定的功能领域，
+通过标准化接口相互配合，共同构建完整的代理重加密框架。
+这种模块化设计不仅提高了系统的可维护性和可扩展性，还便于针对不同应用场景进行定制化部署。
+
 \subsubsection{密钥管理模块}
-\begin{itemize}
-	\item 实现公私钥对的生成和管理
-	\item 支持重加密密钥的分发和更新
-	\item 确保密钥的安全存储
-\end{itemize}
+密钥管理模块作为系统安全基础设施的核心组件，负责整个系统的密码材料全生命周期管理。
+该模块首先实现了基于SM2算法的公私钥对生成功能，支持用户身份绑定的密钥派生和随机密钥生成两种方式。
+在密钥生成过程中，模块采用符合密码学要求的高质量随机源，确保生成密钥的不可预测性和唯一性。
+对于高安全需求场景，系统支持与硬件安全模块(HSM)或可信平台模块(TPM)集成，
+将密钥生成过程迁移至物理隔离的安全环境中执行，进一步增强密钥材料的安全性。
+
+该模块还承担重加密密钥的管理职责，包括基于用户授权关系动态生成重加密密钥、
+执行基于Shamir秘密共享的密钥分片、协调密钥片段的安全分发以及处理密钥的定期更新与撤销。
+特别是在密钥更新机制中，系统实现了无缝的版本转换策略，确保密钥更新不影响已加密数据的可访问性，
+同时支持紧急情况下的密钥撤销，有效限制安全事件的影响范围。
+
+在密钥存储方面，模块采用多层次的安全防护措施。所有敏感密钥材料在存储前均经过额外加密处理，
+加密密钥通过密钥派生函数从用户主密钥和随机盐值派生，并使用安全的密钥封装机制保护。
+系统对存储介质进行了安全分级，核心私钥仅保存在高安全级别的受控环境中，
+而公钥和非敏感元数据可分布在普通存储系统中。模块还实现了完整的密钥备份与恢复机制，
+在确保业务连续性的同时，通过严格的访问控制和审计日志记录，防止备份成为安全漏洞。
 
 \subsubsection{加解密模块}
-\begin{itemize}
-	\item 封装国密算法接口
-	\item 实现混合加密机制
-	\item 提供数据加解密服务
-\end{itemize}
+加解密模块提供了系统的核心密码学功能，通过标准化的接口封装各种密码算法，
+为上层应用提供统一的加密服务。该模块首先实现了对国密算法族（SM2/SM3/SM4）的全面封装，
+提供了符合国家标准规范的算法实现。在接口设计上，模块采用了易于使用的面向对象模式，
+隐藏了底层密码学操作的复杂性，同时保留了必要的参数配置灵活性，
+满足不同安全级别和性能需求的应用场景。
+
+该模块的核心功能是实现高效的混合加密机制，将SM2和SM4算法有机结合，
+在保证安全性的前提下优化性能表现。具体而言，对于需要加密的原始数据，
+系统首先随机生成一个高熵值的SM4会话密钥，使用该密钥和GCM模式对数据进行对称加密；
+然后使用接收方的SM2公钥对会话密钥本身进行非对称加密。
+这种设计使得系统能够高效处理大规模数据，同时保持密钥管理的灵活性。在实现上，
+模块采用流水线处理和内存映射技术处理大文件，提供了分块加密和并行处理能力，
+显著提升了系统在大数据环境下的性能。
+
+加解密模块还提供了一系列辅助功能，包括数据完整性验证、安全随机数生成、
+密码学签名与验证等，构成了完整的密码服务体系。特别是在数据完整性保护方面，
+模块利用SM3算法和HMAC机制实现了强认证，确保数据在传输和存储过程中不被篡改。
+模块的接口设计考虑了与各类应用场景的兼容性，提供了同步/异步调用模式、
+批处理接口和流式处理能力，满足从嵌入式设备到大型服务器的多种部署环境需求。
 
 \subsubsection{代理重加密模块}
-\begin{itemize}
-	\item 执行重加密运算
-	\item 管理重加密密钥片段
-	\item 协调多节点操作
-\end{itemize}
+代理重加密模块是系统实现安全数据共享的核心组件，负责执行密文转换操作而无需解密原始数据。
+该模块基于门限代理重加密理论，实现了$(t,n)$门限重加密方案，
+要求至少$t$个代理节点协作才能完成重加密过程。
+模块的设计确保单个代理节点无法获取足够信息来解密数据或重构完整的重加密密钥，
+从而有效防止了代理节点的权限滥用。
+
+在重加密密钥管理方面，模块实现了密钥片段的安全存储和访问控制机制。
+每个代理节点仅存储分配给它的重加密密钥片段，
+这些片段通过额外的加密层和节点本地的安全存储机制保护。模块支持密钥片段的定期更新和版本控制，
+实现了前向安全性，即使某个时间点的密钥片段被泄露，也不会危及后续操作的安全性。
+
+代理重加密模块的另一重要功能是协调多节点共同完成重加密操作。
+当系统接收到重加密请求时，模块首先验证请求的合法性和授权状态，然后启动分布式重加密协议。
+在该协议中，参与节点各自使用本地存储的密钥片段对密文进行部分重加密，并生成重加密证明；
+协调节点收集这些部分结果，在达到门限数量后，组合生成最终的重加密结果。
+整个过程采用安全多方计算技术确保中间结果不泄露敏感信息，
+同时通过零知识证明验证各节点的操作正确性，防止恶意节点提交错误结果。
+
+模块还实现了丰富的异常处理和容错机制，能够应对节点失效、网络中断等各类故障场景，
+确保系统在不理想的网络环境中仍能可靠运行。性能优化方面，模块采用了批处理重加密、
+预计算和结果缓存等技术，有效降低了重加密操作的延迟和资源消耗。
 
 \subsubsection{通信模块}
-\begin{itemize}
-	\item 基于HTTP协议
-	\item 实现节点间安全通信
-	\item 支持异步数据传输
-\end{itemize}
+通信模块为系统各组件提供了统一的数据交换基础设施，负责处理节点间的消息传递和状态同步。
+该模块基于HTTP/HTTPS协议构建，充分利用了Web技术的成熟性和广泛兼容性，
+便于跨平台部署和防火墙穿透。在具体实现上，模块采用RESTful API设计风格，
+定义了清晰的资源模型和操作语义，支持标准的HTTP方法（GET、POST、PUT、DELETE等）进行资源操作。
+
+安全通信是该模块的核心关注点，系统实现了多层次的安全防护机制。在传输层，
+所有通信均采用TLS 1.3协议加密，确保数据传输的机密性和完整性；在应用层，
+模块实现了基于JWT（JSON Web Token）的身份认证和访问控制，
+每个请求都需要携带有效的身份令牌和操作授权证明。为防止重放攻击和中间人攻击，
+系统还采用了请求时间戳验证、请求签名和随机挑战响应机制。针对分布式拒绝服务攻击，
+模块实现了请求频率限制和资源隔离策略，有效保护系统的可用性。
+
+模块支持灵活的异步数据传输模式，特别适合处理长时间运行的重加密操作和大文件传输场景。
+在异步模式下，系统返回操作标识符，客户端可以通过该标识符查询操作状态或接收操作完成通知，
+避免了长连接占用和请求超时问题。为提高通信效率，模块实现了消息压缩、
+批量请求处理和连接池管理等优化技术，显著降低了网络带宽消耗和请求处理延迟。
+
+在可靠性方面，通信模块采用了完整的错误处理和重试机制，能够应对网络波动和临时故障。
+系统定义了统一的错误码和响应格式，提供了详细的错误信息和处理建议，便于问题诊断和自动恢复。
+模块还实现了通信事件的详细日志记录和性能指标收集，为系统监控和性能优化提供了数据支持。
 
 \section{安全性分析}
-系统的安全性主要体现在以下方面：
-\begin{itemize}
-	\item 基于国密算法的密码学安全性
-	\item 分布式架构降低单点故障风险
-	\item 门限机制提供容错能力
-	\item 完整性校验确保数据不被篡改
-	\item 访问控制保护数据隐私
-\end{itemize}
+系统安全性是代理重加密解决方案的核心考量，通过多层次、纵深防御的安全架构，
+系统在保障数据共享效率的同时，确保了信息资产的全面保护。
+安全性分析从多个维度评估了系统的风险抵抗能力和安全保障水平。
+
+系统的底层安全基础建立在国密算法的密码学强度上。SM2椭圆曲线密码算法采用256位密钥长度，
+其安全性基于椭圆曲线离散对数问题，当前最优算法的计算复杂度为$O(2^{128})$，
+远超现有技术能力。SM3哈希算法输出256位杂凑值，提供了强抗碰撞性和抗前像性，
+有效保障了数据完整性验证机制的安全性。SM4分组密码通过32轮非线性迭代提供了高强度的数据保密性，
+经过密码学分析验证能够抵抗已知的各类密码攻击。这些国家标准算法经过严格的安全评估和论证，
+既符合国内密码合规要求，又提供了国际认可的安全强度，为系统奠定了坚实的密码学基础。
+
+分布式架构是系统抵抗单点故障和集中式攻击的关键机制。与传统中心化系统不同，
+本方案将关键功能和敏感数据分散到多个独立节点，
+任何单点的妥协都不会导致整个系统的崩溃或安全机制的完全失效。特别是在代理重加密过程中，
+重加密密钥和操作被分散到多个代理节点，攻击者需要同时控制多个节点才能获取有效信息，
+显著提高了攻击难度。系统通过一致性协议和状态同步机制，确保分布式环境下的操作一致性和数据完整性，
+即使部分节点失效或遭受攻击，系统仍能维持安全运行。
+分布式架构还提供了自然的负载均衡和横向扩展能力，有效防止了资源耗尽型攻击，
+提高了系统整体的可用性和鲁棒性。
+
+门限机制为系统提供了细粒度的容错能力和访问控制。通过$(t,n)$门限方案，
+系统可以在保证安全性的前提下，容忍最多$n-t$个节点的失效或恶意行为。
+这种设计既增强了系统的可用性，又提高了安全边界，形成了"多数决策"的信任模型。
+在实际部署中，门限参数可以根据具体应用场景的安全需求和可用性要求进行灵活配置，
+实现安全性和可用性的最优平衡。门限机制还支持动态成员管理，
+允许在系统运行过程中添加或移除参与节点，而不需要重建整个密钥体系，
+提供了良好的运维灵活性。
+
+完整性校验是防止数据篡改和确保系统可信运行的重要保障。系统在多个层次实现了数据完整性验证：
+从基础的SM3哈希验证，到高级的数字签名和认证加密。
+所有关键数据在传输和存储过程中均附带密码学完整性证明，
+任何未授权的修改都会导致验证失败并触发安全警报。特别是在代理重加密过程中，
+系统实现了操作证明机制，每个参与节点都需要提供其操作正确性的零知识证明，
+这些证明可以被其他节点或审计者验证，确保了整个重加密过程的可验证性和不可抵赖性。
+系统还建立了完整的审计日志链，记录所有关键操作和状态变更，支持事后追溯和责任认定。
+
+通过这些多层次、相互补充的安全机制，系统构建了全面的安全防护体系，在算法层面、
+架构层面和应用层面均提供了充分的安全保障，有效应对各类安全威胁和攻击场景。
 
 \section{本章小结}
 本章详细介绍了系统的设计方案和实现细节，包括总体架构、核心算法、关键技术和具体实现。
-通过合理的系统设计和可靠的技术实现，确保了系统在分布式环境下能够安全高效地完成数据共享和授权管理任务
+通过合理的系统设计和可靠的技术实现，
+确保了系统在分布式环境下能够安全高效地完成数据共享和授权管理任务
diff --git a/paper/chapters/chapter04.tex b/paper/chapters/chapter04.tex
index b566244..d58185d 100644
--- a/paper/chapters/chapter04.tex
+++ b/paper/chapters/chapter04.tex
@@ -15,10 +15,12 @@
 		\hline
 		处理器            & AMD Ryzen 5 4500U (6) @ 2.38 GHz \\
 		操作系统           & Kali GNU/Linux Rolling x86\_64   \\
+		内核版本           & 6.12.20-amd64                    \\
 		\hline
 		\textbf{软件}    & \textbf{版本}                      \\
 		\hline
 		Python         & 3.13.3                           \\
+		clang          & 19.1.7                           \\
 		gmssl          & 3.2.1                            \\
 		SQLite         & 3.39.3                           \\
 		\hline
@@ -41,21 +43,13 @@
 		\textbf{软件}  & \textbf{版本}   \\
 		\hline
 		Docker       & 24.0.5        \\
-		Redis        & 7.0.11        \\
-		Node.js      & 18.16.0       \\
 		\hline
 	\end{tabular}
 \end{table}
 
 \section{功能测试}
 
-\subsection{密钥生成与管理测试}
-
-本节对分布式环境下基于国密的代理重加密系统的密钥生成与管理功能进行全面测试，
-验证系统在实际应用场景中的可靠性和安全性。密钥生成与管理是整个系统安全架
-构的基础，其正确性和安全性直接关系到系统的整体安全保障能力。
-
-\subsubsection{公私钥对生成测试}
+\subsection{公私钥对生成测试}
 
 公私钥对生成功能测试主要验证系统基于国密算法SM2的密钥生成机制。测试过程
 中，系统随机生成了多组密钥对，每组密钥对包含一个公钥（表现为椭圆曲线上
@@ -66,87 +60,166 @@
 线上的点）和私钥（形式为大整数）。多次调用该函数，验证了生成密钥的随
 机性，确保不同用户或同一用户在不同时间生成的密钥对是唯一的，从而保障了
 系统的安全性。
+如图\ref{fig:gen_pk_sk}所示。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/gen_pk_sk_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/gen_pk_sk_2.png}
+	\end{center}
+	\caption{生成公私密钥对}\label{fig:gen_pk_sk}
+\end{figure}
 
-\subsubsection{重加密密钥生成测试}
+\subsection{加密消息m}
+$m$为待加密消息'helloworld'，capsule\_ct为加密并封装后的消息。
 
-重加密密钥生成功能是代理重加密系统的核心，测试主要验证系统能否基于用
-户A的私钥和用户B的公钥正确生成重加密密钥片段。在测试中，系统为不同的
-代理节点（用节点标识id区分）生成了对应的重加密密钥片段。测试结果表明
-，即使在相同的A私钥和B公钥情况下，不同节点id生成的重加密密钥片段也各
-不相同，这保证了密钥片段的唯一性和安全性。
+capsule\_ct由$E$，$V$，id，$X_d$组成，其中$E$，$V$的形式为椭圆曲线上的一个点，id是哈希后产生的随机整数，$X_d$是bytes类型。
+如图\ref{fig:enc_msg}所示。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/enc_message_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/enc_message_2.png}
+	\end{center}
+	\caption{加密消息m}\label{fig:enc_msg}
+\end{figure}
 
-重加密密钥生成测试还验证了门限机制的有效性，通过设置不同的门限值T和节
-点数N，系统能够正确生成满足门限共享方案的重加密密钥片段集合，为后续
-的分布式重加密操作奠定基础。
+\subsection{重加密密钥生成}
+id\_tuple为代理节点的身份标识id，rekeys为生成的重加密密钥；在单次重加密中$sk_A$与$pk_B$已知，
+不同节点的id不同，其重加密密钥也就不同。
 
-\subsubsection{密钥分发和存储测试}
+图\ref{fig:generate_rekey_test}红框为测试中模拟的节点id，假设id从0开始递增，可以观察到重加密密钥片段成功生成，
+且不同id的节点，后面产生的重加密密钥不相同。
+\begin{figure}
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/generate_rekey_test_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/generate_rekey_test_2.png}
+	\end{center}
+	\caption{重加密密钥生成}\label{fig:generate_rekey_test}
+\end{figure}
 
-密钥分发和存储功能测试主要验证系统在分布式环境中安全传输和存储各类
-密钥的能力。测试过程中，系统成功将用户公钥、重加密密钥片段分发至相
-应的节点，并在各节点本地安全存储。测试结果显示，系统采用的HTTP协议
-传输机制和SQLite数据库存储方案能够有效支持密钥的安全分发和存储，并
-且具有较小的存储开销和较高的兼容性。
+\subsection{密文重加密}
+cfrag\_ct:重加密密文片段，用不同的重加密密钥片段对capsule\_ct进行重加密，
+其产生的重加密密文片段也不同。而每个id对应着一个代理节点服务器，同时对应着一个重加密密钥片段，
+运算后产生对应的重加密密文片段，也都各不相同。
 
-综合测试结果表明，系统的密钥生成和管理功能完善可靠，能够正确生成、
-分发和存储各类密钥，确保密钥的唯一性和安全性，为整个代理重加密系统
-的安全运行提供了坚实的基础。
+图\ref{fig:cfrag_cts}红框内的从0开始逐个递增的数字模拟为节点服务器的id，
+用于标识产生的不同的重加密密文片段。
+通过观察运行结果可以看出代理服务器节点利用自己收到的重加密密钥片段成功计算生成了对应重加密密文片段，
+不同id的点节服务器，产生的重加密密文片段也不同。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/cfrag_cts_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/cfrag_cts_2.png}
+	\end{center}
+	\caption{密文重加密}\label{fig:cfrag_cts}
+\end{figure}
 
-\subsection{加密解密测试}
+\subsection{重加密密文片段合并}
+cfrags为经过mergecfrag()函数合并后的重加密密文，用于后续的解密操作。
 
-加密解密功能作为代理重加密系统的核心操作，直接关系到系统的安全性
-和实用性。本节对系统的加密解密功能进行全面测试，验证其在实际应
-用场景中的可靠性和正确性。
+如图\ref{fig:mergecfrag_test}所示，cfrags由两大部分组成，
+一部分是由$T$个代理服务器节点用自己收到的重加密密钥对capsule\_ct进行重加密后产生的cfrag$_{i=[1..t]}$，
+里面带有产生这个重加密密文片段节点服务器的id，
+另一部分则是所有重加密密文片段相同的部分$enc\_Data$（重加密密文数据）。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/mergecfrag_test_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/mergecfrag_test_2.png}
+	\end{center}
+	\caption{重加密密文片段合并}\label{fig:mergecfrag_test}
+\end{figure}
 
-\subsubsection{原始数据加密测试}
+\subsection{解密}
+当传入DecryptFrags()函数的参数全部正确时，会成功解密重加密密文，
+得到原始数据$m$。这里设置初始明文$m=$'helloworld'。
 
-原始数据加密测试主要验证系统基于国密算法对原始明文数据进行加密的
-功能。在测试中，系统使用用户A的公钥对明文消息"Hello, PRE with SM2!"进
-行加密，生成加密并封装后的密文。测试结果显示，生成的密文由三部分组成
-：一个椭圆曲线上的点、一个哈希后产生的随机整数，以及经过对称加密后的
-数据。多次对相同明文进行加密，每次得到的密文均不同，这验证了加密算法
-的随机性和安全性。
+输入正确的B的私钥$sk_B$，B的公钥$pk_B$和A的公钥$pk_A$以及合并之后的重加密密文cfrags，
+经过解密之后，得到正确的解密数据。
+如图\ref{fig:decrypt_test}所示。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/dec_test_1.png}
+		\includegraphics[width=0.95\textwidth]{images/chapters/dec_test_2.png}
+	\end{center}
+	\caption{成功解密}\label{fig:decrypt_test}
+\end{figure}
 
-值得注意的是，系统采用了混合加密机制，使用SM2公钥算法进行密钥封装，使
-用SM4对称算法进行数据加密，这种组合既保证了安全性，又提高了加密效率
-，特别适合处理大量数据的场景。
+\section{系统云端运行结果}
 
-\subsubsection{重加密操作测试}
+程序运行场景:我们使用一台服务器作为中心服务器,用于记录代理节点的信息。
+使用两台服务器作为代理节点。使用两台服务器作为客户端。
+图\ref{fig:central_server_start_log}为中心服务器成功启动的日志。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/central_server_start_log.png}
+	\end{center}
+	\caption{中心服务器成功启动日志}\label{fig:central_server_start_log}
+\end{figure}
 
-重加密操作是代理重加密系统区别于传统加密系统的关键特性。测试主要验证系
-统能否使用预先生成的重加密密钥片段对密文进行重加密，生成重加密密文片
-段。测试结果表明，不同节点使用各自的重加密密钥片段对同一密文进行重加
-密，生成的重加密密文片段各不相同，这符合门限代理重加密的理论预期。
+图\ref{fig:node_start_log}为代理节点成功启动的日志。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/node_start_log.png}
+	\end{center}
+	\caption{代理节点成功启动的日志}\label{fig:node_start_log}
+\end{figure}
 
-进一步测试表明，如果使用相同的重加密密钥片段对密文进行重加密，将产生
-完全相同的重加密密文片段，这会破坏与重加密密钥的对应关系，导致后续解
-密失败。这一测试结果验证了系统正确实现了代理重加密算法，并能有效防止重
-加密密钥的错误使用。
+图\ref{fig:central_server_db_log}为中心服务器成功登记两个代理节点的信息，
+其中id是节点的唯一标识，ip为节点的ip地址，last\_heartbeat用于确认节点存活状态。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/central_server_db_log.png}
+	\end{center}
+	\caption{中心服务器数据库}\label{fig:central_server_db_log}
+\end{figure}
 
-\subsubsection{密文合并测试}
+图\ref{fig:central_server_msg_log}为中心服务器成功接收两个代理节点的心跳包，
+主要用于更新节点存活状态。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/central_server_msg_log.png}
+	\end{center}
+	\caption{中心服务器接收消息}\label{fig:central_server_msg_log}
+\end{figure}
 
-密文合并功能测试主要验证系统能否正确合并来自不同节点的重加密密文片段。
-在测试中，系统成功将多个节点生成的重加密密文片段合并为一个完整的重加
-密密文。测试结果显示，合并后的重加密密文由两部分组成：包含节点标识的
-重加密密文片段集合和所有片段共享的重加密密文数据。
+图\ref{fig:client_start_log}为客户端成功启动的日志。
+日志显示数据库成功初始化,并且成功从中心服务器获取代理节点信息。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/client_start_log.png}
+	\end{center}
+	\caption{客户端成功启动的日志}\label{fig:client_start_log}
+\end{figure}
 
-测试还验证了当重加密密文片段不完整或错误时，合并操作仍能完成，但后续解
-密将失败并返回错误提示，这保证了系统在片段丢失或错误情况下的健壮性。
+图\ref{fig:client_response}展现了中心服务器成功向客户端返回指定数量的代理节点信息
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/client_response.png}
+	\end{center}
+	\caption{中心服务器响应客户端}\label{fig:client_response}
+\end{figure}
 
-\subsubsection{解密验证测试}
+图\ref{fig:client_fe}是前端客户端程序向其他客户端请求信息并成功接收。
+图\ref{fig:client_fe}中为请求客户端地址;为请求消息的名称；
+最后一行为成功接收到的信息（+8字节随机数据）。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/client_fe.png}
+	\end{center}
+	\caption{前端客户端}\label{fig:client_fe}
+\end{figure}
 
-解密验证功能测试主要验证系统能否使用正确的密钥和重加密密文进行解密，
-恢复原始明文数据。测试分为两种情况：使用正确的参数进行解密和使用错误的参数进行解密。
 
-当使用接收方B的正确私钥、B的公钥、发送方A的公钥以及合并后的重加密
-密文进行解密时，系统成功恢复了原始明文数据"Hello, PRE with SM2!"，
-验证了整个加密、重加密和解密过程的正确性。
+图\ref{fig:client_be_db}为后端客户端程序从代理节点接收到的重加密信息。列为二进制形式存储的重加密密文,
+可用于恢复对称密钥;为使用对称密钥加密的密文; 为密文的发送方的地址（即我们请求的其他客户端）。
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/client_be_db.png}
+	\end{center}
+	\caption{后端客户端数据库}\label{fig:client_be_db}
+\end{figure}
 
-当使用错误的私钥（如将B的私钥替换为A的私钥）进行解密时，系统正确抛
-出了"Decryption failed"错误，这验证了系统的访问控制机制能够有效防止未授权访问。
+由于保密性,代理节点不存储密文。即使代理节点存储了密文,但是由于门限算法的约束,单个恶意节点无法恢复明文。
 
-综合测试结果表明，系统的加密解密功能完善可靠，能够正确完成原始数据加
-密、重加密操作、密文合并和解密验证等核心功能，保证了数据在传输和存储
-过程中的机密性和完整性。
 
 \section{性能测试}
 
@@ -159,8 +232,9 @@
 
 \subsubsection{测试配置与指标}
 
-性能测试在Intel Core i7-10750H CPU @ 2.60GHz处理器环境下进行，主要考
-察在不同节点数(N)和门限值(T)配置下的算法性能表现。测试指标包括以下六个方面：
+性能测试在AMD Ryzen 5 4500U处理器环境下进行，
+主要考察在不同节点数(N)和门限值(T)配置下的算法性能表现。
+测试指标包括以下六个方面：
 
 \begin{enumerate}
 	\item 算法总运行时间：完成整个加密、重加密和解密流程所需的总时间
@@ -182,6 +256,45 @@
 相对稳定，分别约为0.003秒和0.008秒，不受节点数变化影响。而重
 加密密钥生成时间和解密算法时间则随节点数增加而线性增长，这符
 合算法设计的理论预期，因为这两部分操作与节点数直接相关。
+如表\ref{tab:fixed_t}及图\ref{fig:fixed_t}所示。
+
+\begin{landscape}
+	\begin{table}[htbp]
+		\centering
+		\caption{控制门限T不变，算法运行时间表}
+		\label{tab:fixed_t}
+		\begin{tabular}{|c|c|c|c|c|c|c|c|}
+			\hline
+			\multirow{2}{*}{节点个数N} & \multirow{2}{*}{门限值T} & 算法总运    & 密钥生成    & 加密算法    & 重加密密         & 重加密算     & 解密算法    \\
+			                       &                       & 行时间(s)  & 运行时间(s) & 运行时间(s) & 钥生成算法运行时间(s) & 法运行时间(s) & 运行时间(s) \\
+			\hline
+			4                      & 4                     & 0.07474 & 0.00341 & 0.00786 & 0.03038      & 0.01054  & 0.02958 \\
+			\hline
+			6                      & 4                     & 0.09987 & 0.00345 & 0.00789 & 0.04253      & 0.00990  & 0.04230 \\
+			\hline
+			8                      & 4                     & 0.11789 & 0.00325 & 0.00761 & 0.05141      & 0.01044  & 0.05223 \\
+			\hline
+			10                     & 4                     & 0.14616 & 0.00368 & 0.00825 & 0.06407      & 0.01020  & 0.06630 \\
+			\hline
+			12                     & 4                     & 0.16297 & 0.00330 & 0.00901 & 0.07148      & 0.01047  & 0.07575 \\
+			\hline
+			14                     & 4                     & 0.18638 & 0.00326 & 0.00784 & 0.08027      & 0.01002  & 0.09114 \\
+			\hline
+			16                     & 4                     & 0.20876 & 0.00325 & 0.00816 & 0.09117      & 0.01028  & 0.10254 \\
+			\hline
+			18                     & 4                     & 0.23014 & 0.00337 & 0.00749 & 0.09976      & 0.01027  & 0.11579 \\
+			\hline
+		\end{tabular}
+	\end{table}
+
+\end{landscape}
+
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/fixed_t.png}
+	\end{center}
+	\caption{算法总运行时间折线图}\label{fig:fixed_t}
+\end{figure}
 
 \subsubsection{控制节点N不变的性能测试}
 
@@ -193,6 +306,47 @@
 这一发现具有重要的实践指导意义，表明在系统配置中，将门限值T设
 置为节点总数N的一半能够获得最佳的性能平衡。这与理论上的预期相
 符，因为这种配置在安全性和效率之间达到了最佳平衡点。
+如表\ref{tab:fixed_n}及图\ref{fig:fixed_n}所示。
+
+\begin{landscape}
+	\begin{table}[htbp]
+		\centering
+		\caption{控制节点N不变，算法运行时间表}
+		\label{tab:fixed_n}
+		\begin{tabular}{|c|c|c|c|c|c|c|c|}
+			\hline
+			\makecell{节点个数                                                      \\N} & 门限值T & \makecell{算法总运\\行时间\\(s)} & \makecell{密钥生成\\运行时间\\(s)} & \makecell{加密算法\\运行时间\\(s)} & \makecell{重加密密\\钥生成算\\法运行时\\间(s)} & \makecell{重加密算\\法运行时\\间(s)} & \makecell{解密算法\\运行时间\\(s)} \\
+			\hline
+			20 & 2  & 0.25702 & 0.00332 & 0.00844 & 0.11137 & 0.01037 & 0.13018 \\
+			\hline
+			20 & 4  & 0.25943 & 0.00333 & 0.00806 & 0.11324 & 0.01002 & 0.13091 \\
+			\hline
+			20 & 6  & 0.26439 & 0.00318 & 0.00823 & 0.11070 & 0.01009 & 0.13875 \\
+			\hline
+			20 & 8  & 0.26148 & 0.00370 & 0.00794 & 0.11498 & 0.01037 & 0.13126 \\
+			\hline
+			20 & 10 & 0.25665 & 0.00337 & 0.00863 & 0.11158 & 0.01053 & 0.12951 \\
+			\hline
+			20 & 12 & 0.26319 & 0.00357 & 0.00850 & 0.11324 & 0.01027 & 0.13438 \\
+			\hline
+			20 & 14 & 0.26777 & 0.00345 & 0.00849 & 0.12178 & 0.01031 & 0.12832 \\
+			\hline
+			20 & 16 & 0.26163 & 0.00411 & 0.00919 & 0.11350 & 0.01010 & 0.13128 \\
+			\hline
+			20 & 18 & 0.26130 & 0.00325 & 0.00757 & 0.11283 & 0.01038 & 0.13379 \\
+			\hline
+		\end{tabular}
+	\end{table}
+\end{landscape}
+
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/fixed_n.png}
+	\end{center}
+	\caption{N不变算法运行时间}\label{fig:fixed_n}
+\end{figure}
+
+
 
 \subsubsection{控制门限T为节点N一半的性能测试}
 
@@ -207,6 +361,45 @@
 综合分析表明，系统在不同配置下都表现出良好的性能特性，特别是当门限T
 为节点数N的一半时，系统性能最优。这一发现不仅验证了算法设计的合理
 性，也为系统在实际部署中的参数配置提供了重要参考。
+如表\ref{tab:half_n}及图\ref{fig:half_n}所示。
+
+\begin{landscape}
+	\begin{table}[htbp]
+		\centering
+		\caption{控制门限T为节点N的一半，算法运行时间表}
+		\label{tab:half_n}
+		\begin{tabular}{|c|c|c|c|c|c|c|c|}
+			\hline
+			\makecell{节点个数                                                      \\N} & 门限值T & \makecell{算法总运\\行时间\\(s)} & \makecell{密钥生成\\运行时间\\(s)} & \makecell{加密算法\\运行时间\\(s)} & \makecell{重加密密\\钥生成算\\法运行时\\间(s)} & \makecell{重加密算\\法运行时\\间(s)} & \makecell{解密算法\\运行时间\\(s)} \\
+			\hline
+			4  & 2  & 0.07719 & 0.00341 & 0.00792 & 0.03173 & 0.01002 & 0.03057 \\
+			\hline
+			6  & 3  & 0.09806 & 0.00334 & 0.00747 & 0.04278 & 0.01011 & 0.04087 \\
+			\hline
+			8  & 4  & 0.11758 & 0.00325 & 0.00748 & 0.04939 & 0.00995 & 0.05356 \\
+			\hline
+			10 & 5  & 0.14253 & 0.00416 & 0.00867 & 0.06216 & 0.01018 & 0.06368 \\
+			\hline
+			12 & 6  & 0.16258 & 0.00383 & 0.00782 & 0.07178 & 0.01016 & 0.07559 \\
+			\hline
+			14 & 7  & 0.18690 & 0.00342 & 0.00905 & 0.08760 & 0.01040 & 0.09016 \\
+			\hline
+			16 & 8  & 0.20920 & 0.00331 & 0.00754 & 0.09289 & 0.01026 & 0.10092 \\
+			\hline
+			18 & 9  & 0.24200 & 0.00336 & 0.00844 & 0.10238 & 0.01022 & 0.12431 \\
+			\hline
+			20 & 10 & 0.25606 & 0.00329 & 0.00747 & 0.10931 & 0.01025 & 0.13245 \\
+			\hline
+		\end{tabular}
+	\end{table}
+\end{landscape}
+
+\begin{figure}[H]
+	\begin{center}
+		\includegraphics[width=0.95\textwidth]{images/chapters/half_n.png}
+	\end{center}
+	\caption{T为N的一半时运行时间}\label{fig:half_n}
+\end{figure}
 
 \subsection{系统响应时间测试}
 
@@ -229,7 +422,8 @@
 
 测试结果显示，系统采用的异步处理机制能够有效处理并发请求，在测试
 的20个并发请求场景下，系统总处理时间约为1.82秒，平均每个请求的
-处理时间约为0.31秒。与同步处理方式相比，异步处理提升了约40\%的效率，证明了系统在高并发场景下的优异性能。
+处理时间约为0.31秒。与同步处理方式相比，异步处理提升了约40\%的效率，
+证明了系统在高并发场景下的优异性能。
 
 \subsubsection{通信延迟测试}
 
diff --git a/paper/chapters/chapter05.tex b/paper/chapters/chapter05.tex
index 18dc46e..8259bb8 100644
--- a/paper/chapters/chapter05.tex
+++ b/paper/chapters/chapter05.tex
@@ -33,24 +33,53 @@
 
 	\item 关键技术创新
 	      \begin{itemize}
-		      \item 将门限密码学与代理重加密技术相结合。传统的代理重加密方案通常依赖单一代理节点，存在单点故障和安全风险。本文通过引入Shamir密码共享方案，将重加密过程分散到多个代理节点，任何少于门限值的代理节点集合都无法获得关于原始密文的有效信息，从而显著提高了系统的安全性。
+		      \item 将门限密码学与代理重加密技术相结合。传统的代理重加密方案通常依赖单一代理节点，
+		            存在单点故障和安全风险。本文通过引入Shamir密码共享方案，
+		            将重加密过程分散到多个代理节点，
+		            任何少于门限值的代理节点集合都无法获得关于原始密文的有效信息，
+		            从而显著提高了系统的安全性。
 
-		      \item 采用国密算法确保系统安全性。相比国际通用的加密算法，国密算法不仅具有同等的安全强度，还在国内具有更好的兼容性和符合性。具体实现中，采用SM2椭圆曲线密码算法提供公钥加密功能，SM3哈希算法用于数据完整性验证和密钥派生，SM4对称加密算法用于高效的数据加密。
+		      \item 采用国密算法确保系统安全性。相比国际通用的加密算法，
+		            国密算法不仅具有同等的安全强度，还在国内具有更好的兼容性和符合性。
+		            具体实现中，采用SM2椭圆曲线密码算法提供公钥加密功能，
+		            SM3哈希算法用于数据完整性验证和密钥派生，SM4对称加密算法用于高效的数据加密。
 
-		      \item 实现了高效的混合加密机制。通过结合密钥封装机制（KEM）和数据封装机制（DEM），系统能够在保证安全性的同时提高加密效率。具体而言，使用SM4对称算法加密原始数据，再使用SM2公钥算法加密SM4的会话密钥，这种混合加密方式显著提高了系统处理大量数据时的性能。
+		      \item 实现了高效的混合加密机制。
+		            通过结合密钥封装机制（KEM）和数据封装机制（DEM），
+		            系统能够在保证安全性的同时提高加密效率。具体而言，
+		            使用SM4对称算法加密原始数据，再使用SM2公钥算法加密SM4的会话密钥，
+		            这种混合加密方式显著提高了系统处理大量数据时的性能。
 
-		      \item 设计了灵活的密钥管理方案。通过分布式的密钥生成和管理机制，系统能够灵活应对不同的应用场景需求。数据拥有方可以根据安全需要，动态调整门限值和代理节点数量，实现对授权访问的精细控制。同时，重加密密钥的分片管理确保了即使部分代理节点被攻破，整个系统的安全性仍然能够得到保障。
+		      \item 设计了灵活的密钥管理方案。通过分布式的密钥生成和管理机制，
+		            系统能够灵活应对不同的应用场景需求。数据拥有方可以根据安全需要，
+		            动态调整门限值和代理节点数量，实现对授权访问的精细控制。
+		            同时，重加密密钥的分片管理确保了即使部分代理节点被攻破，
+		            整个系统的安全性仍然能够得到保障。
 	      \end{itemize}
 
 	\item 性能与安全性验证
 	      \begin{itemize}
-		      \item 进行了全面的功能测试。测试内容包括密钥生成、加密解密、重加密密钥生成、重加密操作、密文合并以及最终解密等核心功能，确保系统各组件能够正确协同工作。测试结果表明，所有功能模块都能够按照预期运行，系统整体功能完备，操作流程顺畅。
+		      \item 进行了全面的功能测试。测试内容包括密钥生成、
+		            加密解密、重加密密钥生成、重加密操作、密文合并以及最终解密等核心功能，
+		            确保系统各组件能够正确协同工作。测试结果表明，所有功能模块都能够按照预期运行，
+		            系统整体功能完备，操作流程顺畅。
 
-		      \item 完成了系统性能评估。通过设置不同的参数组合，如变化节点数量N和门限值T，全面测试了系统在各种配置下的运行效率。测试数据表明，即使在节点数量较多的情况下，系统的运算时间仍然控制在合理范围内（远低于1秒），满足了实际应用的性能需求。特别是当门限值T设置为节点总数N的一半时，系统表现出最优的性能表现。
+		      \item 完成了系统性能评估。通过设置不同的参数组合，如变化节点数量N和门限值T，
+		            全面测试了系统在各种配置下的运行效率。测试数据表明，
+		            即使在节点数量较多的情况下，系统的运算时间仍然控制在合理范围内（远低于1秒），
+		            满足了实际应用的性能需求。特别是当门限值T设置为节点总数N的一半时，
+		            系统表现出最优的性能表现。
 
-		      \item 验证了安全机制的有效性。通过模拟各种攻击场景，验证了系统的安全防护能力。测试结果显示，在密钥部分泄露、节点部分失效或受到攻击的情况下，系统仍能维持数据的安全性，证明了门限机制在提升系统安全性方面的有效性。此外，安全性分析表明，系统能够抵抗选择明文攻击和选择密文攻击，保证了数据的机密性和完整性。
+		      \item 验证了安全机制的有效性。通过模拟各种攻击场景，验证了系统的安全防护能力。
+		            测试结果显示，在密钥部分泄露、节点部分失效或受到攻击的情况下，
+		            系统仍能维持数据的安全性，证明了门限机制在提升系统安全性方面的有效性。
+		            此外，安全性分析表明，系统能够抵抗选择明文攻击和选择密文攻击，
+		            保证了数据的机密性和完整性。
 
-		      \item 确认了系统的可靠性。通过在不同环境下的部署测试，本文确认了系统的可靠性。在本地测试环境和云端部署环境中，系统均表现出良好的稳定性和一致性，能够持续稳定地提供服务。特别是在异步处理数据和高并发访问的场景下，系统依然保持了预期的性能水平，证明了其在实际应用中的可靠性。
+		      \item 确认了系统的可靠性。通过在不同环境下的部署测试，本文确认了系统的可靠性。
+		            在本地测试环境和云端部署环境中，系统均表现出良好的稳定性和一致性，
+		            能够持续稳定地提供服务。特别是在异步处理数据和高并发访问的场景下，
+		            系统依然保持了预期的性能水平，证明了其在实际应用中的可靠性。
 	      \end{itemize}
 \end{enumerate}
 
@@ -165,7 +194,8 @@
 
 		      \item 实现灵活的权限管理。数据提供方可以精确控制数据使用权限，包
 		            括访问时间、访问范围甚至访问频率，而无需担心数据的原始副本
-		            泄露。这种细粒度的权限管理满足了各类数据交易的复杂需求，使得数据提供方能够在保护自身数据资产的同时，最大化数据的利用价值。
+		            泄露。这种细粒度的权限管理满足了各类数据交易的复杂需求，
+		            使得数据提供方能够在保护自身数据资产的同时，最大化数据的利用价值。
 
 		      \item 保护数据隐私。通过加密保护，确保敏感数据不会在未授权的情况下
 		            被访问，同时通过代理重加密技术，实现了数据的安全共享而无需
diff --git a/paper/chapters/pagetitle-chinese.tex b/paper/chapters/pagetitle-chinese.tex
index 347f500..76b5f19 100644
--- a/paper/chapters/pagetitle-chinese.tex
+++ b/paper/chapters/pagetitle-chinese.tex
@@ -43,7 +43,7 @@
 			\cline{2-2}
 			\makecell[c]{\bfseries\sihao 专\qquad 业}                   & \makecell[c]{\bfseries\sihao 信息安全}                                   \\
 			\cline{2-2}
-			\makecell[c]{\bfseries\sihao 班\qquad 级}                   & \makecell[c]{\bfseries\sihao 0231201}                                \\
+			\makecell[c]{\bfseries\sihao 班\qquad 级}                   & \makecell[c]{\bfseries\sihao 04042101}                               \\
 			\cline{2-2}
 			\makecell[c]{\bfseries\sihao 学\qquad 号}                   & \makecell[c]{\bfseries\sihao 2021212687}                             \\
 			\cline{2-2}
diff --git a/paper/images/chapters/central_server_db_log.png b/paper/images/chapters/central_server_db_log.png
new file mode 100644
index 0000000..8112191
Binary files /dev/null and b/paper/images/chapters/central_server_db_log.png differ
diff --git a/paper/images/chapters/central_server_msg_log.png b/paper/images/chapters/central_server_msg_log.png
new file mode 100644
index 0000000..3f4355d
Binary files /dev/null and b/paper/images/chapters/central_server_msg_log.png differ
diff --git a/paper/images/chapters/central_server_start_log.png b/paper/images/chapters/central_server_start_log.png
new file mode 100644
index 0000000..b8512bd
Binary files /dev/null and b/paper/images/chapters/central_server_start_log.png differ
diff --git a/paper/images/chapters/cfrag_cts_1.png b/paper/images/chapters/cfrag_cts_1.png
new file mode 100644
index 0000000..7de0d71
Binary files /dev/null and b/paper/images/chapters/cfrag_cts_1.png differ
diff --git a/paper/images/chapters/cfrag_cts_2.png b/paper/images/chapters/cfrag_cts_2.png
new file mode 100644
index 0000000..92655b7
Binary files /dev/null and b/paper/images/chapters/cfrag_cts_2.png differ
diff --git a/paper/images/chapters/check_capsule.png b/paper/images/chapters/check_capsule.png
new file mode 100644
index 0000000..11665ca
Binary files /dev/null and b/paper/images/chapters/check_capsule.png differ
diff --git a/paper/images/chapters/client_be_db.png b/paper/images/chapters/client_be_db.png
new file mode 100644
index 0000000..646bd93
Binary files /dev/null and b/paper/images/chapters/client_be_db.png differ
diff --git a/paper/images/chapters/client_fe.png b/paper/images/chapters/client_fe.png
new file mode 100644
index 0000000..1e72ea8
Binary files /dev/null and b/paper/images/chapters/client_fe.png differ
diff --git a/paper/images/chapters/client_response.png b/paper/images/chapters/client_response.png
new file mode 100644
index 0000000..e0271a9
Binary files /dev/null and b/paper/images/chapters/client_response.png differ
diff --git a/paper/images/chapters/client_start_log.png b/paper/images/chapters/client_start_log.png
new file mode 100644
index 0000000..05ca149
Binary files /dev/null and b/paper/images/chapters/client_start_log.png differ
diff --git a/paper/images/chapters/dec.png b/paper/images/chapters/dec.png
new file mode 100644
index 0000000..05837b0
Binary files /dev/null and b/paper/images/chapters/dec.png differ
diff --git a/paper/images/chapters/dec_test_1.png b/paper/images/chapters/dec_test_1.png
new file mode 100644
index 0000000..b9e2785
Binary files /dev/null and b/paper/images/chapters/dec_test_1.png differ
diff --git a/paper/images/chapters/dec_test_2.png b/paper/images/chapters/dec_test_2.png
new file mode 100644
index 0000000..52ae13f
Binary files /dev/null and b/paper/images/chapters/dec_test_2.png differ
diff --git a/paper/images/chapters/decapsulate.png b/paper/images/chapters/decapsulate.png
new file mode 100644
index 0000000..b83cc4c
Binary files /dev/null and b/paper/images/chapters/decapsulate.png differ
diff --git a/paper/images/chapters/decapsulatefrags.png b/paper/images/chapters/decapsulatefrags.png
new file mode 100644
index 0000000..36b663b
Binary files /dev/null and b/paper/images/chapters/decapsulatefrags.png differ
diff --git a/paper/images/chapters/decfrags.png b/paper/images/chapters/decfrags.png
new file mode 100644
index 0000000..0dc56dd
Binary files /dev/null and b/paper/images/chapters/decfrags.png differ
diff --git a/paper/images/chapters/dependencies.png b/paper/images/chapters/dependencies.png
new file mode 100644
index 0000000..34062a5
Binary files /dev/null and b/paper/images/chapters/dependencies.png differ
diff --git a/paper/images/chapters/enc.png b/paper/images/chapters/enc.png
new file mode 100644
index 0000000..98f473f
Binary files /dev/null and b/paper/images/chapters/enc.png differ
diff --git a/paper/images/chapters/enc_message_1.png b/paper/images/chapters/enc_message_1.png
new file mode 100644
index 0000000..8057a54
Binary files /dev/null and b/paper/images/chapters/enc_message_1.png differ
diff --git a/paper/images/chapters/enc_message_2.png b/paper/images/chapters/enc_message_2.png
new file mode 100644
index 0000000..00af3f3
Binary files /dev/null and b/paper/images/chapters/enc_message_2.png differ
diff --git a/paper/images/chapters/encapsulate.png b/paper/images/chapters/encapsulate.png
new file mode 100644
index 0000000..ee0f6bf
Binary files /dev/null and b/paper/images/chapters/encapsulate.png differ
diff --git a/paper/images/chapters/fixed_n.png b/paper/images/chapters/fixed_n.png
new file mode 100644
index 0000000..7b8dceb
Binary files /dev/null and b/paper/images/chapters/fixed_n.png differ
diff --git a/paper/images/chapters/fixed_t.png b/paper/images/chapters/fixed_t.png
new file mode 100644
index 0000000..af594cf
Binary files /dev/null and b/paper/images/chapters/fixed_t.png differ
diff --git a/paper/images/chapters/gen_pk_sk_1.png b/paper/images/chapters/gen_pk_sk_1.png
new file mode 100644
index 0000000..8f680b6
Binary files /dev/null and b/paper/images/chapters/gen_pk_sk_1.png differ
diff --git a/paper/images/chapters/gen_pk_sk_2.png b/paper/images/chapters/gen_pk_sk_2.png
new file mode 100644
index 0000000..889ede3
Binary files /dev/null and b/paper/images/chapters/gen_pk_sk_2.png differ
diff --git a/paper/images/chapters/generate_key_pair.png b/paper/images/chapters/generate_key_pair.png
new file mode 100644
index 0000000..1d49189
Binary files /dev/null and b/paper/images/chapters/generate_key_pair.png differ
diff --git a/paper/images/chapters/generate_rekey.png b/paper/images/chapters/generate_rekey.png
new file mode 100644
index 0000000..74c55b1
Binary files /dev/null and b/paper/images/chapters/generate_rekey.png differ
diff --git a/paper/images/chapters/generate_rekey_test_1.png b/paper/images/chapters/generate_rekey_test_1.png
new file mode 100644
index 0000000..bdaeba8
Binary files /dev/null and b/paper/images/chapters/generate_rekey_test_1.png differ
diff --git a/paper/images/chapters/generate_rekey_test_2.png b/paper/images/chapters/generate_rekey_test_2.png
new file mode 100644
index 0000000..e1c8207
Binary files /dev/null and b/paper/images/chapters/generate_rekey_test_2.png differ
diff --git a/paper/images/chapters/gmssl.png b/paper/images/chapters/gmssl.png
new file mode 100644
index 0000000..b3f9d2e
Binary files /dev/null and b/paper/images/chapters/gmssl.png differ
diff --git a/paper/images/chapters/half_n.png b/paper/images/chapters/half_n.png
new file mode 100644
index 0000000..3e1eef6
Binary files /dev/null and b/paper/images/chapters/half_n.png differ
diff --git a/paper/images/chapters/hash5.png b/paper/images/chapters/hash5.png
new file mode 100644
index 0000000..4a20d2e
Binary files /dev/null and b/paper/images/chapters/hash5.png differ
diff --git a/paper/images/chapters/hash6.png b/paper/images/chapters/hash6.png
new file mode 100644
index 0000000..919695f
Binary files /dev/null and b/paper/images/chapters/hash6.png differ
diff --git a/paper/images/chapters/hashes.png b/paper/images/chapters/hashes.png
new file mode 100644
index 0000000..1a62413
Binary files /dev/null and b/paper/images/chapters/hashes.png differ
diff --git a/paper/images/chapters/kdf.png b/paper/images/chapters/kdf.png
new file mode 100644
index 0000000..f26f815
Binary files /dev/null and b/paper/images/chapters/kdf.png differ
diff --git a/paper/images/chapters/mergecfrag.png b/paper/images/chapters/mergecfrag.png
new file mode 100644
index 0000000..9898409
Binary files /dev/null and b/paper/images/chapters/mergecfrag.png differ
diff --git a/paper/images/chapters/mergecfrag_test_1.png b/paper/images/chapters/mergecfrag_test_1.png
new file mode 100644
index 0000000..b1ab3ce
Binary files /dev/null and b/paper/images/chapters/mergecfrag_test_1.png differ
diff --git a/paper/images/chapters/mergecfrag_test_2.png b/paper/images/chapters/mergecfrag_test_2.png
new file mode 100644
index 0000000..b8cfea4
Binary files /dev/null and b/paper/images/chapters/mergecfrag_test_2.png differ
diff --git a/paper/images/chapters/node_start_log.png b/paper/images/chapters/node_start_log.png
new file mode 100644
index 0000000..8b5908f
Binary files /dev/null and b/paper/images/chapters/node_start_log.png differ
diff --git a/paper/images/chapters/polynomial.png b/paper/images/chapters/polynomial.png
new file mode 100644
index 0000000..6f7245d
Binary files /dev/null and b/paper/images/chapters/polynomial.png differ
diff --git a/paper/images/chapters/reenc.png b/paper/images/chapters/reenc.png
new file mode 100644
index 0000000..8323011
Binary files /dev/null and b/paper/images/chapters/reenc.png differ
diff --git a/paper/images/chapters/reencapsulate.png b/paper/images/chapters/reencapsulate.png
new file mode 100644
index 0000000..bc4122e
Binary files /dev/null and b/paper/images/chapters/reencapsulate.png differ
diff --git a/paper/images/chapters/sm2_methods.png b/paper/images/chapters/sm2_methods.png
new file mode 100644
index 0000000..9375d6b
Binary files /dev/null and b/paper/images/chapters/sm2_methods.png differ
diff --git a/paper/images/chapters/sm2_parameter.png b/paper/images/chapters/sm2_parameter.png
new file mode 100644
index 0000000..35b7953
Binary files /dev/null and b/paper/images/chapters/sm2_parameter.png differ
diff --git a/paper/images/chapters/sm2_python_parameter.png b/paper/images/chapters/sm2_python_parameter.png
new file mode 100644
index 0000000..d7e851d
Binary files /dev/null and b/paper/images/chapters/sm2_python_parameter.png differ
diff --git a/paper/images/chapters/system_flow.png b/paper/images/chapters/system_flow.png
new file mode 100644
index 0000000..31f6ea3
Binary files /dev/null and b/paper/images/chapters/system_flow.png differ
diff --git a/paper/latex_settings/custom-chinese.tex b/paper/latex_settings/custom-chinese.tex
index d3ffa1e..48583c1 100644
--- a/paper/latex_settings/custom-chinese.tex
+++ b/paper/latex_settings/custom-chinese.tex
@@ -30,6 +30,9 @@
 \usepackage{soul}
 \usepackage{color,xcolor}
 
+% 横向表格
+\usepackage{lscape}
+
 
 
 \geometry{a4paper,top=3cm,bottom=2.5cm,left=2.5cm,right=2.5cm}
diff --git a/paper/reference/ref.bib b/paper/reference/ref.bib
index 3d43d25..fb3436d 100644
--- a/paper/reference/ref.bib
+++ b/paper/reference/ref.bib
@@ -55,7 +55,7 @@
   keywords = {区块链|代理重加密|隐私保护|SM2|受控共享},
   url = {https://www.ejournal.org.cn/CN/10.12263/DZXB.20210785},
   doi = {10.12263/DZXB.20210785},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{lixiang2022,
@@ -84,7 +84,7 @@
   pages = "127--144",
   isbn = "978-3-540-69795-4",
   url = {https://link.springer.com/chapter/10.1007/BFb0054122},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @techreport{nakamoto2008bitcoin,
@@ -94,7 +94,7 @@
   month = {oct},
   url = {https://bitcoin.org/bitcoin.pdf},
   type = {Whitepaper},
-  citedate = 2025-04-08,
+  citedate = {2025-04-08},
 }
 
 @article{zhu2017survey,
@@ -105,7 +105,7 @@
   number = {10},
   pages = {2170--2186},
   year = {2017},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{noether2016ring,
@@ -115,7 +115,7 @@
   volume = {1},
   pages = {1--18},
   year = {2016},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{miers2013zerocoin,
@@ -125,7 +125,7 @@
   pages = {397--411},
   year = {2013},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{kosba2016hawk,
@@ -136,7 +136,7 @@
   pages = {839--858},
   year = {2016},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{maesa2017blockchain,
@@ -147,7 +147,7 @@
   pages = {206--220},
   year = {2017},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{maesa2018blockchain,
@@ -160,7 +160,7 @@
   pages = {1379--1386},
   year = {2018},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{wang2018medical,
@@ -171,7 +171,7 @@
   pages = {12--16},
   year = {2018},
   organization = {ACM},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{li2019blockchain,
@@ -183,7 +183,7 @@
   number = {5},
   pages = {762--771},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{dong2018efficient,
@@ -194,7 +194,7 @@
   number = {5},
   pages = {1021--1036},
   year = {2018},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{wu2019electronic,
@@ -205,7 +205,7 @@
   pages = {13--17},
   year = {2019},
   organization = {ACM},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2018data,
@@ -217,7 +217,7 @@
   pages = {1--6},
   year = {2018},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wu2019efficient,
@@ -229,7 +229,7 @@
   number = {7/8},
   pages = {401--411},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{tian2019algorithm,
@@ -240,7 +240,7 @@
   number = {11},
   pages = {101--111},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{feng2020blockchain,
@@ -252,7 +252,7 @@
   number = {1},
   pages = {871--890},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2019model,
@@ -263,7 +263,7 @@
   number = {6},
   pages = {1661--1669},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{su2020assured,
@@ -275,7 +275,7 @@
   number = {5},
   pages = {1563--1572},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{su2020prta,
@@ -286,7 +286,7 @@
   volume = {527},
   pages = {533--547},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2019controlled,
@@ -297,7 +297,7 @@
   volume = {130},
   pages = {153--165},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{samanthula2015secure,
@@ -309,7 +309,7 @@
   volume = {48},
   pages = {196--212},
   year = {2015},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{blaze1998divertible,
@@ -320,7 +320,7 @@
   pages = {127--144},
   year = {1998},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{li2009certificateless,
@@ -331,7 +331,7 @@
   number = {4},
   pages = {813--830},
   year = {2016},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{paul2021provably,
@@ -343,7 +343,7 @@
   number = {2},
   pages = {1--12},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{liu2017efficient,
@@ -354,7 +354,7 @@
   number = {4},
   pages = {2254--2275},
   year = {2017},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{bhatia2018secure,
@@ -365,7 +365,7 @@
   volume = {29},
   number = {6},
   year = {2018},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{selvi2017efficient,
@@ -377,7 +377,7 @@
   pages = {413--433},
   year = {2017},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @patent{li2015certificateless,
@@ -386,7 +386,7 @@
   author = {Li, Jiguo and Zhao, Xuexia and Zhang, Yichen},
   number = {CN201510434184.7},
   year = {2015},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{patil2020non,
@@ -398,7 +398,7 @@
   number = {2},
   pages = {102411.1--102411.12},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{chen2018threshold,
@@ -409,7 +409,7 @@
   pages = {16--25},
   year = {2018},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{patil2019rsa,
@@ -421,7 +421,7 @@
   pages = {349--363},
   year = {2019},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{li2021threshold,
@@ -433,7 +433,7 @@
   number = {11},
   pages = {3350--3358},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @misc{miracl,
@@ -441,7 +441,7 @@
   author = {Shamus Software Ltd.},
   year = {2019},
   howpublished = {\url{https://miracl.com/display/EXT/MIRACL}},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{butpheng2020security,
@@ -453,7 +453,7 @@
   number = {7},
   pages = {1191},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{hathaliya2020exhaustive,
@@ -464,7 +464,7 @@
   volume = {153},
   pages = {311--335},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{xu2021pp,
@@ -476,7 +476,7 @@
   number = {3},
   pages = {3730--3739},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2016attribute,
@@ -487,7 +487,7 @@
   number = {8},
   pages = {1661--1673},
   year = {2016},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{zhang2020multi,
@@ -499,7 +499,7 @@
   number = {1},
   pages = {156--167},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{shahid2020psds,
@@ -510,7 +510,7 @@
   volume = {8},
   pages = {118285--118298},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{zichichim2020distributed,
@@ -522,7 +522,7 @@
   pages = {1--6},
   year = {2020},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{yu2019ciphertext,
@@ -534,7 +534,7 @@
   number = {4},
   pages = {49--57},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{guo2019multi,
@@ -545,7 +545,7 @@
   pages = {6--11},
   year = {2019},
   organization = {ACM},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{zuo2021bcas,
@@ -557,7 +557,7 @@
   number = {3},
   pages = {1--16},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2018secure,
@@ -569,7 +569,7 @@
   number = {8},
   pages = {152--164},
   year = {2018},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{wang2018blockchain,
@@ -580,7 +580,7 @@
   volume = {6},
   pages = {38437--38450},
   year = {2018},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{xia2017medshare,
@@ -591,7 +591,7 @@
   volume = {5},
   pages = {14757--14767},
   year = {2017},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{yang2021method,
@@ -602,7 +602,7 @@
   number = {3},
   pages = {21--30},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{li2020data,
@@ -614,7 +614,7 @@
   number = {8},
   pages = {16--24},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{zhai2020research,
@@ -626,7 +626,7 @@
   number = {5},
   pages = {103--112},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{pournaghi2020medsba,
@@ -638,7 +638,7 @@
   number = {11},
   pages = {4613--4641},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{shamshad2020secure,
@@ -649,7 +649,7 @@
   volume = {55},
   pages = {102590},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{zhang2019hidden,
@@ -660,7 +660,7 @@
   volume = {7},
   pages = {33202--33213},
   year = {2019},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{ying2020fhpt,
@@ -671,7 +671,7 @@
   pages = {1--6},
   year = {2020},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{hu2021expressive,
@@ -683,7 +683,7 @@
   number = {1},
   pages = {365--376},
   year = {2021},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{cui2016efficient,
@@ -694,7 +694,7 @@
   pages = {19--38},
   year = {2016},
   organization = {Springer},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{yan2018multi,
@@ -706,7 +706,7 @@
   number = {2},
   pages = {122--128},
   year = {2018},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{hong2017towards,
@@ -718,7 +718,7 @@
   pages = {218--223},
   year = {2017},
   organization = {IEEE},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{zhang2020attribute,
@@ -730,7 +730,7 @@
   number = {6},
   pages = {1009--1020},
   year = {2020},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @inproceedings{mao2018anonymous,
@@ -745,7 +745,7 @@
   address = "Cham",
   pages = "95--110",
   isbn = "978-3-030-02744-5",
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 
@@ -763,7 +763,7 @@
             Zhou},
   keywords = {Data security, Cryptographic access control, Access policy
               flexibility, Proxy re-encryption, Attribute-based encryption},
-  citedate = 2025-03-03,
+  citedate = {2025-03-03},
 }
 
 @article{Shamir1979How,
@@ -790,7 +790,7 @@
   pages = {612–613},
   numpages = {2},
   keywords = {key management, interpolation, cryptography},
-  citedate = 2025-04-07,
+  citedate = {2025-04-07},
 }
 
 @techreport{nist800-57r5,
@@ -804,7 +804,7 @@
          https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf
          },
   address = {Gaithersburg, MD, USA},
-  citedate = 2025-04-18,
+  citedate = {2025-04-18},
 }
 
 @book{hankerson2006guide,
@@ -815,7 +815,7 @@
   title = {Guide to Elliptic Curve Cryptography},
   isbn = {0-387-95273-X},
   doi = {10.1007/b97644},
-  citedate = 2025-04-18,
+  citedate = {2025-04-18},
 }
 
 @techreport{SM3StandardGroup2013,
@@ -827,7 +827,7 @@
   type = {标准编制说明},
   url = {https://www.tc260.org.cn/file/20140415124745521547.doc},
   address = {北京},
-  citedate = 2025-04-18,
+  citedate = {2025-04-18},
 }
 
 @inproceedings{Lenstra1990GNFS,
@@ -846,7 +846,7 @@
   numpages = {9},
   location = {Baltimore, Maryland, USA},
   series = {STOC '90},
-  citedate = 2025-04-28,
+  citedate = {2025-04-28},
 }
 
 @techreport{Wang2004Collisions,
@@ -855,5 +855,150 @@
   howpublished = {Cryptology {ePrint} Archive, Paper 2004/199},
   year = {2004},
   url = {https://eprint.iacr.org/2004/199},
-  citedate = 2025-04-28,
+  citedate = {2025-04-28},
+}
+
+@article{ateniese2006improved,
+  author = {Ateniese, Giuseppe and Fu, Kevin and Green, Matthew and Hohenberger,
+            Susan},
+  title = {Improved proxy re-encryption schemes with applications to secure
+           distributed storage},
+  year = {2006},
+  issue_date = {February 2006},
+  publisher = {Association for Computing Machinery},
+  address = {New York, NY, USA},
+  volume = {9},
+  number = {1},
+  issn = {1094-9224},
+  url = {https://doi.org/10.1145/1127345.1127346},
+  doi = {10.1145/1127345.1127346},
+  abstract = {In 1998, Blaze, Bleumer, and Strauss (BBS) proposed an application
+              called atomic proxy re-encryption, in which a semitrusted proxy
+              converts a ciphertext for Alice into a ciphertext for Bob without
+              seeing the underlying plaintext. We predict that fast and secure
+              re-encryption will become increasingly popular as a method for
+              managing encrypted file systems. Although efficiently computable,
+              the wide-spread adoption of BBS re-encryption has been hindered by
+              considerable security risks. Following recent work of Dodis and
+              Ivan, we present new re-encryption schemes that realize a stronger
+              notion of security and demonstrate the usefulness of proxy
+              re-encryption as a method of adding access control to a secure file
+              system. Performance measurements of our experimental file system
+              demonstrate that proxy re-encryption can work effectively in
+              practice.},
+  journal = {ACM Trans. Inf. Syst. Secur.},
+  month = feb,
+  pages = {1–30},
+  numpages = {30},
+  keywords = {key translation, double decryption, bilinear maps, Proxy
+              re-encryption},
+  citedate = {2025-05-02},
+}
+
+@article{canetti2007chosen,
+  author = {Ran Canetti and Susan Hohenberger},
+  title = {Chosen-Ciphertext Secure Proxy Re-Encryption},
+  howpublished = {Cryptology {ePrint} Archive, Paper 2007/171},
+  year = {2007},
+  url = {https://eprint.iacr.org/2007/171},
+  journal = {ACM CCS 2007},
+  citedate = {2025-05-02},
+}
+
+@inproceedings{liang2009provably,
+  author = {Liang, Xiaohui and Cao, Zhenfu and Lin, Huang and Xing, Dongsheng},
+  title = {Provably secure and efficient bounded ciphertext policy attribute
+           based encryption},
+  year = {2009},
+  isbn = {9781605583945},
+  publisher = {Association for Computing Machinery},
+  address = {New York, NY, USA},
+  url = {https://doi.org/10.1145/1533057.1533102},
+  doi = {10.1145/1533057.1533102},
+  abstract = {Ciphertext policy attribute based encryption (CPABE) allows a
+              sender to distribute messages based on an access policy which can
+              be expressed as a boolean function consisting of (OR, AND) gates
+              between attributes. A receiver whose secret key is associated with
+              those attributes could only decrypt a ciphertext successfully if
+              and only if his attributes satisfy the ciphertext's access policy.
+              Fine-grained access control, a new concept mentioned by GPSW in
+              CCS'06 can realize a more delicate access policy which could be
+              represented as an access tree with threshold gates connecting
+              attributes.In ICALP'08, Goyal et al. design a bounded CPABE
+              (denoted as GJPS) with fine-grained access policy which can be
+              proven secure under a number-theoretic assumption. In this paper,
+              we improve their scheme by providing faster encryption / decryption
+              algorithm and shortened ciphertext size. Moreover, we use one-time
+              signature technique to obtain a chosen ciphertext secure extension
+              and give its complete security proof in the standard model under
+              traditional Decisional Bilinear Diffie-Hellman (DBDH) assumption
+              and strong existential unforgeability of one-time signature scheme.
+              },
+  booktitle = {Proceedings of the 4th International Symposium on Information,
+               Computer, and Communications Security},
+  pages = {343–352},
+  numpages = {10},
+  keywords = {access control, attribute based encryption, public key
+              cryptography},
+  location = {Sydney, Australia},
+  series = {ASIACCS '09},
+  citedate = {2025-05-02},
+}
+
+@inproceedings{yu2010achieving,
+  author = {Yu, Shucheng and Wang, Cong and Ren, Kui and Lou, Wenjing},
+  booktitle = {2010 Proceedings IEEE INFOCOM},
+  title = {Achieving Secure, Scalable, and Fine-grained Data Access Control in
+           Cloud Computing},
+  year = {2010},
+  volume = {},
+  number = {},
+  pages = {1-9},
+  keywords = {Access control;Cloud computing;Medical services;Data
+              security;Business;Web and internet services;Web
+              server;Cryptography;Service oriented architecture;Memory},
+  doi = {10.1109/INFCOM.2010.5462174},
+  citedate = {2025-05-02},
+}
+
+@article{singh2014lattice,
+  title = {Lattice-based identity-based resplittable threshold public key
+           encryption scheme},
+  author = {Singh, K. and Rangan, C. P. and Banerjee, A. K.},
+  journal = {International Journal of Computer Mathematics},
+  volume = {93},
+  number = {2},
+  pages = {289--307},
+  year = {2014},
+  publisher = {Taylor \& Francis},
+  doi = {10.1080/00207160.2014.928286},
+  citedate = {2025-05-02},
+}
+
+@inproceedings{xagawa2010proxy,
+  title = {Proxy Re-Encryption based on Learning with Errors},
+  author = {Xagawa, Keita and Tanaka, Keisuke},
+  booktitle = {数理解析研究所講究録},
+  volume = {1691},
+  pages = {29--35},
+  year = {2010},
+  address = {Kyoto, Japan},
+  publisher = {京都大学数理解析研究所},
+  series = {Mathematical Foundation of Algorithms and Computer Science},
+  note = {日文题目: 格子に基づく代理人再暗号方式 (アルゴリズムと計算機科学の数理的基盤とその応用)},
+  keywords = {proxy re-encryption, learning with errors, lattice problems},
+  url = {http://hdl.handle.net/2433/141576},
+  citedate = {2025-05-02},
+}
+
+@patent{zhang2024,
+  author = {张云兵 and 赵朝晖},
+  title = {一种基于SM2协同算法的代理重加密方法},
+  number = {CN118018196B},
+  year = {2024},
+  nationality = {CN},
+  assignee = {商密广州信息科技有限公司},
+  filing-date = {2024-02-18},
+  issue-date = {2024-09-03},
+  url = {https://patents.google.com/patent/CN118018196B},
 }
diff --git a/requirements.txt b/requirements.txt
deleted file mode 100644
index 14a0e4e..0000000
--- a/requirements.txt
+++ /dev/null
@@ -1,5 +0,0 @@
-gmssl-python>=2.2.2,<3.0.0
-fastapi
-uvicorn
-requests
-web3