对于“公钥加密，私钥解密”有在 ssh 的 authorized_keys 这种常见的应用场景，那么“私钥签名，公钥验证”有什么常见的应用场景？

个人目的只是想从 应用使用的角度来理解，非对称加密、公钥私钥这些概念。

对于 ssh 的`authorized_keys`的应用使用过程为：
● 服务器检查 `authorized_keys` 文件，找到与客户端提供的公钥匹配的条目。
● 服务器生成一个随机数，并使用公钥对其进行加密，然后将加密后的消息发送给客户端。
● 客户端使用私钥解密该消息，并将解密后的随机数返回给服务器。
● 服务器验证返回的随机数是否正确。如果正确，服务器接受客户端的连接请求。
从这个过程，理解了"正因为客户端使用了私钥来解密，所以才能证明客户端的身份。"，而且反过来，“私钥加密，公钥解密”是无法证明身份的。
自己也去 ssh 连接了多个服务器，查看了`authorized_keys`的内容。也看了客户端自己`~/.ssh/id_rsa.pub`。


那对于“私钥签名，公钥验证”，有什么应用场景是平时接触得到的？
- 而且最好有实物可以查看，帮助理解。
- 而且要是能有一个和我上面差不多的简单分析，就更好了。

各个 Linux 发行版的源仓库中的各种包，都是用作者的私钥签名，然后系统内置了他们的公钥来验证包是否被篡改或是被 认证的，不知道我的理解对不对

说一个场景：JWT ，用户（浏览器之类的）向认证服务器提供登录信息，认证服务器验证后把用户对应的资源访问权限信息（ Payload ）用 [认证服务器的私钥签名] ，之后把权限信息和签名（ JWT ）返回给用户，用户拿到 JWT 之后带着个 JWT 去请求，资源服务器用 [认证服务器的公钥验证] JWT 里的没有被篡改，根据 JWT 里面的权限信息给用户返回对应的资源数据

PDF 数字签名，就是私钥签公钥验

公钥加密的东西，只有私钥可以解密，
私钥加密的东西，也只有公钥可以解密。
由此引申的个种用法，利用的是以上两种机制。
最好理解的，公钥是公开的，私钥是藏起来自己用。
我用私钥加密了个文件，所有人可以用公钥解密。这叫数字签名，证明是我发的。
你用公钥加密一个文件给我，只有我可以用私钥解密，这个用于数据传输。

GitHub 或者其他的代码托管平台，对于 commit 的提交进行签名，应该属于是这个场景吧

也可以用来发邮件

请看 /t/519617 里面我的回复。

@kera0a #3 @NessajCN #7 #11 #15 #18 #20 @amiwrong123 #10 #19 #30 @LaTero #13
@iOCZS #26 @R18 #36

“用私钥加密，用公钥解密”在任何一本密码学教材上都不会出现。此外，私钥加密蕴涵着数字签名（这是一个公钥对象），但目前不知道数字签名蕴涵着公钥加密。

另请参阅 https://www.zhihu.com/question/432504839/answer/1681747812 答案和评论区。

你的问题在于书读的不多但想的太多

我记得有个开源项目 nostr 貌似可以做个例子。
大概是个去中心化的 twitter 微博，用户信息和数据存在第三方建立的节点上(relay)，用户可选择在多个不同的 relay 上存储自己和订阅别人，用户 ID 就是公钥，用户明文发推，但私信用接收者公钥加密。relay 只需要无脑收发存储，不需要对用户做任何身份验证。

现在的公钥私钥, 主要都是来签名的, 几乎不在直接加密了.
ssh 或者 ssl/tls 中, 都是用 dh/ecdh 来动态协商产生对称加密密钥.  最后,用公钥私钥来签名就好了.  因为对称的密钥不需要通过网络传输, 所以不存在加密的问题.