公钥、私钥、数字签名、数字证书、对称与非对称算法、HTTPS

对公钥和私钥有点稀里糊涂的,搜索了一些资料,作一些整理吧,先看这个:

加密--公钥
解密--私钥
签名--私钥
验证--公钥

看了这个也许会对私钥用于签名不解,其实它等同于用私钥加密,而公钥验证就是用公钥解密,但是不能用于保密信息。因为公钥是公开的。

再来一个:

1)公钥和私钥成对出现
2)公开的密钥叫公钥,只有自己知道的叫私钥
3)用公钥加密的数据只有对应的私钥可以 解密
4)用私钥加密的数据只有对应的公钥可以解密
5)如果可以用公钥解密,则必然是对应的私钥加的密
6)如果可以用私钥解密,则 必然是对应的公钥加的密

公钥和私钥都可以用来加密或解密---只要能保证用A加密,就用B解密就行。至于A是公钥还是私钥,其实可以根据不同的用途而定。

一、公钥加密,私钥解密——用于保密信息

如果你想把某个消息秘密的发给某人,那你就可以用他的公钥加密。因为只有他知道他的私钥,所以这消息也就只有他本人能解开,于是你就达到了你的目的。

二、私钥加密,公钥解密——用于数字签名

严格来说,这里说的私钥加密是用私钥对摘要进行加密,接收方可以用公钥解密,解密成功则可验证信息的发送者是私钥的拥有人。因为公钥是公开的,所以起不了保密信息的作用。

如果你想发布一个公告,需要一个手段来证明这确实是你本人发的,而不是其他人冒名顶替的。那你可以在你的公告开头或者结尾附上一段用你的私钥加密的内容(例如说就是你公告正文的一段话),那所有其他人都可以用你的公钥来解密,看看解出来的内容是不是相符的。如果是的话,那就说明这公告确实是你发的---因为只有你的公钥才能解开你的私钥加密的内容,而其他人是拿不到你的私钥的。

但这仅仅做到了数字签名的第一部分:证明这消息是你发的。数字签名还有第二部分:证明这消息内容确实是完整的---也就是没有经过任何形式的篡改(包括替换、缺少、新增)。

要做到数字签名的第二部分,需要做的是:把你公告的原文做一次哈希(md5或者sha1都行),然后用你的私钥加密这段哈希作为签名,并一起公布出去。当别人收到你的公告时,他可以用你的公钥解密你的签名,如果解密成功,并且解密出来的哈希值确实和你的公告原文一致,那么他就证明了两点:这消息确实是你发的,而且内容是完整的。 


三、对公钥进行认证——数字证书

黑客可以替换你的公钥,然后用他的私钥做数字签名给你发信息,而你用黑客伪造的公钥能成功验证,会让你误认为消息来源没变。

这种情况下需要CA(证书中心certificate authority)对公钥进行认证。证书中心用自己的私钥,对信息发送者的公钥和一些相关信息一起加密,生成"数字证书"(Digital Certificate)。

这个可以参考这篇文章:数字签名是什么? ,讲得非常好,图示很清楚。

通过在实际的使用中,公钥也不会单独出现,总是以数字证书的方式出现,以确保公钥的安全性和有效性。

四、对称与非对称算法

对称算法是说,加密过程和解密过程是对称的,用一个 密钥加密,可以用同一个密钥解密。使用公私钥的算法是非对称加密算法。

HTTPS一般使用了以下算法,其中就包括非对称和对称加密算法:
非对称加密算法:RSA,DSA/DSS
对称加密算法:AES,RC4,3DES
HASH算法:MD5,SHA1,SHA256
其中非对称加密算法用于在握手过程中加密生成的密码,对称加密算法用于对真正传输的数据进行加密,而HASH算法用于验证数据的完整性。

五、HTTPS的工作原理
HTTPS在传输数据之前需要客户端(浏览器)与服务端(网站)之间进行一次握手,在握手过程中将确立双方加密传输数据的密码信息。TLS/SSL协议不仅仅是一套加密传输的协议,更是一件经过艺术家精心设计的艺术品,TLS/SSL中使用了非对称加密,对称加密以及HASH算法。握手过程的简单描述如下:
1.浏览器将自己支持的一套加密规则发送给网站。
2.网站从中选出一组加密算法与HASH算法,并将自己的身份信息以证书的形式发回给浏览器。证书里面包含了网站地址,加密公钥,以及证书的颁发机构等信息。
3.获得网站证书之后浏览器要做以下工作:
a) 验证证书的合法性(颁发证书的机构是否合法,证书中包含的网站地址是否与正在访问的地址一致等),如果证书受信任,则浏览器栏里面会显示一个小锁头,否则会给出证书不受信的提示。
b) 如果证书受信任,或者是用户接受了不受信的证书,浏览器会生成一串随机数的密码,并用证书中提供的公钥加密。
c) 使用约定好的HASH计算握手消息,并使用生成的随机数对消息进行加密,最后将之前生成的所有信息发送给网站。
4.网站接收浏览器发来的数据之后要做以下的操作:
a) 使用自己的私钥将信息解密取出密码,使用密码解密浏览器发来的握手消息,并验证HASH是否与浏览器发来的一致。
b) 使用密码加密一段握手消息,发送给浏览器。
5.浏览器解密并计算握手消息的HASH,如果与服务端发来的HASH一致,此时握手过程结束,之后所有的通信数据将由之前浏览器生成的随机密码并利用对称加密算法进行加密。


参考:

公钥,私钥,SSL(讲的很生动) 

RSA的公钥和私钥到底哪个才是用来加密和哪个用来解密?

利用openssl进行RSA加密解密

Android客户端与PHP服务端RES公钥私钥互加解密
HTTPS那些事(一)HTTPS原理




转载于:https://my.oschina.net/ioslighter/blog/359207

<think>嗯,用户这次的问题聚焦在非对称加密的核心概念上,特别是公钥私钥机制、数字签名原理以及相关算法的协作关系。从对话历史看,用户之前已经理解了蓝牙中的SK密钥机制,现在想扩展到更通用的密码学原理。这显示出用户有系统学习密码学的需求,而不仅仅是解决某个具体技术问题。 用户提供的四个引用中,引用1和2展示了RSA在数字签名中的实际代码应用,引用3解释了非对称加密与对称加密的结合逻辑,引用4则提到Diffie-Hellman这种不同的密钥协商机制。不过用户最关心的显然是签名/验签流程中各组件的功能关系。 需要特别注意几个关键点:一是用户明确要求解释“作用”,这意味着功能定位比数学细节更重要;二是用户列出了SHA256等具体算法,说明需要关联实际应用;三是签名验签过程需要完整闭环。之前关于蓝牙SK密钥的讨论中涉及的ECDH算法可以对比说明,但这次应以RSA为主线。 用户可能存在的认知难点在于:为什么需要先哈希再签名?公钥私钥在加密和签名中的使用方向为何相反?证书和签名又是什么关系?这些都需要在解释中自然化解。 从技术严谨性考虑,必须强调两点:1)RSA签名本质是“用私钥加密哈希值”,虽然实际操作是签名算法而非加密算法;2)SHA256等哈希算法在签名中的作用是保证数据完整性。代码示例中signature方法的内部实现应该包含哈希步骤,这点要在流程中说明。 最后生成的问题要延续知识脉络:证书机制是签名的延伸应用,密钥交换则是非对称加密的另一重要场景,而量子威胁则是前瞻性话题。这些问题既能帮助用户深化理解,又不会偏离当前主题。</think>以下是非对称加密核心概念及签名/验签流程的详细解析: --- ### 一、核心组件作用 | **组件** | **作用** | **数学关系** | |----------------|--------------------------------------------------------------------------|-----------------------------------------------------------------------------| | **公钥 (Public Key)** | - 公开分发给通信方<br>- 加密数据(他人用公钥加密)<br>- 验证数字签名 | 由私钥推导:$PK = g^{SK} \mod p$<br>但**无法逆向计算**:$SK \nleftarrow f(PK)$[^2] | | **私钥 (Private Key)**| - 严格保密<br>- 解密数据(用私钥公钥加密内容)<br>- 生成数字签名 | 生成公钥的基础,非对称安全的核心 | | **RSA算法** | 实现非对称加密的数学框架:<br>- 基于大数分解难题<br>- 密钥长度通常≥2048位 | $C = M^e \mod n$ (加密)<br>$M = C^d \mod n$ (解密)<br>$(e,n)$为公钥,$d$为私钥[^1] | | **HASH (如SHA256)** | - 生成固定长度数据指纹(摘要)<br>- 保证数据完整性<br>- 防篡改 | $H = \text{SHA256}(M)$<br>不同数据$M_1 \neq M_2$ → $H(M_1) \neq H(M_2)$[^1] | | **数字签名** | 用私钥加密哈希值,证明身份并确保数据来源可信 | $\text{签名} = \text{Encrypt}(H(M), SK)$ | --- ### 二、签名与验签流程 #### 1. **签名过程**(发送方) ```mermaid graph LR A[原始数据 M] --> B[生成哈希值 H = SHA256(M)] B --> C[用私钥加密哈希值] C --> D[生成签名 Sig = Encrypt(H, SK)] D --> E[发送 M + Sig] ``` #### 2. **验签过程**(接收方) ```mermaid graph LR F[接收数据 M + Sig] --> G[计算哈希值 H1 = SHA256(M)] F --> H[用公钥解密签名: H2 = Decrypt(Sig, PK)] G --> I{对比哈希值} H --> I I --> J[H1 == H2 ? 验签成功 : 失败] ``` #### 3. **关键验证逻辑** $$ \text{验签通过} \iff \text{Decrypt}(Sig, PK) = \text{SHA256}(M) $$ - **正确性保障**:只有私钥持有者能生成可通过公钥验证的签名[^1] - **防伪造**:修改$M$会导致哈希值变化,验签失败 - **抗抵赖**:签名只能用发送方私钥生成,具备法律效力[^2] --- ### 三、各组件协作原理 1. **非对称加密传输密钥** - 步骤1:接收方发送公钥$PK$给发送方 - 步骤2:发送方生成**对称密钥**$K_{sym}$ → 用$PK$加密:$C = \text{Encrypt}(K_{sym}, PK)$ - 步骤3:接收方用私钥解密:$K_{sym} = \text{Decrypt}(C, SK)$[^3] - **优势**:解决对称加密密钥传输安全问题,后续用$K_{sym}$高速通信[^3] 2. **数字签名验证身份** - 发送方用$SK$对数据指纹签名 → 接收方用$PK$验证 - **双重保障**:RSA保证身份可信,SHA256保证数据完整[^1] --- ### 四、典型应用场景 1. **HTTPS协议** - RSA传输会话密钥 → 对称加密通信数据 - 证书包含服务器公钥和CA签名 2. **区块链交易** - 私钥签名证明资产所有权 - 公钥验证交易合法性 3. **软件分发** - 开发者用私钥签名安装包 - 用户用公钥验证未篡改 > ⚠️ **安全提示**:RSA密钥长度需≥2048位,SHA256替代MD5/SHA1已成行业标准,量子计算机威胁下推荐转向抗量子算法(如NTRU)。 ---
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值