haraichi · 高并发授权验证基础设施

累计验证请求

—次

trending_up日环比 +3.2%

在线应用

—个

trending_up本周新增 12

平均响应延迟

—毫秒

trending_down较上周 -6 毫秒

服务可用性

—%

check_circle近 90 天无故障

系统能力

从加密链路到运营数据，从代码注入到资源保护，四个方向组成完整的授权验证闭环。

enhanced_encryption

双向加密链路

请求加密、响应加密、签名验签、时间戳与随机数防重放，四层防护叠加。抓包拿到的始终是密文，改包无法通过签名校验。

请求加密响应加密一次性令牌

analytics

运营数据看板

激活量、订单量、道具消耗、消费排行，多维度数据实时聚合。图表滚动更新，指标波动可见，异常发现从小时级压缩到分钟级。

用户统计数据排行趋势曲线

tune

策略化管理后台

用户、应用、密钥、算法、风控阈值在同一个后台集中配置。策略变更实时推送，无需重启服务，无需发版。

用户管理全局配置即时生效

shield

源码与资源保护

云端一键注入加密代码，重复注入块自动清理，安装包加固与反编译分析配套使用，形成从源码到产物的完整保护链。

一键注入自动去重加固

加密链路

请求与响应各走一遍加解密，客户端与服务端各自持有部分密钥，中间人无法还原明文、无法伪造响应。

upload

请求加密客户端 → 服务端

check_circle
用 应用标识 + 应用密钥 派生本次会话密钥
check_circle
请求体按所选算法（AES-256-GCM / SM4 / RC4 等）加密
check_circle
附加 时间戳 + 随机数 + 签名，抵御重放与篡改
check_circle
服务端解密后用同一密钥校验签名

download

响应加密服务端 → 客户端

check_circle
服务端使用 本次动态密钥 加密响应数据
check_circle
附带一次性令牌，绑定本次请求，过期即作废
check_circle
响应内含 HMAC / RSA / ECDSA 签名 供客户端校验
check_circle
客户端本地解密并验签，签名不通过视为无效响应

加密算法库

每一族的来历、每一支算法的诞生年份、设计者、原理与适用场景列在下方，点击展开查看细节。

lock

高级加密标准（AES）

Rijndael · 1997—2001

1997 年 1 月，美国国家标准与技术研究院发起公开征集，目标是寻找一种能承受未来数十年算力增长的分组密码。同年 9 月，15 个候选算法入围；1999 年 8 月筛至 5 个：MARS、RC6、Rijndael、Serpent、Twofish。2000 年 10 月 2 日，比利时密码学家 Joan Daemen 与 Vincent Rijmen 设计的 Rijndael 被正式选中。2001 年 11 月 26 日发布 FIPS PUB 197，2002 年 5 月 26 日正式生效，AES 从此成为全球通用的对称加密标准。Rijndael 本体支持 128 / 192 / 256 位分组，AES 标准只固定使用 128 位分组，密钥长度则支持 128 / 192 / 256 三种。

AES-128-ECB1970s 概念 / 2001 落地chevron_right

全称: 高级加密标准 128 位密钥 · 电子密码本模式
设计者: Joan Daemen、Vincent Rijmen（算法本体），模式源自 1970 年代 IBM 的分组密码实践
原理: 将明文按 16 字节切块，每块独立加密，相同明文块产生相同密文块。
起源: ECB 是最早的分组密码工作模式，概念可追溯到 1960—1970 年代早期。当时分组密码刚起步，初始化向量概念尚未成形。它简单、可并行、易实现，早期加密库第一版几乎全部支持。

注意：ECB 因相同明文产生相同密文，被称作"电子密码本"，图像加密后可直接看出轮廓。仅适用于明文完全随机、不可能重复的场景，例如加密已加盐的会话密钥。

AES-128-CBC1976 · IBMchevron_right

全称: 高级加密标准 128 位密钥 · 密码分组链接模式
设计者: IBM 密码研究组（1976 年首次提出，用于 System/370 系列）
原理: 每块明文先与上一块的密文异或，再送入 AES 加密。首块需要一个 16 字节初始化向量作为"上一块密文"。相同明文在 IV 不同时密文完全不同。
起源: 1976 年 IBM 在为美国国家标准局实现 DES 时提出 CBC。他们发现 ECB 在真实业务中缺陷明显——重复数据全部暴露。CBC 用"上块密文参与下块加密"的办法让相同内容在不同位置产生不同密文，此思路被写入后续所有分组密码标准。

要点：初始化向量必须随机且不可预测，否则攻击者可构造相同 IV 复现密文。IV 本身无需保密，可随密文一同发送。

AES-128-CTR1979 · Diffie & Hellmanchevron_right

全称: 高级加密标准 128 位密钥 · 计数器模式
设计者: Whitfield Diffie 与 Martin Hellman（1979 年提出计数器思想）
原理: 维护一个计数器，每次加密计数器值得到密钥流，再与明文异或。加密与解密是同一操作。
起源: 1979 年 Diffie 与 Hellman 在密码模式论文中提出：既然分组密码可加密任意 16 字节，那么把计数器当作明文加密、用产出异或真实数据，分组密码即可当流密码使用。此思路后来成为高性能场景的首选模式。

要点：计数器绝不能重用——同一密钥加密同一计数器两次，密钥流重复，明文直接泄露。CTR 必须配合严格的计数器管理。

AES-128-CFB1970s 末chevron_right

全称: 高级加密标准 128 位密钥 · 密码反馈模式
设计者: 1970 年代分组密码研究集体产物，与 OFB 同期
原理: 将上次密文反馈进 AES 加密，输出与下一段明文异或。分组密码当作流密码使用，但反馈的是密文而非计数器。
起源: 在 CTR 普及前，CFB 与 OFB 是仅有的两种把分组密码"流化"的方法。CFB 适合不能等待整块数据的场景，例如实时通讯、串口传输。它自带一定错误扩散：密文丢一字节只影响一个块，后续可自恢复。

要点：CFB 分 CFB-8、CFB-64、CFB-128 等变体，数字表示每次反馈位数。常规场景用 CFB-128。

AES-128-OFB1970s 末chevron_right

全称: 高级加密标准 128 位密钥 · 输出反馈模式
设计者: 1970 年代分组密码研究集体产物
原理: 与 CFB 类似，但反馈的是 AES 输出而非密文。密钥流提前生成，与明文无关。
起源: OFB 是为解决 CFB 错误扩散问题而设计：让密钥流独立于密文，单个位翻转只影响对应那一位。早期用于卫星通讯等易出错环境。缺点在于必须严格按序消费密钥流，不能跳跃访问。

要点：OFB 的 IV 不能在同一密钥下重复使用，否则两次加密得到相同密钥流，明文异或即可还原。

AES-128-GCM2004 · McGrew & Viegachevron_right

全称: 高级加密标准 128 位密钥 · 伽罗瓦计数器模式
设计者: David McGrew 与 John Viega（2004 年提出，2007 年成为 NIST SP 800-38D 标准）
原理: CTR 模式做加密，再在伽罗瓦域上计算认证标签，一次完成保密与防篡改。解密时标签不匹配直接拒绝。
起源: 2000 年代初，传统"先加密再 HMAC"的做法需要两把密钥、两遍计算。McGrew 与 Viega 将 CTR 与 Carter-Wegman 认证结合，2004 年提出 GCM。2013 年 Google 在 Chrome 中将 GCM 设为默认，TLS 1.3 将 AEAD 强制为唯一允许模式，GCM 成为默认选择。

要点：GCM 的 IV 不能在同一密钥下重复——重复一次，密钥流泄露，认证密钥也可能被反推。TLS、IPsec、802.11 均使用 GCM。

AES-192 / 256 系列同上chevron_right

说明: 密钥长度改为 192 或 256 位，其余与 128 位版本一致。轮数随密钥增长：128 位 10 轮，192 位 12 轮，256 位 14 轮。
为什么有 256: NIST 当初要求 AES 至少能承受未来数十年的算力增长，192 与 256 位是为高安全场景预留。当前普遍观点是 AES-128 已足够，AES-256 性能稍慢但安全裕度更大，政府、金融及合规场景常强制要求 256。
模式: ECB、CBC、CTR、CFB、OFB、GCM 全部支持，与 128 位一一对应。

要点：256 位密钥下 AES 密钥扩展多两轮，理论上面对相关密钥攻击存在隐患（Biryukov 与 Khovratovich 2009 年提出），实际攻击复杂度仍为天文数字，正常使用无碍。

shield

商用密码（SM 系列）

中国国家密码管理局 · 2006—2016

2006 年 1 月，中国国家密码管理局发布 SM4（原名 SMS4），最初为 WAPI 无线局域网标准配套。2012 年 3 月成为密码行业标准 GM/T 0002-2012，2016 年 8 月成为国家标准 GB/T 32907-2016。SM 系列为一整族：SM1 是硬件实现的对称算法，接口开放但内部不公开，需专用芯片；SM2 是非对称算法（椭圆曲线）；SM3 是哈希算法；SM4 是对称分组密码。国密主要用于国内合规场景，在等级保护测评与商用密码应用安全性评估中经常出现。

SM4-ECB / CBC / CTR / OFB / CFB / GCM2006 发布 / 2016 国标chevron_right

全称: 商用密码 4 号算法 · 工作模式家族
设计者: 中国国家密码管理局组织设计，设计细节未公开
结构: 128 位分组、128 位密钥、32 轮非线性迭代。轮函数 F 使用 S 盒与循环移位，结构与 AES 不同，但安全目标相近。
模式起源: SM4 原只定义 ECB 基础用法，2016 年国标补充 CBC 模式（GM/T 0064-2018 等标准陆续跟进），国际通用 CTR、OFB、CFB、GCM 后均被接纳为 SM4 工作模式。SM4-GCM 是国内 TLS 国密套件最常见的组合。

要点：与 AES 一样，ECB 仅适用于特殊场合，常规场景优先选用 CBC 或 GCM。SM4 软件实现较 AES 慢，但有专门的国密硬件加速指令集。

SM12006 年前后chevron_right

全称: 商用密码 1 号算法
类型: 对称分组密码，硬件实现
特点: SM1 算法本身不向社会公开，只能通过国家密码管理局批准的专用加密芯片调用。芯片通过标准接口接收指令并返回结果，开发者仅见接口，不见内部。
起源: SM1 是中国最早进入商用密码体系的算法之一，早于 SM4。主要用于金融 IC 卡、政务系统、身份认证等高安全场景，因算法不公开，攻击者无从分析。缺点在于必须依赖硬件，跨平台部署不便。

cyclone

里维斯特密码系列（RC 家族）

Ron Rivest · 1987—1998

RC 是 Ron Rivest（RSA 中的 R）设计的算法系列，"RC"通常理解为 "Rivest Cipher" 或 "Ron's Code"。该系列横跨十余年，从 1987 年 RC2 到 1998 年 RC6。RC4 最具传奇色彩：它原为 RSA 公司商业机密，1994 年 9 月有人在 Cypherpunks 邮件列表匿名贴出完整代码，从此全世界都可使用，RSA 公司再未收回。RC4 此后用于 WEP、WPA、SSL 3.0、TLS 1.0—1.2，直到 2015 年 RFC 7465 明确禁止在 TLS 中使用。

RC41987 · 1994 公开chevron_right

全称: Rivest Cipher 4 · 流密码
设计者: Ron Rivest，1987 年设计，RSA 数据安全公司内部使用
原理: 维护一个 256 字节的 S 盒，用密钥对其做密钥调度算法洗牌，再用伪随机生成算法每次输出 1 字节密钥流，与明文异或。
起源: 1994 年 9 月 9 日，有人在 Cypherpunks 邮件列表贴出 RC4 完整源码。RSA 公司尝试维权未果，从此 RC4 成为公开算法。1990 年代末至 2000 年代初，它是 SSL/TLS 最常用的算法之一，因为速度极快，软件实现仅需几十行代码。2013 年斯诺登事件后，人们发现 RC4 的统计偏差被情报机构利用，2015 年 RFC 7465 正式将其从 TLS 移除。

要点：RC4 存在已知偏差（密钥流前几字节非完全随机、相关密钥攻击等），新项目不建议使用。在早期游戏、老软件、短连接协议中仍有存在，haraichi 支持它是为兼容历史系统。

RC4-drop2001 前后chevron_right

全称: 丢弃前 N 字节的 RC4
原理: RC4 密钥流前 256 或 768 字节统计偏差最严重，直接丢弃前 N 字节再使用，N 通常取 256 或 768。
起源: 2001 年 Fluhrer、Mantin、Shamir 三人发布对 WEP 的攻击，指出 RC4 前几字节存在严重偏差。随后各种 "drop N" 变体被提出，作为老系统的临时加固方案。现代新系统已不再使用，直接换 AES-GCM 或 ChaCha20 更省事。

RC2 / RC5 / RC61987 / 1994 / 1998chevron_right

RC2: 1987 年设计，分组密码，64 位分组、可变密钥长度。最初替代 DES 用于出口至美国的软件（DES 出口受限）。后在某些密钥长度下被判定强度不足。
RC5: 1994 年设计，首个使用数据相关循环移位的密码。分组、密钥、轮数全部可变，曾用于 RSA 公司 BSAFE 库。特点是参数化——可根据场景调整分组大小与轮数。
RC6: 1997 年由 Rivest、Sidney、Yin 合作设计，是 RC5 的加强版，加入乘法运算增强扩散。RC6 参加 NIST 的 AES 竞赛并进入 5 强，最终负于 Rijndael。竞赛后 RC6 未再获大规模商用，主要作为学术算法存在。

key

数据加密标准（DES 家族）

IBM · 1972—1977

1972 年，美国国家标准局（NBS，NIST 前身）公开征集标准加密算法，用于保护政府非机密数据。1973 年第一次征集无果，同年 8 月第二次征集，IBM 提交了由 Horst Feistel 主导、Don Coppersmith 等人参与的 Lucifer 算法。NBS 与 NSA 介入修改后，1976 年 11 月正式采纳，1977 年 1 月 15 日发布 FIPS PUB 46，DES 成为美国联邦标准。DES 密钥 56 位（加 8 位校验共 64 位），1998 年电子前哨基金会用一台 25 万美元的机器，56 小时即暴力破解。2002 年 AES 正式取代它。

DES-ECB / CBC / CFB / OFB / CTR1977 · FIPS 46chevron_right

全称: 数据加密标准 · 各工作模式
结构: 64 位分组、56 位有效密钥、16 轮 Feistel 结构，每轮用 S 盒与 P 盒做非线性变换。
模式起源: ECB 是原始 DES 用法。CBC、CFB、OFB 在 1970 年代后期陆续标准化，1981 年 NBS 发布 FIPS 81 确立四种模式。CTR 直到 2001 年才由 NIST SP 800-38A 补充。DES 因密钥过短（56 位）已不安全，但其模式设计影响了后续数十年的所有分组密码。

要点：DES 不能用于保护真实数据，56 位密钥暴力破解成本已很低。在智能卡、老 POS 机、部分工业协议中仍有使用，haraichi 支持它主要为对接历史系统。

3DES（DES-EDE3）1995 前后chevron_right

全称: 三重数据加密算法 · 加密-解密-加密
结构: 用 DES 对同一块数据加密三次：密钥 K1 加密、K2 解密、K3 加密。三把不同密钥时有效强度约 112 位；三把密钥全不同则约 168 位。
起源: 1990 年代中期，DES 已经撑不住，但全球仍有大量老系统与硬件在使用 DES。3DES 是当时的折中方案：不改硬件，多次调用 DES 即可提升强度。EDE3 设计兼容单 DES（三把密钥相同时退化为单次加密）。3DES 用到 2017 年，NIST 才正式宣布 2023 年后不再批准。银行、支付、EMV 卡中 3DES 使用极广。

要点：3DES 比 AES 慢数倍，但胜在兼容。使用两把密钥（K1=K3）还是三把密钥（K1≠K2≠K3）取决于具体实现，强度不同。

DESX1990 年前后chevron_right

全称: 扩展数据加密标准
结构: 在 DES 外层套两层白化：明文先与一个额外 64 位密钥异或，DES 处理后再与另一个 64 位密钥异或。
起源: 1990 年前后，RSA 公司的 Ron Rivest 提出用简单异或白化扩展 DES 有效密钥长度，成本几乎不增加。DESX 曾作为"轻量加固"用于短生命周期场景，后被证明对某些攻击仍不够强，已基本退出历史舞台。

waves

流密码

ChaCha 家族 · 2005—2020

流密码的核心思路是"生成一条随机密钥流，与明文逐字节异或"。它不需要填充，延迟低，适合移动端与实时通讯。Daniel J. Bernstein 于 2005 年设计 Salsa20，2008 年改进为 ChaCha20。Google 于 2013 年将 ChaCha20-Poly1305 引入 Android 与 Chrome，2018 年成为 RFC 8439。TLS 1.3 中 ChaCha20-Poly1305 与 AES-GCM 并列成为两种标准算法，前者在没有 AES 硬件加速的设备上性能更好。

ChaCha202008 · Bernsteinchevron_right

全称: ChaCha20 流密码
设计者: Daniel J. Bernstein（djb）
原理: 维护 512 位状态（4 个常量 + 8 个密钥字 + 计数器 + 随机数），每轮做 4 次四分之一轮操作，共 20 轮（10 次双轮），输出密钥流。
起源: djb 于 2005 年设计 Salsa20，参加欧盟 eSTREAM 竞赛并胜出。2008 年改进 Salsa20，加快扩散，命名为 ChaCha。"ChaCha" 来自这种三拍子舞蹈，算法以四分之一轮的节奏推进。移动端应用广泛，因为没有 AES 硬件加速的设备上，它的性能优于 AES。

ChaCha20-Poly13052013 实用化 / 2018 标准chevron_right

全称: ChaCha20 加密 + Poly1305 认证的组合
原理: ChaCha20 做加密，Poly1305 用一次性密钥做认证，两把密钥由同一主密钥派生。解密时认证失败直接拒绝。
起源: 2013 年 Google 的 Adam Langley 团队开始在 Chrome 与 Android 部署 ChaCha20-Poly1305，理由是大量安卓设备没有 AES 硬件加速。2015 年被 IETF 采纳为草案，2018 年成为 RFC 8439。TLS 1.3、WireGuard、SSH 均支持。与 AES-GCM 相比，ChaCha20 优势在软件实现快、抗侧信道；劣势是在有 AES-NI 的服务器上不及 AES。

Salsa20 / XSalsa20 / XChaCha202005 / 2008 / 2008chevron_right

说明: Salsa20 是 ChaCha20 的前身，结构与 ChaCha 相似但扩散稍慢。X 系列（XSalsa20、XChaCha20）将随机数从 8 字节扩展到 24 字节，降低随机数重用风险。
起源: Salsa20 在 eSTREAM 竞赛胜出后，djb 发现 8 字节 nonce 在大规模随机化场景下不足，扩展出 24 字节的 X 系列。XChaCha20 目前在 libsodium 中是默认的流密码推荐，主要用于加密文件、加密消息等非网络流场景。

vpn_key

RSA 算法

Rivest-Shamir-Adleman · 1977

1976 年，Whitfield Diffie 与 Martin Hellman 发表《密码学的新方向》，提出"公钥密码"概念——加密与解密可使用不同密钥。第二年，MIT 三位研究者 Ron Rivest、Adi Shamir、Leonard Adleman 找到第一个实用方案，基于大整数分解难题。1983 年 RSA 获美国专利 4,405,829，2000 年 9 月专利到期后彻底免费。

RSA-1024 / 2048 / 3072 / 40961977 至今chevron_right

全称: Rivest-Shamir-Adleman 非对称加密 / 签名
原理: 选两个大素数 p、q，算出 n=pq 与欧拉函数 φ(n)。取一个与 φ(n) 互素的 e 作为公钥指数，计算 d 使 ed≡1 mod φ(n)。加密 c=m^e mod n，解密 m=c^d mod n。
为何难破: 已知 n 求 p、q 即整数分解问题。当前人类能分解的最大 RSA 数为 829 位（RSA-250，2020 年 2 月），消耗数千核·年。RSA-2048 目前无法分解。
位数选择: 1024 位已不安全（NIST 2013 年起建议退役），2048 位为当前主流，3072 位以上用于长期密钥，4096 位更稳但生成与运算更慢。
填充: 原始 RSA 为"教科书 RSA"，不安全（确定性、可乘性）。实际使用必须配合 PKCS#1 v1.5 或 OAEP 填充。

要点：RSA 密钥长、运算慢，新项目基本只用它做签名或密钥交换，真正加密数据用 AES。量子计算机一旦实用，RSA 会被 Shor 算法直接攻破，目前已在向抗量子算法迁移。

timeline

椭圆曲线密码（ECC / ECDSA / EdDSA）

Koblitz & Miller · 1985

1985 年，华盛顿大学的 Neal Koblitz 与 IBM 的 Victor Miller 各自独立提出用椭圆曲线上的离散对数问题构建密码系统。优势直观：256 位 ECC 的安全强度相当于 3072 位 RSA，密钥短、速度快、存储省。1992 年 Scott Vanstone 提出 ECDSA，1998 年成为 ANSI X9.62 标准，2005 年进入 NIST 标准。2008 年中本聪在比特币中使用 secp256k1 曲线，让 ECC 进入大众视野。

ECDSA P-256 / P-3841992 提出 / 1998 标准chevron_right

全称: 椭圆曲线数字签名算法 · NIST 标准曲线
设计者: Scott Vanstone 提出，NIST 标准化
原理: 用椭圆曲线上的点乘运算代替 RSA 的模幂运算。私钥为一个 256 位整数，公钥为曲线上的一个点。签名为 (r, s) 对。
起源: P-256（即 secp256r1 或 prime256v1）是 NIST 1999 年推荐的标准曲线，P-384 是 2001 年补充的高安全版本。TLS 证书、JWT 签名、iOS 代码签名、Android 应用签名均使用它们。P-256 在 2015 年后成为 HTTPS 的默认曲线。

ECDSA secp256k12000 前后chevron_right

全称: Koblitz 曲线 secp256k1
特点: 曲线方程 y² = x³ + 7，结构较 P-256 更简单，参数更"可验证"（无来历不明的随机种子）。
起源: Certicom 公司 2000 年前后提出。起初关注度不高，直到 2008 年中本聪选用它作为比特币签名曲线，secp256k1 一夜爆红。区块链行业此后几乎都使用它，以太坊亦然。相比 P-256，secp256k1 的参数生成方式更透明，不易藏后门，这可能是中本聪选择它的原因之一。

Ed25519 / Ed4482011 / 2015chevron_right

全称: 基于扭曲爱德华兹曲线的数字签名
设计者: Daniel J. Bernstein、Niels Duif、Tanja Lange、Peter Schwabe、Bo-Yin Yang
原理: 用扭曲爱德华兹曲线配合 SHA-512 哈希，签名过程确定（不需要随机数）。签名 64 字节，公钥 32 字节，比 ECDSA 短。
起源: djb 团队 2011 年发布 Ed25519，最初为解决 ECDSA 的两个痛点：一是 ECDSA 每次签名需要高质量随机数，随机数一旦重用私钥立即泄露（索尼 PS3 由此被攻破）；二是 P 系列曲线参数来历有争议。Ed25519 用确定性签名彻底解决随机数问题，并提出可验证参数方案。2017 年成为 RFC 8032。SSH 从 7.0 开始支持，TLS 1.3 也支持。

SM22010 · 国密chevron_right

全称: 商用密码 2 号算法 · 椭圆曲线公钥密码
发布: 2010 年 12 月 17 日，国家密码管理局发布
原理: 基于 256 位椭圆曲线，曲线参数由国内自行选定。包含加密、签名、密钥交换三套算法，一个算法族解决所有非对称需求。
起源: 2000 年代末，中国开始建立自主商用密码体系。SM2 是中国第一个公开、完整、可自主实现的椭圆曲线密码标准。2012 年成为密码行业标准 GM/T 0003-2012，2016 年成为国标 GB/T 32918-2016。国内政务、金融、电子认证均使用 SM2 替代 RSA 与 ECDSA。

Diffie-Hellman / ECDH1976 / 1985chevron_right

全称: Diffie-Hellman 密钥交换 / 椭圆曲线版本
设计者: Whitfield Diffie、Martin Hellman（1976）；ECDH 由 1985 年 Koblitz 与 Miller 的椭圆曲线理论延伸而来
原理: 双方各自选一个私钥，用公开的生成元计算公钥发给对方，各自再与对方公钥结合得到相同共享密钥。窃听者只有两个公钥，无法算出共享密钥（离散对数难题）。
起源: 1976 年 Diffie 与 Hellman 发表《密码学的新方向》，这是现代公钥密码学的起点。此前加密与解密必须使用同一密钥，密钥分发本身即为难题。DH 让双方在不安全信道上也能协商出共享密钥。今天所有 HTTPS 握手第一步都是 DH 的变体（DHE 或 ECDHE）。

fingerprint

信息摘要算法（MD 家族）

Ron Rivest · 1989—1991

MD 系列是 Ron Rivest 针对"把任意长度数据压缩成固定长度指纹"这一问题的答案。1989 年 MD2（为 8 位机设计）、1990 年 MD4、1991 年 MD5。MD5 曾经是数字签名、文件校验、密码存储的通用方案，直到 2004 年山东大学王小云教授团队公布 MD5 碰撞攻击，2008 年又被用于伪造 CA 证书，MD5 从此在安全领域被淘汰。当前 MD5 仍存活的地方，基本只剩"校验文件是否损坏"这类非对抗场景。

MD51991 · Rivestchevron_right

全称: Message Digest Algorithm 5 · 信息摘要算法第 5 版
设计者: Ron Rivest
输出: 128 位（16 字节），通常写成 32 位十六进制。
原理: 输入按 512 位分组，每组经 4 轮、每轮 16 次非线性操作，维护 4 个 32 位状态变量，最后拼成 128 位输出。
起源: 1991 年 Rivest 用 MD5 取代 MD4，主要改进为增加安全裕度与抗分析性。MD5 在 1990 年代成为事实标准，几乎所有软件下载页都提供 MD5 校验值。2004 年王小云团队在 CRYPTO 会议宣布能快速找到 MD5 碰撞，此后各种伪造证书、伪造软件签名事件层出不穷。目前除校验文件完整性，MD5 不应再用于任何安全场景。

要点：MD5 已不安全。密码存储、数字签名、数据完整性校验一律换 SHA-256 或更好。

MD4 / MD21990 / 1989chevron_right

MD4: 1990 年设计，是 MD5 的前身，速度比 MD5 更快，1995 年被 Dobbertin 找到碰撞。现已完全淘汰。
MD2: 1989 年为 8 位机（如早期 PC）设计，使用 S 盒做 18 轮迭代，速度较慢但当时适用。1996 年被发现存在碰撞。现仅出现在极老的协议与实现中。

functions

安全散列算法（SHA 家族）

NSA / NIST · 1993—2015

SHA 系列由美国国家安全局（NSA）设计、NIST 发布。1993 年发布 SHA-0（很快被撤），1995 年发布 SHA-1，2001 年发布 SHA-2 系列（SHA-224、SHA-256、SHA-384、SHA-512），2015 年发布 SHA-3。SHA-1 在 2017 年被 Google 与 CWI 联合公布的 "SHAttered" 攻击证实可产生碰撞，全球所有浏览器与 CA 从那时起陆续淘汰 SHA-1。SHA-2 目前仍是绝对主力，SHA-3 作为补充，使用与 SHA-2 完全不同的 Keccak 海绵结构。

SHA-11993 / 1995chevron_right

全称: Secure Hash Algorithm 1 · 安全散列算法第 1 版
设计者: NSA 设计，NIST 发布 FIPS 180-1
输出: 160 位（20 字节），通常写成 40 位十六进制。
起源: 1993 年发布 SHA-0，很快被发现设计缺陷并撤回。1995 年发布修订版 SHA-1。此后二十年，SHA-1 是 Git 提交哈希、TLS 证书、代码签名的默认选择。2017 年 2 月 23 日，Google 与荷兰 CWI 研究所联合发布第一例 SHA-1 碰撞，两段不同 PDF 产生相同 SHA-1。目前 SHA-1 在安全场景彻底退役，Git 也迁移到 SHA-256。

SHA-256 / 224 / 384 / 5122001 · FIPS 180-2chevron_right

全称: SHA-2 家族
设计者: NSA 设计，NIST 标准化
结构: SHA-224/256 用 32 位字，64 轮迭代；SHA-384/512 用 64 位字，80 轮迭代。基于 Merkle-Damgård 结构。
起源: 2001 年 NIST 发布 FIPS 180-2，引入 SHA-2 家族。当时 SHA-1 仍可用，SHA-2 关注度不高。2005 年王小云团队对 SHA-1 的攻击成果公布后，SHA-2 迅速成为默认选择。今天比特币、TLS 证书、JWT、Git 的 SHA-256 对象均使用它。SHA-256 已成为"默认哈希算法"的代名词。

SHA-3（Keccak）2012 竞赛 / 2015 标准chevron_right

全称: SHA-3 · 基于 Keccak 海绵结构
设计者: Guido Bertoni、Joan Daemen、Michael Peeters、Gilles Van Assche
结构: 与 SHA-2 完全不同。使用海绵结构：先把数据吸进一个 1600 位状态，再挤出哈希值。内部置换函数 keccak-f 用 5×5 的 64 位字阵列做 24 轮操作。
起源: 2007 年 NIST 发起 SHA-3 竞赛，意在寻找与 SHA-2 结构完全不同的备选方案。2012 年 10 月 Keccak 胜出，2015 年 8 月成为 FIPS 202 标准。SHA-3 在结构上与 SHA-2 完全无关，这是它最大的价值：若 SHA-2 未来被发现致命缺陷，SHA-3 可作为替代。

BLAKE2 / BLAKE32012 / 2020chevron_right

BLAKE2: 2012 年由 Jean-Philippe Aumasson 与 Samuel Neves 设计。BLAKE 曾在 SHA-3 竞赛进入决赛但未获胜，作者将其简化优化后发布为 BLAKE2。比 MD5 快、比 SHA-3 快，密码学界评价很高。BLAKE2b 用于 64 位平台，BLAKE2s 用于 8—32 位平台。
BLAKE3: 2020 年发布，由 Jack O'Connor 主导，以 BLAKE2s 为基础，加入 Merkle 树结构支持并行计算。比 BLAKE2 更快，还支持任意长度的可扩展输出。许多新项目把它作为 SHA-256 的替代。

RIPEMD-1601992 / 1996chevron_right

全称: RACE Integrity Primitives Evaluation Message Digest · 160 位版本
设计者: Hans Dobbertin、Antoon Bosselaers、Bart Preneel（1996 年）
起源: 1992 年欧洲 RIPE 项目发布初版 RIPEMD，因设计缺陷很快被淘汰。1996 年三位密码学家改进后发布 RIPEMD-160。在比特币中用途特殊：比特币地址生成需先 SHA-256 再 RIPEMD-160，因 RIPEMD-160 输出更短，可让地址更紧凑。

SM32010 · 国密chevron_right

全称: 商用密码 3 号算法 · 密码杂凑算法
发布: 2010 年 12 月 17 日，国家密码管理局发布
输出: 256 位
起源: 2010 年配合 SM2 一起发布，2016 年成为国标 GB/T 32905-2016。结构借鉴 SHA-256 的思路（Merkle-Damgård + 压缩函数），但消息扩展与压缩函数不同，安全性目标相近。国密 TLS、电子签章、区块链国密版本均使用 SM3。

Whirlpool2000 · Barreto & Rijmenchevron_right

全称: Whirlpool 哈希函数
设计者: Paulo Barreto 与 Vincent Rijmen（Rijmen 也是 AES 的设计者之一）
输出: 512 位
起源: 2000 年设计，2003 年被 ISO 采纳为 ISO/IEC 10118-3 标准。结构基于 AES 的压缩函数（W 盒是 AES 的 S 盒扩展），是"用分组密码构造哈希"的经典例子。主要用在部分欧洲电子签名系统，普及度不高。

verified

消息认证码（MAC）

Bellare / Canetti / Krawczyk · 1996

哈希能保证"数据没被改"，但保证不了"是谁发的"——中间人把数据与哈希一起改掉，接收方无法发现。消息认证码（MAC）即为解决此问题：用一把只有双方知道的密钥参与计算，攻击者不知道密钥就无法伪造。1996 年 2 月，Mihir Bellare、Ran Canetti、Hugo Krawczyk 三人发表 HMAC 论文，将"用哈希构造 MAC"标准化，1997 年成为 RFC 2104。今天 HMAC 是所有协议中最常见的完整性保护手段。

HMAC-SHA256 / HMAC-SHA1 / HMAC-MD51996 / 1997 标准chevron_right

全称: 基于哈希的消息认证码
设计者: Mihir Bellare、Ran Canetti、Hugo Krawczyk
原理: 把密钥与消息做两次哈希：H(K⊕opad || H(K⊕ipad || message))。两次哈希防止长度扩展攻击。内层哈希处理消息，外层哈希把密钥混入。
起源: 1996 年之前，人们用 H(K || message) 或 H(message || K) 做 MAC，均被证明有缺陷（长度扩展攻击）。Bellare 三人提出的 HMAC 结构被证明安全（在哈希函数是伪随机函数的假设下），1997 年成为 RFC 2104。今天 HMAC-SHA256 是 API 签名、JWT、支付回调校验的标配。

要点：HMAC 密钥长度不能短于哈希输出的一半，推荐与哈希输出等长。HMAC-MD5 仍在用，但新项目一律使用 HMAC-SHA256。

CMAC2005 · NIST SP 800-38Bchevron_right

全称: 基于密码的消息认证码（Cipher-based MAC）
原理: 用分组密码（如 AES）做 CBC 模式加密，取最后一块密文作为 MAC。因 CBC-MAC 对长度不安全的变体存在攻击，CMAC 加入子密钥区分处理最后一块。
起源: 2005 年 NIST 发布 SP 800-38B，将 CMAC 定为标准。它是对 1990 年代 CBC-MAC 各种漏洞的修正版，主要用于资源受限硬件（如智能卡）——那里不适合跑哈希算法，但已有 AES 硬件模块。

GMAC2004 · 基于 GCMchevron_right

全称: 伽罗瓦消息认证码
原理: GCM 模式中的认证部分独立出来，只做完整性校验，不加密数据。
起源: 2004 年随 GCM 一起提出。某些场景只需要防篡改不需要保密（例如公开日志的完整性签名），GMAC 正好适用。TLS 中偶尔用于会话票据的完整性。

Poly13052005 · Bernsteinchevron_right

全称: Poly1305 一次性消息认证码
设计者: Daniel J. Bernstein
原理: 用模 2¹³⁰−5 的多项式乘法，速度快，适合软件实现。每次加密使用不同密钥，一次用后即弃。
起源: 2005 年设计，与 ChaCha20 同一作者。Poly1305 的设计目标是在通用 CPU 上运行极快，同时保持数学上可证明的安全性。它几乎总是与 ChaCha20 一起出现（ChaCha20-Poly1305），TLS 1.3、WireGuard、SSH 的默认组合即为它。

code_blocks

编码与格式

不是加密 · 是换一种写法

编码不提供保密性，任何人都能解出来，它的作用是"把二进制数据变成可以放进文本协议里的字符串"。加密算法算出的密文是乱码字节，直接放进 HTTP 头、JSON、URL 会出问题，所以先编码再传输。常见编码有 Base64、十六进制、URL 编码，以及在此之上构建的 JWT、JWS、JWE 这类结构化格式。

Base64 / Base64URL1987 · RFC 989chevron_right

原理: 把 3 个字节（24 位）切成 4 个 6 位，每个 6 位映射到字符表（A—Z、a—z、0—9、+、/），不足 3 字节的部分用 = 补位。
起源: 1987 年首次在 RFC 989（隐私增强邮件标准）中定义，用于解决电子邮件只能传 7 位 ASCII 字符的问题——附件是二进制数据，直接塞进邮件会被破坏，Base64 把任意字节变成可打印字符。Base64URL 是 2003 年 RFC 3548 定义的变体，将 + 换成 -、/ 换成 _，去掉 =，因为 + 和 / 在 URL 中有特殊含义。

要点：Base64 会让数据变大 33%，且不提供任何保密性。看到"加密后的字符串"如果开头是 eyJ（对应 {"），基本是 Base64 编码的 JSON，不是真加密。

Hex（十六进制）计算机科学基础chevron_right

原理: 每 4 位二进制映射到 0—9、A—F 中的一个字符，1 个字节 = 2 个十六进制字符。
起源: 十六进制自早期计算机时代便有，因为字节是 8 位，正好可用两位十六进制表示，比十进制更直观。哈希值、密钥、密文常用十六进制展示，因为每个字节有确定字符对应，不会出现编码歧义。

要点：Hex 比 Base64 大 100%，但它无歧义、对大小写敏感，适合展示指纹、校验值这类"人眼比对"数据。

JWT / JWS / JWE2010—2015 · RFC 7515/7516/7519chevron_right

JWT: JSON Web Token，2015 年成为 RFC 7519。用 JSON 存储声明（谁、何时、能做什么），用 Base64URL 编码后拼接，再用 HMAC 或 RSA/ECDSA 签名。
JWS: JSON Web Signature，RFC 7515，只做签名不做加密。JWT 大多数时候即为 JWS 的实现。
JWE: JSON Web Encryption，RFC 7516，对 JWT 内容加密，外人看不到 payload。适合传输敏感声明。
起源: 2010 年前后，OAuth 2.0 的令牌需要一种"自包含、可校验、轻量"的格式。JWT 正好满足：服务端不用查库，验签即可知道令牌真伪。后来逐渐成为标准化格式，现代身份认证系统几乎都在使用。

hub

混合加密方案

对称 + 非对称 · 各司其职

单用对称加密存在密钥分发问题，单用非对称加密又太慢（RSA 加密 1KB 数据需数毫秒，AES 仅需数微秒）。现实中几乎所有协议都走混合路线：用非对称算法协商出临时对称密钥，再用该对称密钥加密业务数据。TLS、SSH、IPsec、Signal 协议全是这个套路。

AES + RSATLS 经典组合chevron_right

流程: 客户端生成一个随机对称密钥，用服务器公钥（RSA）加密后发送。服务器用私钥解密得到对称密钥。此后双方均用对称密钥加密数据。
起源: 这是 SSL 3.0 与 TLS 1.0—1.2 的主流做法，也称 RSA 密钥交换。1990 年代 Netscape 设计 SSL 时确定架构。缺点是缺少前向保密——服务器 RSA 私钥一旦泄露，此前录下的所有流量均可解密。TLS 1.3 已将其废弃，改用 ECDHE 做密钥交换。

AES + SM2 / SM4 + SM2国密 TLS 套件chevron_right

流程: SM2 做密钥交换与签名，SM4 做对称加密，SM3 做完整性校验。一套纯国密的完整方案。
起源: 国内政务、金融系统需要"全栈国产密码"，2010 年代逐步建立国密 TLS 标准。浏览器要支持国密 TLS 需要专门的双证书套件，目前主要通过奇安信、吉大正元等公司的方案落地。

ChaCha20 + ECDHTLS 1.3 / WireGuardchevron_right

流程: 用 X25519（一种特殊的 ECDH）协商共享密钥，再用 ChaCha20-Poly1305 加密数据。整套方案不依赖 AES 硬件，纯软件也很快。
起源: WireGuard VPN 默认方案，TLS 1.3 在没有 AES 硬件加速设备上的首选。完全基于 djb 家族算法（Curve25519 + ChaCha20 + Poly1305 + BLAKE2s），设计目标是"可证明安全 + 代码极简"。

自定义加盐 / 时间戳签名 / Nonce 防重放 / 一次性令牌通用加固手段chevron_right

自定义加盐: 加密前给明文混入一段随机字节（盐），让相同明文每次加密结果都不同。主要防止彩虹表攻击与重放攻击。
时间戳签名: 把当前时间戳一起参与签名，服务端只接受 5 分钟内的请求，超过时间窗口直接拒绝，防重放。
Nonce 防重放: 每次请求带一个只用一次的随机数，服务端记录已用过的 Nonce，重复出现直接拒绝。比时间戳更严格，但需要服务端存储。
一次性令牌: 每个请求配一个一次性令牌，响应必须带回同一令牌才算有效。haraichi 默认开启，防止请求被截获后挪作他用。

对接代码与云端注入

两种方式共用同一份配置。对接是把配置写进项目里，注入是由工具自动写入并附带加密逻辑。

integration_instructions对接代码

把下面三行加入项目配置文件，SDK 会自动从地址拉取并完成加密、签名、解密、验签四步流程。

haraichi.conf

# 对接配置 url=https://haraichi.top/haraichi.java haraichiid=填写唯一标识 key=填写唯一标识

info url 是 SDK 地址，haraichiid 与 key 在控制台创建应用后由系统生成，每个应用一套，不要外泄。

cloud_upload云端一键注入

不使用对接代码时，也可以在站内注入工具里选择自己的源码，由工具自动完成配置写入与加密代码生成。

注入配置

# 注入配置（与对接使用同一份） url=https://haraichi.top/haraichi.java haraichiid=填写唯一标识 key=填写唯一标识

info 工具会自动解析源码、写入上述配置、生成并注入加密与验签代码，若源码中已存在相同配置或重复代码块则自动清理。

功能一

多语言对接代码

二十多种语言的现成片段，加密、签名、解密、验签一次给全，复制改标识即可运行。

功能二

云端一键注入

上传源码，工具自动定位加密入口与网络请求点，写入配置并生成对应的加解密逻辑。

功能三

注入代码去重

同一源码多次注入会产生重复块，工具自动识别并清理，避免配置冲突与逻辑冗余。

功能四

安装包加固

对已打包的安装包加壳，隐藏关键逻辑与密钥访问路径，常规反编译工具无法直接读取。

功能五

逆向与反编译

先对已有安装包做反编译分析，定位风险点，再进行针对性加固，形成完整保护闭环。

功能六

处理报告

注入与加固完成后输出报告，列出注入位置、去重数量、加固状态，便于二次审查。

Java虚拟机

Kotlin安卓

Python3.x

Go1.18+

Node.js脚本

PHP7.4+

C#.NET

C / C++原生

RubyRails

Rustcargo

SwiftiOS

DartFlutter

Lua游戏

易语言中文

DelphiPascal

Objective-CmacOS

PerlCPAN

R统计

MATLAB科研

Shell命令行

注入流程演示

移动端注入工具的操作路径：选择源码、确认配置、等待处理、查看报告，四步走完。

9:41 signal_cellular_alt wifi battery_full

verified_user

haraichi 注入工具

选择源码
配置自动写入
加密与加固一并完成

开始

arrow_back 选择源码

folder_zip

我的应用源码.zip

2.3 兆 · 已就绪

check_box自动清理重复注入代码

check_box注入后执行安装包加固

一键注入

cloud_upload 正在处理

正在注入加密与校验代码...

解析源码结构

写入对接配置

清理 12 处重复注入

执行安装包加固...

check

处理完成

check_circle清理了 12 处重复注入

check_circle安装包已 加固完成

check_circle加密算法 AES-256-GCM

运行数据

实时聚合，1.5 秒刷新一次。请求趋势、延迟分布、算法占比可切换查看。

monitoring 数据看板

6

算法族

接入流程

注册、建应用、配策略、对接或注入，四步走完即可上线。

01

注册账号

邮箱注册验证，登录后系统会分配一个默认测试应用。

02

创建应用与密钥

新建应用，系统生成唯一应用标识与密钥，开发、测试、生产各一套。

03

配置加密策略

选算法、设密钥轮换周期、调风控阈值，改完立即生效。

04

对接或注入

把对接配置写进项目，或上传源码走一键注入，完成签名与校验调用即可上线。

开始使用 haraichi

开发测试阶段免费，生产环境按量计费，无最低消费。

login登录 person_add注册

官方群：546873073

haraichi高并发授权验证基础设施