关于加密:先加密后签名是不是安全看完这篇就秒懂

52次阅读

共计 1417 个字符，预计需要花费 4 分钟才能阅读完成。

摘要：很多平安标准及平安文章中都提到一条规定：先加密后签名是不平安的，该当先签名后加密。这条规定背地的原理是什么？先加密后签名肯定不平安吗？本文为您一一解答。

先签名后加密是指先对音讯进行签名，而后对音讯的签名值和音讯一起进行加密。如果采纳先加密后签名的形式，接管方只能晓得该音讯是由签名者发送过去的，但并不能确定签名者是否是该音讯的创建者。比方在发送一个认证凭据时采纳先加密后签名的形式，音讯在发送过程中就有可能被第三方截获并将认证凭据密文的签名值批改为本人的签名，而后发送给接管方。第三方就有可能在不需晓得认证凭据的状况下通过这种形式来通过认证获取权限。

采纳先签名后加密形式能够防止这类问题的产生，因为只有在晓得音讯明文的状况下能力对其进行签名。

尽管不同的标准形容有差别，但外围观点都是“先签名后加密”。然而这条标准的实用场景是什么呢，“先加密后签名”肯定不平安吗？须要深挖一下。

如果应用“先加密后签名”，则音讯发送方 Alice 和音讯接管方 Bob 的处理过程如下图：

Alice 发送的明文音讯先通过 Alice 私钥签名，再将音讯明文和音讯签名一起应用 Bob 的公钥加密，密文通过网络传输到 Bob。因为 Bob 应用私钥解密还原出音讯明文和签名，而私钥只有 Bob 持有，这能保障音讯明文不会泄露给第三方 Eve，而后 Bob 应用 Alice 的公钥验证音讯明文和签名是否统一，因为 Alice 的签名只有 Alice 的公钥能力验证，这能保障音讯肯定来自 Alice，不可抵赖，且没有被第三方 Mallory 篡改。在拿不到音讯明文的状况下，无奈计算出音讯签名，而还原音讯明文又必须应用 Bob 的私钥，这样就能防止网络传输过程中的中间人进行篡改攻打。

如果“先加密后签名”，会存在什么样的攻打危险呢，先看下“先加密后签名”的解决流程：

音讯明文应用 Bob 的公钥加密，不可能泄露给第三方，签名也有了，能够防篡改，不认真看的话，仿佛没什么问题。持续看上面这张图：

如果存在一个中间人 Mallory 能够拦挡 Alice 和 Bob 的音讯，在不篡改音讯明文和密文的状况下，应用 Mallory 的私钥对音讯密文进行签名，并替换 Alice 原始的签名，最初篡改后的音讯传输给接管方 Bob，Bob 依然能够胜利解密明文，同时用 Mallory 的公钥胜利验证签名，最终这条音讯会被 Bob 认为是 Mallory 发送的非法音讯。

从下面的演示来看，“先加密后签名”仿佛肯定不平安，是这样吗？中间人 Mallory 针对“先加密后签名”进行替换签名攻打得手的前提条件：

1、接管方 Bob 依据签名内容中的证书 ID 找到对应的 Mallory 公钥来验证签名。

2、接管方 Bob 仅应用公钥验签来辨认发送方的身份。

只有突破下面的任意一个前提，“先加密后签名”也是平安的：

1、Bob 应用固定的公钥来验证签名，而不是依据签名内容来找对应公钥，或者不应用多个公钥尝试验签。即 Mallory 替换签名后，Bob 依然用 Alice 的公钥验证签名，必定能发现申请被篡改。

2、Bob 应用公钥 + 应用层属性一起辨认发送方的身份，假如 Alice 在音讯明文中携带本人的用户 ID，Bob 验证公钥和用户 ID 是否匹配，即便 Mallory 替换签名也无奈攻打。

所以“先加密后签名”是不是平安，还要看业务利用是怎么设计的，不能相对的认定为不平安。