RSA数字签名与加密、解密间的关系

RSA数字签名与加密、解密间的关系 

 

 说起RSA，你们会想到公钥、私钥、加密、解密、数字签名、数字信封。。。
但也许你们和曾经的我同样，对其中的某些理解会存在误区，最近看了下关于RSA的RFC 2313文档，再加上本身的一些测试，终于理清了其中的一些关系，主要包括如下几点：
一、公钥和私钥间的关系；
二、数字签名和私钥加密间的关系；
三、数字签名的验证具体是怎样的过程；

公钥与私钥

通常，咱们能够用RSA算法生成一对密钥，公钥发放给外部客户，私钥本身保管；有如下一些应用场景：
【公钥加密、私钥解密】或者【私钥加密、公钥验证】
对于第一种场景，彷佛没有什么疑问；可是对于第二种场景，公钥验证时究竟是如何验证法我的有我的的说法，我之前一直觉得是和数字证书同样（固然这个理解有误，关于数字证书后续也会详述），只能验证不能被解密！但通过个人测试证实：私钥加密是能够用公钥解密的；因此说对于RSA算法，用任何一方密钥加密均可以用另一个密钥解密；这也从另一个角度说明，其实公钥和私钥是相对而言的，发放其中一个密钥出去，另一个天然也就成为私钥了；对于该观点，不少同窗都已经提到过，但我之前一直认为这是一个误解，汗本身一把；
另外，当咱们使用证书的时候，好比pfx、cer、jks、rsa等，从中咱们能够看出私钥比公钥暴露出了更多的信息，你们能够自行导出xml查看，固然其中不少参数是用来加速的，根本的信息仍是密钥；
好比公钥导出格式为：
<RSAKeyValue>
 <Modulus>...</Modulus>
 <Exponent>...</Exponent>
</RSAKeyValue>
私钥导出格式为：
<RSAKeyValue>
 <Modulus>...</Modulus>
 <Exponent>...</Exponent>
 <P>...</p>
 <Q>...</q>
 <DP>...</DP>
 <DQ>...</DQ>
 <InverseQ>...</InverseQ>
 <D>...</D>
</RSAKeyValue>

数字签名与私钥加密

数字签名：就是只有信息的发送者才能产生的，别人没法伪造的一段数字串，它同时也是对发送者发送的信息的真实性的一个证实。
对一段信息进行签名时，通常会先用哈希函数计算出被签名信息唯一的哈希结果值(为实用目的，下降加密成本，RSA加密不适用于大数据量加密).最后使用私钥将哈希结果值转化为数字签名.获得的数字签名对于被签名的信息和用以建立数字签名的私钥而言都是独一无二的。
按照上面的说法，数字签名=私钥加密（hash（原始数据））；可是我用相同的原始数据、相同的hash算法、相同的密钥分别进行计算获得的结果倒是不一致的，因此我一直怀疑这个描述有问题？
对此，我search了不少，ch的，en的，但都没有找到一个让我信服的解释，大多都是如上的这种解释；最后仍是求助于官方描述文档RFC 2313，下面就看看数字签名究竟是怎么回事：
数字签名包括4个步骤：消息散列，DER数据编码，RSA私钥加密和字节串到位串的转换。
这样也就能够解释上面的公式为何两边运算的结果不一致了，由于中间少了不少运算；以后我也下载了bouncycastle的jce实现源码来看，过程的确如此；
关于DER数据编码，这个会在后续文章中详述，他是一个遵循ASN.1规范的编码规范；

数字签名的验证过程

咱们在验证数字签名的时候，通常会将签名数据、原始数据、公钥一块儿做为参数输入，返回验证true或false；这样便形成了一种假象，如上面所说的：公钥是不能解密的！可是实际验证过程却不是这样的；
一样的，他彻底是数字签名的逆向过程，来看看RFC的官方描述，验证过程包括四个步骤：位串到字节串的转换，RSA公钥解密，DER数据解码，获得解密后的散列值，最后与原始数据散列值进行比较，若每一位都相同则返回true，不然返回false；

 

数字签名通常使用公钥密码体制，用私钥签名，公钥验证签名，如RSA。加密通常使用对称密码体制，如DES,AES。原理上RSA等公钥密码算法也可进行加密，但相比之下对称密码的加密速度快，故实际应用中，对称密码用于加密。