浅谈加密与签名的区别及其密钥使用方式

GeorgiaStar

已于 2025-02-19 16:35:29 修改

阅读量599

点赞数 16

文章标签：密码学网络安全

于 2025-02-19 16:34:37 首次发布

本文链接：https://blog.csdn.net/fuzhongmin05/article/details/145731555

版权

加密与加签的联系

加密和加签是两种不同的安全机制，目的和实现方式有所区别：

加密：目的是保证数据的保密性，防止信息在传输过程中被窃取。例如，使用对方的公钥加密数据，只有持有对应私钥的接收方才能解密。
加签：目的是验证数据的完整性和来源真实性，防止数据被篡改或伪造。通常通过哈希算法生成摘要，再用私钥对摘要加密生成签名，接收方通过公钥验签。

两者的联系在于：

均基于密码学技术（如非对称加密算法），但密钥使用方式不同：加密使用公钥加密、私钥解密，而签名使用私钥签名、公钥验签。
可结合使用以同时保障数据的保密性和完整性。

为何需要先加签再加密

在API接口合作中，先加签后加密的设计逻辑如下：

加签（签名）：发送方先用私钥对原始报文生成签名，确保报文未被篡改且来源可信。若报文被修改，验签时会因哈希值不匹配而失败。
加密：随后用接收方的公钥加密报文（含签名），确保传输过程中数据不被窃取。

接收方处理流程：

解密：用私钥解密报文，获取明文和签名。
验签：用发送方的公钥验证签名，确认报文未被篡改且来源合法。

只加密不加签的风险

若仅加密不加签，可能面临以下问题：

篡改风险：攻击者可截获加密报文，篡改后重新加密发送。接收方解密后无法识别篡改，导致处理错误数据。

例如：攻击者将转账金额从100元改为1000元，接收方解密后直接处理，造成资金损失。
身份伪造：无法验证发送方身份，攻击者可能伪造合法请求。
抵赖风险：发送方可能否认自己发送过报文，缺乏防抵赖证据。

划重点

在API接口安全设计中：

加密确保数据保密性，防止窃听；
加签确保数据完整性、来源真实性和防抵赖；
两者结合使用，才能全面应对窃取、篡改、伪造等风险。若仅加密不加签，虽能保护数据隐私，但无法防御篡改和伪造，安全性存在重大漏洞。

如何理解防篡改

你经常给你的女朋友写信，里面有绵绵情话，有个快递员很坏，喜欢偷拆看别人的信，看完后再放回去。有一天，你发现你给女朋友写信的内容被曝光了，你意识到肯定是有人偷看了你写的信，于是你决定

对信件内容进行加密

你采取了一套加密算法，如明文I love you，会被转化为密文：324678967702。

你把解密的密钥给了女友，这样只有她能解密信件内容，这样快递员即使偷看了信，也不知道里面写的是啥。哈哈，你的目的达到了。

但是这个快递员真的很坏，他心怀不满，他说你不是不让我看你的信的内容吗？那么我就把你的信件给改了，比如，把I love you的密文：324678967702给改成1234567890，你女朋友收到信后，解密出1234567890的结果可能是：你欠我的一万块钱什么时候还。你女朋友很生气的问你，你信里都写的啥呀，莫名其妙的。你意识到，信件的内容肯定是被篡改了。你要防止别人篡改，你又有了新的想法。

对信息内容追加签名

你每次写完信，除了对信件内容进行加密外，还会用一套算法，针对信件明文生成一个签名（一般不会对明文直接签名，会先用哈希算法对明文进行摘要，然后对摘要进行加密，这个密文就叫签名），这套算法会保证：只要信件明文有任何改动，生成的签名都是不一样的。这样就做到了防篡改吗？是的，回到故事中，你的女友收到信件其实包含两个密文，一个是明文加密后的内容，我们称之为密文，一个是明文摘要加密后的内容，我们称之为签名。她收到你的信后，先要进行解密操作。即先用私钥解密密文，得到解密后的明文。那这个明文与原来的明文一致吗？她用同样的算法对收到明文做摘要，记为摘要2，然后再用公钥解密签名（即验签），得到摘要1，如果摘要2与摘要1相同，那么就说明信件明文或密文没有被篡改。如果两个摘要不同，那么她马上明白，密文不可信，被篡改过，即验签不通过。

而且用来做签名的密钥是一对非对称密钥，公私钥是成对的，用私钥生成的签名，只有用对应的公钥才能验签通过。

这下任何人拿你的信件都没有办法了，即不能知道你信件的内容，也不能通过篡改信件来行骗或破坏你们的关系。

非对称加密中密钥使用方式的设计逻辑

1. 加密场景：公钥加密、私钥解密

核心目的：确保数据保密性，防止窃听。
密钥逻辑：
- 发送方用接收方的公钥加密数据 → 只有接收方的私钥能解密。
- 优势：公钥可公开分发，任何人均可加密数据，但只有私钥持有者（接收方）能解密。
不可反过来的原因：
- 若用私钥加密、公钥解密，则密文可被任何人解密（公钥是公开的），完全失去保密性。
- 例如：攻击者可截获私钥加密的报文，直接用公钥解密获取明文。

2. 签名场景：私钥签名、公钥验签

核心目的：验证数据来源真实性和完整性，防止篡改和抵赖。
密钥逻辑：
- 发送方用自身私钥对数据哈希值签名 → 接收方用发送方的公钥验证签名。
- 优势：私钥唯一性确保签名不可伪造，公钥验签可验证身份。
不可反过来的原因：
- 若用公钥签名、私钥验签，则任何人都能用公开的公钥生成签名，无法验证发送方身份。
- 例如：攻击者可伪造签名，接收方无法区分合法与非法来源。