密码学中两个核心概念信息摘要哈希函数和数字签名的基本原理与安全目标。信息摘要如 SHA-256、SM3是一种确定性单向函数输入任意长度数据输出固定长度如 SHA-256 输出 256 位SM3 输出 256 位的摘要值。其三大关键安全性质为单向性无法从摘要反推原始输入抗碰撞性极难找到两个不同输入产生相同摘要雪崩效应输入微小变化如1比特导致摘要显著变化约50%比特翻转。广泛用于文件完整性校验、密码存储加盐哈希、区块链默克尔树等场景。数字签名是基于公钥密码体制如 RSA、ECDSA、SM2构建的认证机制发送方先对消息计算摘要如用 SM3再用自身私钥加密该摘要生成签名接收方用发送方公钥解密签名得到摘要A同时对收到的消息独立计算摘要B比对 A ≡ B。若一致则可验证✅ 消息未被篡改完整性、✅ 签名者拥有对应私钥身份认证、✅ 签名不可抵赖不可否认性。二者常协同使用“先哈希再签名”既提升效率避免直接签名长消息又保障安全性利用哈希的抗碰撞性防止签名伪造。# 示例逻辑非实际实现仅示意流程messagebHello, World!digestsm3_hash(message)# 生成摘要signaturersa_sign(private_key,digest)# 私钥签名摘要verify_resultrsa_verify(public_key,digest,signature)# 公钥验签这是一个非常关键且常被误解的问题。数字签名本质上不是“对消息加密”而是对消息的摘要哈希值进行密码学变换如私钥签名运算。之所以必须“先哈希、再签名”而非直接对原始消息用私钥“加密”主要基于以下五大核心原因✅1. 效率与可行性性能约束公钥密码算法如 RSA、SM2、ECDSA计算开销大且有输入长度限制RSA 签名要求明文长度 ≤ 密钥长度 − 填充开销如 2048 位 RSA 最多处理约 256 字节而实际消息可能达 GB 级如软件安装包、视频文件。→ 直接签名不可行而哈希可将任意长消息压缩为固定短摘要如 32 字节签名运算瞬间完成。✅2. 安全性保障抗碰撞性绑定签名的安全性依赖于摘要的抗碰撞性若攻击者能构造m ≠ m但H(m) H(m)则其可用m的合法签名冒充m的签名。→ 使用强哈希如 SHA-256、SM3可将签名安全性归约为哈希函数的安全性且标准化哈希已通过长期密码分析验证。⚠️ 若跳过哈希直接设计“长消息签名方案”需重新证明其抗伪造性复杂度高、风险大。✅3. 标准化与确定性哈希是确定性、无密钥的公开函数确保发送方和接收方独立计算出完全相同的摘要前提消息一致避免因填充方式、编码差异等导致验签失败符合 PKCS#1 v2.2RSA-PSS、GB/T 32918.2SM2等标准强制要求。✅4. 支持“签名加密”混合流程如 sign-then-encrypt先哈希再签名使签名结果长度固定、可预测便于与后续加密如用对方公钥加密签名消息组合实现机密性认证一体化如 S/MIME、PGP。✅5. 消除语义攻击面如选择明文攻击直接对原始消息用私钥“加密”即 textbook RSA 签名存在严重漏洞若σ₁ m₁^d mod nσ₂ m₂^d mod n则σ₁·σ₂ ≡ (m₁·m₂)^d mod n攻击者可伪造新签名哈希填充如 PSS、SM2 的 Zₐ 消息拼接引入随机性与结构化处理彻底阻断此类代数攻击。 补充说明术语辨析❌ 错误说法“用私钥加密消息生成签名”✅ 正确理解“用私钥对消息摘要执行签名变换如 RSA 的模幂运算、SM2 的椭圆曲线签名运算”—— 这不是加密encryption而是数字签名生成signature generation目的不是保密而是认证与不可否认。# 对比示意伪代码# ❌ 危险且低效仅理论不推荐raw_sigpow(message_as_int,private_d,n)# message_as_int 可能超长或含非法值# ✅ 标准安全做法RFC 8017 / GM/T 0003.2digestsm3_hash(message)# 固定32字节padded_digestpss_encode(digest,salt)# 加盐填充sigrsa_sign_raw(private_key,padded_digest)# 对填充后摘要签名
密码学中两个核心概念：**信息摘要（哈希函数）** 和 **数字签名** 的基本原理与安全目标
发布时间：2026/7/13 16:57:38
密码学中两个核心概念信息摘要哈希函数和数字签名的基本原理与安全目标。信息摘要如 SHA-256、SM3是一种确定性单向函数输入任意长度数据输出固定长度如 SHA-256 输出 256 位SM3 输出 256 位的摘要值。其三大关键安全性质为单向性无法从摘要反推原始输入抗碰撞性极难找到两个不同输入产生相同摘要雪崩效应输入微小变化如1比特导致摘要显著变化约50%比特翻转。广泛用于文件完整性校验、密码存储加盐哈希、区块链默克尔树等场景。数字签名是基于公钥密码体制如 RSA、ECDSA、SM2构建的认证机制发送方先对消息计算摘要如用 SM3再用自身私钥加密该摘要生成签名接收方用发送方公钥解密签名得到摘要A同时对收到的消息独立计算摘要B比对 A ≡ B。若一致则可验证✅ 消息未被篡改完整性、✅ 签名者拥有对应私钥身份认证、✅ 签名不可抵赖不可否认性。二者常协同使用“先哈希再签名”既提升效率避免直接签名长消息又保障安全性利用哈希的抗碰撞性防止签名伪造。# 示例逻辑非实际实现仅示意流程messagebHello, World!digestsm3_hash(message)# 生成摘要signaturersa_sign(private_key,digest)# 私钥签名摘要verify_resultrsa_verify(public_key,digest,signature)# 公钥验签这是一个非常关键且常被误解的问题。数字签名本质上不是“对消息加密”而是对消息的摘要哈希值进行密码学变换如私钥签名运算。之所以必须“先哈希、再签名”而非直接对原始消息用私钥“加密”主要基于以下五大核心原因✅1. 效率与可行性性能约束公钥密码算法如 RSA、SM2、ECDSA计算开销大且有输入长度限制RSA 签名要求明文长度 ≤ 密钥长度 − 填充开销如 2048 位 RSA 最多处理约 256 字节而实际消息可能达 GB 级如软件安装包、视频文件。→ 直接签名不可行而哈希可将任意长消息压缩为固定短摘要如 32 字节签名运算瞬间完成。✅2. 安全性保障抗碰撞性绑定签名的安全性依赖于摘要的抗碰撞性若攻击者能构造m ≠ m但H(m) H(m)则其可用m的合法签名冒充m的签名。→ 使用强哈希如 SHA-256、SM3可将签名安全性归约为哈希函数的安全性且标准化哈希已通过长期密码分析验证。⚠️ 若跳过哈希直接设计“长消息签名方案”需重新证明其抗伪造性复杂度高、风险大。✅3. 标准化与确定性哈希是确定性、无密钥的公开函数确保发送方和接收方独立计算出完全相同的摘要前提消息一致避免因填充方式、编码差异等导致验签失败符合 PKCS#1 v2.2RSA-PSS、GB/T 32918.2SM2等标准强制要求。✅4. 支持“签名加密”混合流程如 sign-then-encrypt先哈希再签名使签名结果长度固定、可预测便于与后续加密如用对方公钥加密签名消息组合实现机密性认证一体化如 S/MIME、PGP。✅5. 消除语义攻击面如选择明文攻击直接对原始消息用私钥“加密”即 textbook RSA 签名存在严重漏洞若σ₁ m₁^d mod nσ₂ m₂^d mod n则σ₁·σ₂ ≡ (m₁·m₂)^d mod n攻击者可伪造新签名哈希填充如 PSS、SM2 的 Zₐ 消息拼接引入随机性与结构化处理彻底阻断此类代数攻击。 补充说明术语辨析❌ 错误说法“用私钥加密消息生成签名”✅ 正确理解“用私钥对消息摘要执行签名变换如 RSA 的模幂运算、SM2 的椭圆曲线签名运算”—— 这不是加密encryption而是数字签名生成signature generation目的不是保密而是认证与不可否认。# 对比示意伪代码# ❌ 危险且低效仅理论不推荐raw_sigpow(message_as_int,private_d,n)# message_as_int 可能超长或含非法值# ✅ 标准安全做法RFC 8017 / GM/T 0003.2digestsm3_hash(message)# 固定32字节padded_digestpss_encode(digest,salt)# 加盐填充sigrsa_sign_raw(private_key,padded_digest)# 对填充后摘要签名
