CAESAR竞赛认证加密算法全解析：从AEGIS到Ascon的工程选型指南

1. 项目概述CAESAR竞赛与认证加密算法的演进在当今这个数据驱动一切的时代信息安全早已不是可有可无的附加项而是数字世界的基石。无论是我们手机里的支付信息、云端存储的私人文件还是工业控制系统的核心指令其安全都依赖于一套可靠的密码学“锁具”。传统的做法是先用一把“锁”加密算法如AES把数据锁进保险箱加密再用另一把“锁”认证算法如HMAC给保险箱贴上封条生成消息认证码。这种方法虽然有效但步骤繁琐且两把“锁”的配合稍有不慎——比如先认证后加密MAC-then-Encrypt——就可能留下安全缝隙让攻击者有隙可乘。认证加密Authenticated Encryption, AE算法的出现就是为了解决这个“两把锁”的痛点。它本质上是一个“一体化保险箱”在加密数据的同时就自动生成了独一无二的、防篡改的“封条”认证标签。接收方只需用同一把钥匙打开就能同时验证数据的完整性和真实性并解密出原始内容。这不仅简化了流程降低了实现复杂度更重要的是它在密码学理论上被证明能提供更强的安全保证避免了组合使用独立算法时可能产生的微妙安全漏洞。正是在这样的背景下由美国国家标准与技术研究院NIST发起的CAESAR竞赛Competition for Authenticated Encryption: Security, Applicability, and Robustness应运而生。你可以把它看作是密码学界的“奥林匹克”目标是寻找和标准化下一代超越现有标杆AES-GCM的认证加密算法。从2013年启动到2018年结束这场历时五年的竞赛吸引了全球顶尖密码学家的目光经过三轮严苛的筛选从数十个提交方案中最终角逐出了七位“决赛选手”。本文的目的就是为你深入剖析这场竞赛的精华不仅解读这些最终入围的明星算法——如ACORN、AEGIS、Ascon、Deoxys、MORUS、OCB以及COLM——的设计哲学与核心机制更会结合大量的工程实践视角分析它们在不同场景下的性能表现、安全边界以及那些在标准论文里不会明说的“坑”与技巧。无论你是正在为产品选型的工程师还是对前沿密码学感兴趣的研究者这篇文章都将为你提供一份从理论到实践的深度指南。2. CAESAR竞赛核心要求与候选算法设计思路解析CAESAR竞赛并非漫无目的地征集算法它有一套清晰且严格的设计目标。理解这些目标是理解所有候选算法为何如此设计的钥匙。2.1 竞赛的三大核心支柱安全、适用性与鲁棒性竞赛名称中的三个关键词——Security安全、Applicability适用性、Robustness鲁棒性——构成了评估算法的黄金三角。安全性是底线也是最复杂的一环。它远不止抵抗传统的差分分析、线性分析那么简单。CAESAR要求算法能同时保障机密性Ciphertext Indistinguishability under Chosen Plaintext Attack, IND-CPA和完整性Ciphertext Integrity, INT-CTXT。更重要的是它强调在Nonce误用场景下的安全性。Nonce一次性数值是许多现代AE算法防止重放攻击的关键。但在实际部署中由于伪随机数生成器PRNG故障或实现错误Nonce可能会被重复使用。一个健壮的AE算法应当在此种“误用”下其机密性损失是可控的、渐进的而非瞬间崩溃。此外抵抗侧信道攻击如功耗分析、时序分析和故障注入攻击的能力也越来越成为衡量安全性的重要维度。适用性关注的是算法能否落地。这包括了性能在软件x86, ARM和硬件ASIC, FPGA上的吞吐率、延迟和资源占用。灵活性是否支持并行处理能否处理任意长度的关联数据Associated Data, AD和明文对Nonce的长度是否有苛刻要求简洁性设计是否优雅、易于实现和验证复杂的算法往往意味着更多的实现错误和安全漏洞。鲁棒性则是一种“防呆”设计。它要求算法在面对非预期的输入或使用方式时仍能保持尽可能多的安全性。例如即使关联数据为空或者算法被错误地当作仅加密或仅认证的组件来使用其安全性的退化也应是可知和可控的。2.2 候选算法的四大设计流派面对这些要求决赛圈的算法演化出了几种鲜明的设计哲学主要可以归为四类2.2.1 基于分组密码的AEBC-AE这类算法以AES等成熟的分组密码为“积木”通过精巧的操作模式来构建AE功能。代表算法有OCB、Deoxys和COLM。核心思想将分组密码如AES视为一个理想的伪随机置换PRP在其基础上通过偏移量Tweak或反馈结构来同时实现加密和认证。优势继承了AES等标准算法经过千锤百炼的安全性分析且能直接利用现代CPU的AES-NI指令集获得极高的软件性能。结构清晰安全性证明相对成熟。挑战性能严重依赖底层分组密码的效率。在无AES硬件加速的环境如某些嵌入式设备中可能表现不佳。2.2.2 基于海绵结构的AESH-AE这类算法源于SHA-3哈希函数竞赛的冠军设计——海绵结构Sponge Construction。代表算法是Ascon第三轮中的Ketje、Keyak、NORX也属此类。核心思想算法内部维护一个固定大小的“状态”Sponge State通过一个置换函数Permutation反复“吸收”明文和关联数据再“挤出”密文和认证标签。整个过程像海绵吸水再挤水。优势结构非常简洁通常只使用比特位的与、或、非、异或和循环移位操作没有复杂的代数运算。这使得它在硬件实现上面积小、功耗低且天然对侧信道攻击有一定抵抗力。它也能很灵活地处理任意长度的数据。挑战软件性能尤其是在无位切片优化时可能不如基于AES-NI的算法。并行化能力受限于海绵结构的串行吸收过程。2.2.3 基于流密码的AESC-AE这类算法借鉴了流密码的思想通过内部状态生成密钥流再与明文结合。决赛中唯一的代表是ACORN。核心思想算法内部有一个不断更新的线性反馈移位寄存器LFSR或类似结构产生的密钥流与明文逐比特异或产生密文。认证标签的生成也与这个内部状态紧密相关。优势实现极其简单硬件门电路数量少非常适合超轻量级场景。可以逐比特或逐字节处理数据适合流式传输。挑战安全性分析通常比分组密码更复杂对初始状态IV和Key的敏感性极高。一旦内部状态被部分恢复可能导致灾难性后果。2.2.4 专用结构AED-AE这类算法为了极致性能抛弃了传统的分组或海绵结构从头设计专用的置换或状态更新函数。代表算法是AEGIS和MORUS。核心思想设计一个快速的非线性状态更新函数常使用AES的轮函数或其他自定义操作让大量数据块可以并行地影响一个大的内部状态最终从状态中提取出密钥流和认证标签。优势通过深度优化可以在支持并行指令如SIMD的平台上获得惊人的吞吐率。AEGIS和MORUS在Intel Haswell处理器上的性能远超AES-GCM。挑战专用结构缺乏像AES那样长达二十年的全球密码分析历史其长期安全性需要更多时间检验。设计复杂度高实现错误的风险相对较大。实操心得如何根据场景选择技术路线在实际项目中选型没有“最好”只有“最合适”。追求极限软件性能服务器、桌面端优先考虑AEGIS、MORUS或基于AES-NI的OCB、Deoxys。实测中AEGIS-128L在长消息加密上可以达到0.48 cycles/byte的恐怖速度。资源受限的物联网设备Ascon和ACORN是首选。Ascon在硬件面积和功耗上表现优异且其简洁的比特操作易于实施侧信道防护。ACORN则胜在极致的硬件面积效率。需要强鲁棒性和Nonce误用抵抗关注COLM及其前身AES-COPA和Deoxys-II。它们专门针对Nonce重复使用的场景进行了设计。与现有AES生态深度集成基于AES的OCB、Deoxys、COLM更容易通过现有安全模块的认证。3. 决赛圈核心算法深度剖析与实操要点纸上得来终觉浅绝知此事要躬行。下面我们深入到几个最具代表性的决赛算法内部看看它们是如何工作的以及在实现和使用时需要注意什么。3.1 Ascon轻量级冠军的简约之美Ascon最终赢得了CAESAR竞赛轻量级应用场景的推荐其设计充分体现了“少即是多”的哲学。3.1.1 核心结构与工作流程Ascon使用一个320比特的内部状态分为一个外部速率部分r比特通常为64或128和一个内部容量部分c比特256或192。它采用海绵双工Duplex模式初始化将密钥K和Nonce N通过置换函数$p^a$a轮通常12轮混入状态。处理关联数据将AD分组每轮吸收一个r比特的分组到状态中并用$p^b$置换b轮通常6或8轮进行搅拌。如果无AD则跳过。加密/解密同样分组处理明文P。在吸收阶段将明文分组与状态的速率部分异或产生密文分组C。同样使用$p^b$进行搅拌。最终化将密钥K再次混入状态经过$p^a$轮置换后从状态中提取认证标签T。# Ascon加密过程伪代码示意极度简化突出流程 def ascon_encrypt(K, N, AD, P): # 初始化状态 state IV || K || N state permutation_p_a(state) # 吸收关联数据 for ad_block in split(AD): state_rate_part ^ ad_block state permutation_p_b(state) # 域分隔状态速率部分 ^ 1 state_rate_part ^ 1 # 加密并吸收明文 C [] for p_block in split(P): c_block state_rate_part ^ p_block C.append(c_block) state_rate_part c_block # 海绵结构密文反馈 state permutation_p_b(state) # 最终化生成标签 state ^ (0* || K) # 密钥回注 state permutation_p_a(state) T truncate(state_rate_part, tag_len) return C, T3.1.2 实操要点与避坑指南Nonce管理是生命线与大多数海绵结构算法一样Ascon严格要求Nonce的唯一性。重复使用同一个Key, Nonce对进行加密会完全破坏机密性。务必使用密码学安全的随机数生成器。侧信道防护的便利性Ascon的置换函数仅由AND、NOT、XOR、循环移位构成没有查表S-Box或复杂的算术运算。这使得在硬件上实现其阈值实现等掩码防护方案相对直接成本较低。这是它赢得轻量级赛道的关键优势之一。并行性的局限海绵结构本质上是串行的。当前数据块的处理依赖于前一个数据块处理后的状态。因此Ascon无法像CTR或某些专用模式那样对数据块进行并行加密。这在需要极高吞吐率的大数据流场景中是一个劣势。状态大小与性能权衡Ascon-128128位安全等级使用320比特状态r64 c256而Ascon-128a追求更高速度使用r128 c192。更大的r值意味着每次置换处理的数据更多吞吐率更高但安全性理论边界由c决定略有变化。选择时需要根据具体安全等级和性能要求决定。3.2 AEGIS为现代CPU而生的性能怪兽如果说Ascon是精巧的瑞士军刀那AEGIS就是一把为性能而生的重剑。它完全放弃了传统模式设计了一套专用的、高度并行的状态更新机制。3.2.1 核心结构与工作流程AEGIS如AEGIS-128L维护多个例如8个128位的状态寄存器$S_0, S_1, ..., S_7$。其核心是使用AES的轮函数特别是AESENC指令来高效地更新这些状态。状态初始化用密钥K和Nonce N通过多轮AES轮函数初始化状态寄存器。吸收明文并更新状态对于每一个128位明文块$P_i$密文$C_i$由当前所有状态值的复杂函数通常是异或和与$P_i$异或产生。然后状态寄存器会使用$P_i$和$C_i$或仅$P_i$通过AES轮函数进行并行更新。这个更新过程是高度并行的多个状态寄存器可以同时计算。生成认证标签标签是最终状态的一个函数同样涉及所有状态寄存器。3.2.2 实操要点与避坑指南硬件加速是灵魂AEGIS的性能优势完全建立在AES-NI指令集之上。在支持AES-NI的x86/ARM平台上其速度一骑绝尘。但在没有该指令集的平台如某些老旧或嵌入式架构其性能会大打折扣因为需要用软件模拟AES轮函数。巨大的状态带来高并行度AEGIS-128L维护着8个128位状态总计1024比特。这个巨大的状态空间是其安全性和并行能力的来源。在实现时可以利用SIMD指令如AVX2一次性处理多个状态更新最大化CPU流水线利用率。认证与加密的强耦合AEGIS的认证标签生成与整个加密历史强相关。这意味着它无法像某些模式如Encrypt-then-MAC那样先流式输出密文最后再计算标签。必须等到所有数据处理完毕才能生成和验证标签这在某些低延迟场景下可能需要考虑。安全分析仍在进行由于其专用结构AEGIS的密码学分析不如AES那样透彻。虽然目前没有发现致命弱点且其设计者提供了详细的安全论证但在对长期安全性有极端要求的场景如国家机密基于标准化分组密码的模式如OCB可能仍是更保守的选择。3.3 OCB优雅而高效的“老将”OCB模式并非CAESAR竞赛的新发明它由密码学家Phillip Rogaway等人设计已有近二十年历史。它代表了基于分组密码的AE模式的一个理论高峰。3.3.1 核心思想偏移码本模式OCB的核心是一种叫做偏移码本的加密方式。它通过为每个明文块生成一个独特的、与位置相关的“偏移量”Offset然后使用分组密码加密“明文块异或偏移量”来产生密文块。认证标签则是所有明文块或密文块的某种校验和再经过加密的结果。偏移量生成使用一个“L值”由密钥加密0得到通过格雷码Gray Code或倍乘Doubling在有限域GF(2^128)上生成一系列与位置相关的偏移量$Δ_i$。这个生成过程非常高效。并行加密对于每个明文块$P_i$计算 $C_i E_K(P_i \oplus Δ_i) \oplus Δ_i$。注意每个$C_i$的计算完全独立可以并行进行。认证计算所有明文块的“校验和” $\Sigma P_1 \oplus P_2 \oplus ... \oplus P_m$然后标签 $T E_K(\Sigma \oplus Δ_m)$ 的截断。3.3.2 实操要点与避坑指南近乎极限的效率OCB是“单次通过”的即只需对数据扫描一遍即可同时成加密和认证。其加密部分的速度理论上可以接近纯加密模式CTR即分组密码的极限速度。在实际测试中OCB3的性能通常优于GCM。专利问题的历史遗留OCB模式历史上存在专利限制这严重阻碍了其广泛应用。虽然专利已过期但许多协议和库因历史惯性仍首选GCM。在商业产品中使用前务必确认专利状态目前OCB3已免费。Nonce的严格要求OCB是典型的Nonce-based方案绝对不能重复使用Nonce。否则会严重破坏安全性。必须确保每个Key, Nonce对只使用一次。偏移量生成的正确性至关重要偏移量$Δ_i$的生成算法如倍乘必须严格按照标准实现。一个微小的错误比如在有限域乘法上出错会导致整个加密失效。建议直接使用经过验证的密码库如Libsodium的crypto_aead_aes256ocb_tiny实现。缺少Nonce误用抵抗这是OCB相对于COLM或Deoxys-II的一个理论劣势。如果应用场景无法绝对保证Nonce的唯一性则需要选择其他方案。4. 性能横评与安全攻击实例深度解读了解了原理我们还需要从数据和实战角度看看这些算法究竟表现如何以及它们经历过怎样的攻击考验。4.1 综合性能对比分析下表整理了主要决赛算法在典型平台上的性能特征和关键指标这是工程选型时最直接的参考。算法设计结构核心操作软件性能 (长消息)硬件友好性并行性Nonce误用抵抗典型应用场景AEGIS-128L专用结构AES轮函数~0.48 cpb (Haswell)高 (需AES-NI)极高无高性能服务器、数据中心MORUS-1280专用结构比特运算~0.69 cpb (Haswell)中高极高无通用高性能计算OCB3BC-AE (AES)AES加密~0.7-1.0 cpb (AES-NI)高 (需AES-NI)高无通用协议追求效率Deoxys-IIBC-AE (AES)AES加密 (带Tweak)接近OCB中高高有需要抗Nonce误用的场景Ascon-128海绵结构比特/字置换~10-20 cpb (软件)极高(面积小)无无物联网、智能卡、轻量级硬件ACORN流密码结构比特运算/反馈中等 (串行)极高(面积极小)无无超低功耗RFID、传感器COLMBC-AE (AES)AES加密混合接近AES-GCM中中高有平衡安全与鲁棒性的应用性能数据解读与实测心得**cpbcycles per byte**是衡量软件性能的关键指标数值越低越好。AEGIS和MORUS的亚1 cpb表现堪称顶级。但需注意这个性能是在现代x86 CPU上、处理长消息如4KB时测得的。对于短消息如网络数据包初始化开销占比大性能排名可能会有变化。硬件友好性不仅指速度更指面积Area和功耗Power。Ascon和ACORN在这方面优势明显其简单的比特操作逻辑门数少非常适合集成到芯片中。并行性直接影响多核CPU或硬件流水线上的吞吐率。AEGIS、MORUS、OCB的并行能力极强。而海绵结构和流密码结构本质串行是其性能瓶颈。4.2 经典安全攻击案例与启示没有经过攻击考验的算法不是好算法。CAESAR竞赛的过程也是全球密码分析师对候选算法进行“围攻”的过程。一些有代表性的攻击揭示了算法设计和实现中需要警惕的陷阱。4.2.1 对AES-COPA/ELmD的通用伪造攻击AES-COPA和ELmD是COLM的前身它们设计目标是提供Nonce误用抵抗。然而在2015年密码学家Jian Guo等人提出了一种通用伪造攻击。该攻击的核心在于当攻击者能够查询大量约$2^{n/2}$对于128位分组即$2^{64}$消息后可以以不可忽略的概率伪造出一个有效的密文标签对。攻击原理简化这类基于PMAC结构的算法其认证标签的生成最终依赖于一个“校验和”的加密。攻击者通过收集大量查询利用生日悖论寻找校验和的碰撞。一旦找到两个不同消息对应相同的中间校验和就可以构造伪造。对我们的启示这并非算法被完全破解而是证明了其安全性边界在生日攻击复杂度内$2^{64}$次查询。对于需要$2^{128}$安全级别的应用这是一个安全限度的削弱。它提醒我们安全声明需要仔细审视其具体边界。COLM在后继设计中对此进行了改进。4.2.2 对ACORN的故障攻击ACORN作为流密码其安全性高度依赖于内部状态的保密性。2017年有研究团队成功对ACORN实施了差分故障攻击。攻击场景假设攻击者能在设备运行ACORN时例如在智能卡中通过激光或电压毛刺等手段在特定时刻翻转内部状态中的少数几个比特注入故障。攻击过程通过分析正确密文和故障密文之间的差异结合ACORN的状态更新方程攻击者可以逐步推导出内部状态最终恢复出密钥。该研究显示在某些假设下注入数百个单比特故障即可恢复密钥。对我们的启示轻量级算法对物理攻击可能更脆弱。ACORN的简单线性结构在方便实现的同时也可能使故障传播模式更易于分析。对于部署在可能遭受物理攻击环境中的设备必须考虑加入故障检测机制如冗余计算、传感器或使用具有内在故障攻击抵抗设计的算法。4.2.3 对JAMBU的Nonce误用安全声明破解JAMBU声称在Nonce部分重复使用时仍能保持一定安全性。然而Peyrin等人在2015年发表的工作驳斥了这一过于乐观的声明。攻击方法他们展示了一种攻击在Nonce重复使用的情况下仅需约$2^{32}$次加密查询就能成功伪造消息。这远低于设计者声称的安全强度。对我们的启示对算法的安全声明要保持审慎尤其是那些声称在“非理想条件”如Nonce误用下仍安全的算法。这些声明的成立往往依赖于非常严格且不直观的条件。在工程实践中最安全的做法永远是严格保证Nonce的唯一性而不是依赖算法的“误用抵抗”特性。5. 工程实践选型、实现与常见问题排查理论再美终需落地。最后这部分我们聚焦于如何将这些算法应用到实际系统中。5.1 算法选型决策矩阵面对这么多选择你可以通过回答下面几个关键问题来缩小范围你的平台是什么x86/ARM服务器有AES-NI优先AEGIS、MORUS、OCB、Deoxys。性能是首要考虑。资源受限的MCU/FPGA优先Ascon、ACORN。关注代码大小、内存占用和功耗。需要硬件加速IP核Ascon和ACORN有大量经过验证的硬件实现方案。你的数据特性是什么大量长数据流如视频传输需要高吞吐和并行选AEGIS、MORUS。短数据包如IoT传感数据初始化开销占比大。Ascon、ACORN的轻量级初始化有优势。也可以考虑专门为短消息优化的模式。是否需要处理关联数据AD所有CAESAR候选都支持但API调用方式需确认。你的安全威胁模型是什么能否绝对保证Nonce不重复如果能OCB、AEGIS是优秀选择。如果不能考虑Deoxys-II或COLM。是否面临侧信道或故障注入风险优先选择结构简单、易于防护的Ascon并确保实现加入了掩码或冗余校验。是否需要后量子安全传统AE算法不直接提供量子安全。如需应关注基于格、哈希等后量子密码学的AE方案这超出了CAESAR范围。你的生态和合规要求是什么是否需符合特定国家标准如中国商密CAESAR算法目前并非国际或中国标准。在国内商用领域需优先考虑SM4/GCM等国密算法。团队是否有相关算法的实现和审计经验选择有成熟、广泛审计的开源实现如Libsodium, monocypher的算法如Ascon、AEGIS可以降低风险。5.2 实现中的“坑”与最佳实践即使选对了算法错误的实现也会让安全归零。以下是一些血泪教训Nonce管理的陷阱绝对不要使用计数器作为Nonce而不加密钥派生。如果密钥固定简单的计数器Nonce在设备重启后可能重复。应采用“密钥计数器”派生出一个唯一的Nonce或者使用高质量的随机数。Nonce长度必须符合算法要求。例如Ascon-128要求128位Nonce。用96位Nonce后面补零和用128位随机Nonce在安全性上是等价的吗不一定具体要看算法规范。务必遵循标准。关联数据AD的误解AD是不加密但受认证的数据。常见的错误是忘记包含重要的协议元数据如数据包头部、协议版本号到AD中。攻击者可以篡改这些数据而不会被发现。AD的处理顺序必须正确。通常是先处理完所有AD再进行加密/解密。顺序错乱会导致验证失败。密钥生命周期管理AE算法解决了数据安全但没解决密钥管理。长期使用同一个密钥加密海量数据是危险的。即使算法本身安全密钥也可能因侧信道泄露。应建立密钥轮换机制。许多AE算法如Ascon的密钥加载Key Setup阶段是计算密集型的。对于短消息频繁加密的场景如TLS记录应考虑会话密钥派生用一个主密钥派生出的临时密钥来加密实际数据避免反复进行完整的初始化。时间侧信道在验证标签时必须使用常数时间比较如crypto_verify_16。逐字节比较并在发现第一个不匹配时就返回会泄露标签差异的位置信息可能被利用进行伪造攻击。即使算法本身是常数时间的实现也必须是。避免在关键操作中使用分支或基于秘密数据的数组索引。5.3 常见问题排查速查表问题现象可能原因排查步骤认证失败解密返回错误1. 密钥不匹配2. Nonce不匹配3. 关联数据AD不匹配4. 密文或标签在传输中被篡改5. 实现Bug如字节序问题1. 确认加解密双方使用相同的密钥。2. 确认Nonce唯一且正确传输/存储。3. 确认AD内容、长度和顺序完全一致。4. 检查通信通道完整性。5. 使用标准测试向量验证自身实现。加解密结果与参考实现不同1. 数据编码Hex, Base64错误2. 字节序Endianness问题3. 填充Padding处理错误CAESAR算法通常无需填充4. API调用参数顺序错误1. 确保编解码在算法调用之外进行。2. 确认所有输入Key, Nonce, AD, Plaintext是否为算法预期的字节数组。3. 确认是否错误地添加了PKCS#7等填充。4. 仔细对照算法规范的API定义。性能远低于预期1. 未启用硬件加速如AES-NI2. 处理消息过短初始化开销占比大3. 内存拷贝过多4. 上下文切换频繁如每次加密都重新初始化1. 检查CPU标志和编译选项。2. 对于短消息考虑使用“会话”模式复用部分初始化状态。3. 使用原地操作in-place减少拷贝。4. 对于频繁操作保持算法上下文而不是每次都创建新的。在嵌入式设备上内存溢出1. 算法状态上下文过大2. 实现中使用了动态内存分配或大缓冲区1. 选择状态小的算法如Ascon-128状态320位即40字节。2. 使用静态缓冲区并在编译时确定最大内存使用量。CAESAR竞赛虽然已经落幕但它所推动的认证加密技术革新正在持续发酵。决赛算法如Ascon、AEGIS等已经在TLS 1.3的候选套件、物联网安全协议、内存加密等领域开始探索应用。这场竞赛留给我们的不仅是几个优秀的算法更是一套如何系统化地设计、评估和选择密码原语的方法论。在具体项目中我个人的体会是永远不要盲目追求“性能第一”或“最新潮”而应回到你的具体威胁模型、资源约束和运维能力上来做权衡。很多时候一个经过充分实践检验、有高质量开源实现、并且团队能真正理解的“老”算法远比一个看似完美但充满未知风险的“新”算法来得可靠。密码学是安全的基石而审慎是构建这块基石的第一原则。