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

[amiwrong123]

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

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


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

[mark2025]

ssh 也可能双向认证的： 即认证服务端，也认证客户端

[neilp]

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

[amiwrong123]

@expy #39
那如果是不省事的做法呢，还会做啥呀

[amiwrong123]

@mark2025 #41
authorized_keys 我知道是服务器用来验证客户端的身份的。
你说的“认证服务端”，是指那个客户端保存的 known_hosts 文件吗？

但我看了 known_hosts 的用法：
A 通过 ssh 首次连接到 B ，B 会将公钥 1 传递给 A ，A 将公钥 1 存入 known_hosts 文件中，以后 A 再连接 B 时，B 依然会传递给 A 一个公钥 2 ，OpenSSH 会核对公钥，通过对比公钥 1 与公钥 2 是否相同来进行简单的验证，如果公钥不同，OpenSSH 会发出警告， 避免你受到 DNS Hijack 之类的攻击。

---------

只是一个很简单的对比 公钥 1 和公钥 2 啊

[raw0xff]

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

[jdkxnktkdkxod]

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

[amiwrong123]

@Xheldon #29
哈哈，没想到有你这个应用场景。