好的，到目前为止，答案基本上都在轨道上，但我会试着回答你提出的问题：

* where did this public key come from?

公钥是非对称密码学中使用的密钥对的一部分。那里有许多加密算法，但归结为在数学上链接的公钥和私钥。它们可以这样使用：

加密（公钥，原始数据）-> 加密数据

解密（私钥，加密数据）-> 原始数据

私钥和公钥之间的数学关系的性质与密码算法有关，并很快成为 Math Overflow 的一个好话题。:)

关键部分是它们是一起生成的一对密钥。

接下来，为了处理数字签名，发送者发送：

• 原始数据、加密数据、公钥以及如何验证签名的信息（例如，正在使用什么算法）

验证者执行上述解密操作并将其输出与原始数据进行比较。如果两者相同，他就知道消息没有被篡改，因为只有发送者拥有私钥，没有合理的方法从公钥中确定私钥。

让这有点不正常......

* and what is the role of the certification authority in this process?

任何人都可以制作私钥/公钥对。鉴于今天的工具包，这是一项非常容易的任务。因此，给你我的公钥，连同所描述的加密数据和签名，就像给你一张我在 Staples 以 50 美元打印的名片一样值得信赖。要真正相信我就是我所说的我，并因此值得信赖，你需要有人在我的身份上签字（比如检查驾驶执照）。

这就是证书颁发机构的工作（简称 CA）。CA 有它自己的密钥对——它使用它的私钥为密钥持有者签署数字证书。证书包括公钥，以及一堆关于持有这个私钥的人或事物的信息。这就像我的政府让我成为一个漂亮的身份证，上面有一张没有特殊设备就无法轻易伪造的照片——你可以相信我的信息，因为你信任政府……不，因为你信任我。

通常，当系统验证签名时，它不仅会检查加密数据是否与原始数据匹配，还会检查证明公钥持有者身份的证书是否也由可信来源正确签名。通常 CA 系统组织在源自根的 CA 链中。可以在您的浏览器中找到更突出的根 CA 的集合（它们是自签名的，即由它们自己的私钥签名）。

对于高度安全的系统，可以对最新的状态信息进行额外检查。这完全取决于绝对确定发件人状态的重要性。

* and how is it (the public key) distributed to the receiver?

在这里仔细检查-您是指证书的接收者还是密钥的持有者？

发送者（密钥持有者）可以通过多种方式获得密钥对和证书。最简单的方法是在本地制作，然后向CA申请证书，提交公钥数据。在其他情况下，可以集中制作密钥并通过安全通道将密钥分发给密钥持有者。

在大多数签名情况下，密钥对由密钥持有者制作，因为它限制了私钥暴露的可能性。

当创建签名并将其发送给接收者时，公钥通常也会附加到消息中（例如，这方面的标准是 XMLDSIG，其中元素中的一个可选字段是数字证书，其中包括公钥）。

在带宽成为问题的情况下，公钥可能保存在中央存储库中——例如员工数据库，或者通常是 Active Directory 或其他 LDAP 服务器。然后签名可以引用发送者的身份，验证过程可以包括对存储库的请求以检索公钥。

* how the public key is identified for the specific digital signature?

通常通过数字证书。

当发送者去创建一个数字签名时，他通常有与他可以用于什么目的的密钥对相关联的规则。在 X509 证书标准中，证书标识了一个 Key Usage 字段，该字段说明了证书描述的密钥对的特定用途。其中一种用途恰好是数字签名，许多软件系统不允许您在证书中没有该设置的情况下创建签名。

CA 在签署证书之前实际上确定了这些设置。在许多安全策略中，如果没有特定的身份验证过程，就无法授予某些密钥使用设置，因此解决此问题的责任在于 CA 和负责它的人员（通常是 RA，注册机构）。

如果由于某种原因，您的系统不使用数字证书，则可能有其他方法来确定什么密钥对。最后，它归结为适当的安全策略以及什么被认为适合需要签名的给定活动。

您提到的问题（我们如何分发公钥？）正是公钥基础设施要解决的问题，而 PKI 本质上是一堆证书颁发机构。

在一个简单的设置中，我们将拥有每个人的公钥的中央目录；把它想象成公园中央的一块大大理石板，上面刻着公钥。任何人都可以看看它，并确保它是“真品”，因为你不能简单地在雕刻的东西上涂漆。

公共部分没有很好地连接到整个互联网，计算机无法“看到”某些信息被刻录并因此“保证正确”。此外，那里可能有数十亿个密钥持有者，这需要一块相当大的石头。所以翻译成整个计算机化的世界就是证书。

证书是一个小型结构，以传统格式包含：

• 身份（密钥所有者的姓名）；
• 公钥（据称由该人拥有）；
• 证书颁发机构在前两个部分上计算的数字签名。

CA 的角色，准确地说，是颁发证书，即对它们进行签名。您可以将证书视为包含特定公钥的一块大大理石板。要使用公钥，首先要确保它包含正确的信息；为此，您使用 CA 的公钥验证证书上的签名。如果该签名是正确的，您就知道 CA实际上签署了该证书，并且由于 CA 在检查了密钥所有者的身份之后才签署证书（通过与他们的一次性物理协议，例如密钥所有者显示ID），您可以“确信”证书中的公钥确实属于已识别的所有者。

现在您可以告诉我，我们根本没有解决问题，只是将其转移：要验证证书，您必须知道 CA 的公钥；您如何获得该密钥？答案就在数字中：一个给定的 CA 可能会签署几个证书，可能有数百万个。例如，可能有一百个 CA，它们为全世界颁发证书。通过知道这一百个公钥，您可以验证任何证书。换句话说，我们不仅移动了问题，还集中了它：我们将分发数十亿个公钥的问题变成了分发一百个公钥的问题。

而且，瞧！这正是 HTTPS 网站的做法。在浏览器和网络服务器之间连接的初始阶段，服务器会发送其证书。然后，浏览器根据其硬编码的 CA 公钥列表（由浏览器（即 Firefox）或操作系统本身（即 MacOS）提供，验证证书。一旦浏览器验证了证书，它就知道公共服务端发送的密钥，其实是属于服务端的，用它与服务端建立机密隧道。

数字签名通常分两步进行。第一步是对数据使用安全散列算法。SHA-2 算法就是一个例子。第二步是使用私有签名密钥对结果输出进行加密。

因此，当公钥验证签名时，它会解密为与消息匹配的哈希。只有使用私有签名密钥加密该散列才能使用公钥解密。

公钥由密钥对所有者创建。证书颁发机构签署公钥的证书。服务器所有者安装该签名证书。在 SSL（我假设您指的是）中，证书（包括来自证书颁发机构的密钥和签名）由您连接到的服务器传递。您的软件会检查它所连接的站点是否与证书中的数据匹配，并通过根据证书颁发机构的密钥检查其签名来验证证书。证书颁发机构使用他们的密钥进行签名，服务器使用他们的密钥进行加密。

你知道什么是公钥 - 私钥，对吧？

您想将某些内容加密为bob. 所以你需要他的公钥。你去网上搜索，但你不能确定你得到的公钥真的属于他。

因此，您采取了不同的方法：从可以向您保证一个特定密钥属于的人那里获取密钥bob。CA 正是这样做的。

CA 是如何做到的？简单的。bob向 CA 表明自己的身份并向他们发送他的公钥。这样，CA 就有了bob与此公钥相关的“身份”的东西。而且您可以相信您获得的公钥确实属于bob.