密码学：现代方法的基础知识

加密密钥

保持加密应用程序的安全依赖于对称密钥和私钥，这些密钥和私钥始终保密。用于保密的方法也受到保护。

非对称密钥和对称密钥是现代密码学中使用的两种基本算法类型。非对称密钥算法使用私钥和公钥的组合，而对称算法仅使用私钥，通常称为密钥。表 1 提供了每种算法方法的主要特征的快照。

 

安全服务和功能实现	算法方法
	对称密钥	非对称密钥
保密性	是的	是的
识别和 认证	是的	是的
正直	是的	是的
不可否认性	是，结合公钥/私钥算法	是的
加密	是，快速	是，慢
解密	是，快速	是，慢
整体安全性	高	高
密钥管理	需要在发送方和接收方交换密钥并保护密钥	需要保护发件人和收件人端的每个私钥
算法复杂性	易于理解	可能难以理解
密钥大小	128 位、192 位或 256 位或更长，但不需要像非对称密钥一样长（取决于密钥的保密性）	256 位、1024 位、2048 位、3072 位或更长。取决于棘手性（需要解决的时间和资源量）。
系统漏洞	密钥管理、 生成和使用不当	实施不当
攻击方法	蛮力，线性/差分密码分析	蛮力、线性/差分密码分析和甲骨文

 

让我们来看看如何使用这两种类型的算法来实现每个加密目标。

使用对称密钥算法的机密性

保密的主要目标是使信息远离所有不知情的人。在对称密钥加密系统中，这非常简单，是通过加密发送方和接收方之间交换的数据来实现的。发送方和接收方都可以访问用于加密和解密交换消息的同一密钥，如图 1 所示。

图1.对称密钥算法有助于使用私钥或密钥实现机密性。

只要密钥是安全的，并且只有发送方和接收方可以访问加密/解密密钥，即使传输过程中被截获，其他人也无法接收传输的消息。因此，消息保持“机密”。

使用非对称密钥算法的机密性

在非对称密钥系统中，接收者可以自由分发她/他的公钥。发送方获取公钥并验证其真实性。完成此操作需要几个步骤，如图 2 所示。为了简单起见，让我们假设发件人可以访问收件人的已验证公钥。然后，发件人使用该公钥加密邮件并将其发送给收件人。

图2.非对称密钥算法有助于通过使用公钥和私钥来实现机密性。

收件人的公钥在数学上与收件人的私钥相关。发件人和其他任何人都无法访问收件人的私钥。收件人收到消息后，私钥将用于解密消息。收件人的私钥是唯一可用于解密使用相关公钥加密的消息的私钥。由于私钥仅驻留在收件人手中，因此其他人或组织无法解密已发送的邮件。因此，消息保持“机密”。

使用对称密钥算法进行识别和身份验证

识别和身份验证的目标是首先识别对象或用户，然后对它们进行身份验证，以便我们知道我们正在与我们真正想要与之通信的人进行通信。

如何使用对称密钥方案实现这一点？图 3 显示了对称密钥识别和身份验证过程的简单示例。查看步骤 1 到 6 以更好地理解。步骤 4 使用称为“摘要”的概念。摘要或哈希是在大型数据集上计算的固定长度值。

图3.此图显示了对称密钥标识和身份验证过程的简单示例。

为什么我们需要“随机数”？

冒名顶替者可以拥有收件人传输的最后一个摘要，然后使用该摘要发出“验证我”。这些类型的攻击称为“重放攻击”，即重新发送以前使用的摘要。使用“nonce”或一次性随机数进行身份验证可防止此类攻击。在这种情况下，身份验证将失败，因为对于每个身份验证，发送方都需要一个带有全新随机数的新摘要。这些数字通常使用批准的随机数生成器生成。

现在，让我们研究一个使用 SHA3-256 算法进行标识和身份验证的真实示例。

使用 SHA-3 算法进行识别和身份验证

图 4 显示了对称密钥标识和身份验证过程的更完整示例。这使用 SHA-3 对称密钥算法，该算法是安全哈希算法 （SHA） 系列中的最新算法。Maxim Integred是首家在量产中采用SHA3-256安全认证器件的公司。查看图中的步骤 1 到 6，以更好地了解该过程。图 4 中的“随机数”基本上是防止重放攻击所需的“随机数”，如前面一节中的简单示例中所述。

图4.此图显示了使用 SHA-3 的对称密钥算法的详细示例。

使用非对称密钥算法进行识别和身份验证

如前所述，识别和身份验证的目标是首先识别对象或用户，然后对它们进行身份验证，以便我们知道我们正在与我们真正想要与之通信的人进行通信。

如何使用非对称密钥方案实现这一点？图 5 显示了对称密钥识别和身份验证过程的简单示例。查看图中的步骤 1 到 6 以了解该过程。

图5.此图显示了使用非对称密钥算法进行标识和身份验证的简单示例。

为什么我们需要一个随机数？

冒名顶替者可以获得收件人传输的最后一个签名，然后使用该签名发出“验证我”。这些类型的攻击称为“重放攻击”，即重新发送以前使用的特征码。使用随机数或一次性随机数进行身份验证可防止此类攻击。在这种情况下，身份验证将失败，因为发件人需要一个新的签名，每个身份验证都有一个全新的随机数。这些数字通常使用批准的随机数生成器生成。

现在，让我们研究一个使用椭圆曲线数字签名算法 （ECDSA） 算法进行识别和身份验证的真实示例。

使用 ECDSA 算法进行识别和身份验证

图 6 显示了使用 ECDSA 非对称密钥算法的非对称密钥识别和身份验证过程的更完整示例。图中的步骤 1 到 6 可以帮助您更好地了解该过程。

图6.使用 ECDSA 非对称密钥算法进行标识和身份验证的详细示例。

尽管此方法完成设备身份验证，但它不涵盖完整的系统身份验证过程。这包括验证收件人是否是系统的一部分，以及所需的设备数字证书验证。

比较加密算法

图 7 显示了对称和非对称密钥算法的密钥使用情况的并排比较。在进入下一个主题之前，我们需要了解以下两个概念之间的区别：

安全哈希

HMAC（散列消息身份验证代码）

图7.这是对称密钥和非对称密钥加密算法的比较。

图 8 说明了 HMAC 和安全哈希之间的差异。本质上，安全哈希使用哈希算法（如 SHA-3）来生成消息的固定长度哈希，而不考虑消息长度。HMAC 与此类似，但使用密钥作为哈希引擎的附加输入。它还生成固定长度的哈希，而不考虑输入消息长度。

图8.HMAC 和安全哈希之间存在相似之处但主要区别。

使用对称密钥算法保持完整性

保持消息完整性的目标是确保收到的任何消息或连接的任何新设备都不会携带不需要的代码或信息。让我们看一个如何使用对称密钥算法（如 SHA-3）实现此目的的示例。稍后，我们将回顾这些算法如何工作的细节。

在图 9 中，发送方使用特定键计算消息的摘要。由于这是一个对称密钥方案，因此此密钥在发送方和接收方之间共享。使用密钥生成的摘要或哈希称为 HMAC（基于哈希的消息身份验证代码）。

图9.SHA-3 对称密钥算法可保持完整性。

这是通过将消息和密钥提供给 SHA-3 引擎生成的。然后将生成的 HMAC 和消息发送给收件人。然后，接收者使用她拥有的密钥生成自己的 HMAC。然后比较两个 HMAC，如果它们匹配，则消息未被篡改。在这种情况下，有人可以截获 HMAC 和消息，然后更改消息并生成新的 HMAC 并将其发送给收件人。但是，这将不起作用，因为拦截器将没有收件人的密钥，并且HMAC将不匹配。

使用非对称密钥算法保持完整性

保持消息完整性的目标是确保收到的任何消息或连接的任何新设备都不会携带不需要的代码或信息。让我们看一个如何使用非对称密钥算法（如 ECDSA（椭圆曲线数字签名算法）实现此目的的示例。

这背后的基本思想是，发件人使用数字签名对消息进行签名，收件人验证签名，以确保收到的消息的完整性。

在图 10 中，发送方通过将消息馈送到 SHA-2 哈希引擎来计算消息的摘要。由于这是一个非对称密钥方案，因此发送方和接收方之间不共享此密钥。发送方有一个永远不会共享的私钥，而接收方有一个可以与许多人共享的公钥，反之亦然，与对称密钥算法不同，生成的摘要/哈希不使用密钥。

图 10.ECDSA 非对称密钥算法有助于保持消息完整性。

然后将生成的摘要与发送方的私钥一起馈送到 ECDSA 引擎，以生成消息的数字签名。此签名与邮件一起发送给收件人。这样就完成了已发送邮件的签名过程。

现在收件人已收到发件人的邮件和数字签名，她可以开始验证过程。此过程包括两个不同的步骤：

步骤1：收件人从收到的消息中计算消息摘要。

第 2 步：这个新计算的摘要、从发件人收到的数字签名以及发件人的公钥随后被输入 ECDSA 引擎进行验证。

在验证过程中，ECDSA 引擎会产生“是”或“否”结果。如果结果为“是”，则保留了消息完整性。如果结果为“否”，则消息完整性已受到损害。

使用非对称密钥算法实现不可否认性

由发件人的数字签名签名的邮件可用于证明邮件是由发件人发送的，并且邮件未被更改。但是，数字签名无法证明发件人的身份。身份证明是使用数字证书实现的。图 11 到 14 显示了实现完整公钥系统所需的完整步骤，在该系统中，交换的消息不能被任何一方否认。

图 11.发件人和收件人交换受信任的第三方签名的数字证书。

图 12.发件人和收件人验证受信任的第三方签名数字证书的真实性。

图 13.发件人和收件人从数字证书中提取彼此的公钥。

图 14.发件人和收件人交换无法否认的消息。

主要思想是发送者和接收者都需要相互证明他们的身份，并且他们各自的公钥需要由受信任的第三方证明真实。

为什么使用数字证书如此重要？没有它，假装是发件人的人（即冒名顶替者）可以发送一条用收件人的公钥加密的消息以及用冒名顶替者的私钥签名的数字签名。然后，冒名顶替者将向收件人发送他/她虚构的公钥。然后，收件人将使用该公钥来验证数字签名，并且所有内容都将得到验证。但是来自冒名顶替者的消息可能包含收件人永远不会怀疑的恶意信息。这是通过使用数字证书可以避免的问题，该证书验证收到的公钥确实属于发件人而不是冒名顶替者。

审核编辑：郭婷