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

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

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

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

如果应用“先加密后签名”，则音讯发送方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替换签名也无奈攻打。

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

本文分享自华为云社区《“先签名后加密”的思考》，原文作者：卡农。

点击关注，第一工夫理解华为云陈腐技术~