U盾密码学【重要】

ssl搞那么复杂，都是为了阻止对称密钥在通信过程被拦截，那么就不用通信，直接物理上给你

U盾中可以存一个对称密钥，避免对称密钥在网络上传输被拦截；

2025年2月 {

但对称密钥有个问题，对称密钥的另一半在银行，银行有内鬼的话就完了；

所有U盾里面应该藏了一个银行帮你弄的密钥对的私钥

转账时，用U盾的私钥加密（银行公钥加密（转账内容）），银行拿出客户的公钥解密，如果能解密，则证明转账真的来自于本人

}

 

假如在一个网吧，用U盾，网吧老板能用自己的U盾篡改吗？

只要u盾是个性化的，跟账户绑定就行

 

如果您没插U盾，这是必然得结果。 SSL server requires client certificate ErrorCode: 901，

 

2025年2月{ 

为了帮助理解，抛开传输层，假设所有通信工作在应用层，并假设双方线下交换了密钥，用户1001给银行他的公钥，银行给用户1001银行的公钥

正常情况下，用户发送
1001➕用户user1001的私钥加密(银行公钥加密(转给user2001三千元))，银行先拿到1001的公钥，解密成功，再拿出自己的私钥得到明文，从1001的账户划走三千元到2001账老板可以构建

老板最多能够做到
1001➕老板私钥加密(银行公钥(转给网吧老板三百元))，当银行用1001的公钥解密时会失败，直接结束

假如U盾是对称密钥，那么如果这个网吧老板从银行内鬼那里买到这个用户的公钥，则可以随意伪造用户了

}

 

================== 

2025年2月

 

https://www.zhihu.com/question/513161674?utm_campaign=Sharon&utm_content=group3_supplementQuestions&utm_medium=social&utm_psn=1869061017859919872&utm_source=wechat_session

 

1.私钥加密公钥解密，解决的是明确数据来源问题，也就是签名。

2.反过来，解决的是单向传输的数据加密传输问题。

 

除了加密以外，还有个应用叫做“签名”。这是第二个容易混淆的地方。

问这个问题的多半是把“加密”和“签名”搞混了。

 

很多人搞不清签名和加密。签名是用来防止数据被篡改的（即证明消息是我发的，我是我）

 

U盾里的私钥是读不出来的

 

公钥加密私钥解密，这里是为了解决保密传输的问题。私钥加密公钥解密，这是为了解决鉴权认证的问题，也就是俗称的数字签名。

 

在这个场景中，私钥加密是对你的软件（的hash值）签名鉴权，用于确保内容的确是你发布的。可以认为公钥加密私钥解密是为了保证内容不被第三者知道，但私钥加密公钥解密则是反过来，它希望内容被所有人都知道，并保证内容不被第三者篡改。

 

场景一：公钥加密，私钥解密

A作为发送方，要保证消息只有对方B能接收，使用对方B的公钥加密后发送，B收到数据用B的私钥解密。 由于B的私钥只有B拥有，因此只有B能正确接收这条消息。

但这个过程B不能确定消息一定是A发送过来的，因为B的公钥任何人都能得到。

场景二：私钥签名，公钥验签

A要让B确定消息一定是A发的。需要使用A的私钥签名后发送，然后B收到后用A的公钥验签，验签成功说明消息一定是A发送的，因为A的私钥只有A能拥有。

非对称密钥体系中，私钥加密公钥解密-这种方式一般用来做身份认证，不做敏感数据加密

这个加密过程是为了证明"你是你"

 

非对称加密是加密两次的，即：

1、发送方A，先用自己的私钥加密消息M得到E1，

2、再用对方的公钥加密E1得到秘文E，再将E交给接收方B

3、B收到E，先用自己的私钥解密，得到E1

4、再用A的公钥解密E1得到M

其中的每一步都有相应的安全意义：

1、第一步是A担保是自己发出的密文

2、第二步确保消息只能由B知道

3、第三步B确信确实是发给自己的

4、第四步B验证了确实是由A发出的

通信过程中，任何被拦截到的密文因为都用B的公钥加密过，所以只有B才能知道A到底发送了什么。但如果没有第一步中的用A的私钥加密，则任何人都可以冒充A和B通信，即B无法确信自己到底是在和谁通信。

其中的第一次加密是为了让对方确认到底是在和谁通信，属于安全体系中的身份验证，第二次加密才是为了保密。

 

签名，你用私钥加密，任何人都可以用你的公钥解密，但是都知道能加密的就你一个，具有不可否认性。

 

私钥只是用来验证签名，也就证明是谁发出来的，通常做法是

1. 发送方计算出原文 T1 的hash值 H1
2. 通过自己的私钥加密hash值 H1 得到一个签名S1
3. 将原文 T1 和签名 S1 一起发给对方。
4. 对方收到数据T1和S1
5. 用你的公钥解密签名S1得到一个H2，
6. 计算原文T1的hash得到H3，对比H3和H2是否一致

 

公钥加密是用来传输数据的，数据需要私钥来解密。

而私钥加密是用来签名的，需要公钥来验证密文是否被篡改。

 

这么个用法叫数字签名，用来验证加密数据就是本人发出的。

 

如果用甲的私钥加密，乙用甲的公钥可以解开这份数据，那么这个过程称之为签名，因为可以保证是甲发送的。当然这份数据没有保密的效果，因为甲的公钥是公开的。

如果用乙的公钥加密，乙可以用自己的私钥解密，这个过程是加密传输，因为除了乙之外没人能解开这份数据。但是，不能保证是甲发送的，因为任何人都可以知道乙的公钥。

公钥加密，私钥签名

 

用私钥加密，我们一般不叫做加密，而是叫做签名，用来保证信息发送来源的正确性。

 

你说的这个场景是签名

 

私钥加密过的数据目的不是为了加密使人无法读取而是为了签名防止数据遭到篡改

私钥加密后你只能读取内容但是无法修改内容

 

如果要给对方发加密信息，就用对方的公钥来加密信息，而不是用私钥加密。

 

能解开说明是本人发出的，而非篡改

 

 

 

以下是自己的理解：

对方的公钥保护内容；公钥加密解决防止窥探

我的私钥证明我是我；私钥加密解决防止伪造或者叫篡改，篡改其实并不需要窥探到明文

 

机构和特工

1特工a汇报情报，用机构中带出来的公钥加密，再用自己的私钥加密（签名）

机构拿到情报，一看来自a，拿出a的公钥解密，可以解，所以是a发来的，再用自己的私钥解密得到明文情报

2特工a昭告同行，机构不发工资号召大家罢工

a用自己的私钥加密，同行一看，用a的公钥解，一看工资发不出了

3机构公布今年年终奖，用机构的私钥加密，所有特工用机构的私钥解密

 

传统的公钥颁发可以面对面具有绝对信用，特工可以到总部办理自己的密钥对，把自己的公钥给机构，同时领机构的公钥；而互联网不同，互联网公钥是飞过去的，不可能每个网站都网浏览器操作系统事先塞好公钥

CA就是解决这个问题

服务器的公钥给CA，CA用自己的私钥（信用）给他签名，浏览器用内置的CA公钥能解密，就知道ok这个公钥是真的属于这个网站的

 

就好比一个只接受任务，不汇报的特工因为没空，让机构把公钥寄过去，特工收到之后，也不知道是不是真的，突然有一天接到任务，特工用收到的公钥解密，任务是干掉C，然后特工就干掉了C，然后被机构辞退了，机构没说过，原来邮寄的公钥被隔壁老王调包了，寄过来的是老王的公钥，老王天天拿自己的私钥给特工发任务

 

几年后特工又应聘了一家机构，这次聪明了，虽然还是邮寄，但是他要求这家机构发包的时候放一张纸条在里面，纸条上要求有地球特工工会用工会私钥加密的“欢迎加入”四个字，然后特工这次收到包裹后，用特工工会的公钥能解开，oh发现可以解密“欢迎加入”，好的这个就是机构的真的公钥；结果又悲剧了。

原来是隔壁老王也去特工工会弄了张纸条，这次包裹又被他截胡了

 

几年后特工又。。。，这次再吸取教训，要求机构把营业执照法人代表等提交到工会，工会核实后用工会的私钥加密；这次特工收到包裹后解密一看，嗯，解密出来的营业执照跟boss直聘一致；隔壁老王又想截胡，他也去工会这样搞，工会一看你丫要把别人的营业执照弄进来果断驳回

 

这个营业执照就是浏览器里的地址，客户端请求服务器公钥返回：CA私钥加密（地址、服务器公钥）

下划线的这部分是服务器提交给CA机构的，地址不能乱给CA不给你批的

浏览器拿到，先调出CA公钥解密，可以解再继续，如果可以解密，拿到地址和浏览器地址核对，对不上就要你thisisunsafe

 

特工-浏览器

机构-服务器

老王-中间人攻击

地球特工工会-CA

 

 

 

 

 

https://zhuanlan.zhihu.com/p/468290883?utm_medium=social&utm_psn=1869061127067013120&utm_source=wechat_session

加密（反之解密）和签名（反之验证签名，简称验签），是香蕉和苹果的区别，完全不同的概念。它们唯一的共同点是，底层使用了相同的“密码学库”。

从根本上来说签名/验签 和 加密/解密，是两个完全不同的密码学应用概念，首先要把这两者从根子上分开，对此我先给个最简结论，概括成：一个基本概念，两种应用。

• 一个基本概念：对于公钥密码学，至少存在签名和加密两种完全不同的“应用”。
• 加密、解密：面向的是数据接受者，提供“秘密的传输”。
• 签名、验签：面向的是数据发送者，提供“可信的背书”。

 

• 加密、解密：解决的问题是：如何秘密地传输一段消息给接收者。特别地：加密、解密过程中，使用的密钥对是接收者的密钥对！还记得上述斯诺登的故事里面，斯诺登为什幺开始要求拿到Glenn的公钥吗?
• 签名/验签，解决的问题是：如何证明传输的这一段消息，确实地来自当前所号称的发送人，特别地：签名/验签，使用的密钥对是发送者的密钥对！
• 一个基本的，常被忽略的事实是，签名和验签，处理的可以是原文而不是密文。也就是说，标准的签名和验签过程中，发送方和接受方都看到的是信息明文！