OpenSSL 入门：密码学基础知识

本文是使用 OpenSSL 的密码学基础知识的两篇文章中的第一篇，OpenSSL 是在 Linux 和其他系统上流行的生产级库和工具包。（要安装 OpenSSL 的最新版本，请参阅 这里 。）OpenSSL 实用程序可在命令行使用，程序也可以调用 OpenSSL 库中的函数。本文的示例程序使用的是 C 语言，即 OpenSSL 库的源语言。

本系列的两篇文章涵盖了加密哈希、数字签名、加密和解密以及数字证书。你可以从 我的网站 的 ZIP 文件中找到这些代码和命令行示例。

让我们首先回顾一下 OpenSSL 名称中的 SSL。

安全套接字层 (Secure Socket Layer)（SSL）是 Netscape 在 1995 年发布的一种加密协议。该协议层可以位于 HTTP 之上，从而为 HTTPS 提供了 S： 安全(secure)。SSL 协议提供了各种安全服务，其中包括两项在 HTTPS 中至关重要的服务：

SSL 有多个版本（例如 SSLv2 和 SSLv3），并且在 1999 年出现了一个基于 SSLv3 的类似协议 传输层安全性(Transport Layer Security)（TLS）。TLSv1 和 SSLv3 相似，但不足以相互配合工作。不过，通常将 SSL/TLS 称为同一协议。例如，即使正在使用的是 TLS（而非 SSL），OpenSSL 函数也经常在名称中包含 SSL。此外，调用 OpenSSL 命令行实用程序以 openssl 开始。

除了 man 页面之外，OpenSSL 的文档是零零散散的，鉴于 OpenSSL 工具包很大，这些页面很难以查找使用。命令行和代码示例可以将主要主题集中起来。让我们从一个熟悉的示例开始（使用 HTTPS 访问网站），然后使用该示例来选出我们感兴趣的加密部分进行讲述。

此处显示的 client 程序通过 HTTPS 连接到 Google：

可以从命令行编译和执行该程序（请注意 -lssl 和 -lcrypto 中的小写字母 L）：

该程序尝试打开与网站 www.google.com 的安全连接。在与 Google Web 服务器的 TLS 握手过程中，client 程序会收到一个或多个数字证书，该程序会尝试对其进行验证（但在我的系统上失败了）。尽管如此，client 程序仍继续通过安全通道获取 Google 主页。该程序取决于前面提到的安全工件，尽管在上述代码中只着重突出了数字证书。但其它工件仍在幕后发挥作用，稍后将对它们进行详细说明。

通常，打开 HTTP（非安全）通道的 C 或 C++ 的客户端程序将使用诸如文件描述符或网络套接字之类的结构，它们是两个进程（例如，这个 client 程序和 Google Web 服务器）之间连接的端点。另一方面，文件描述符是一个非负整数值，用于在程序中标识该程序打开的任何文件类的结构。这样的程序还将使用一种结构来指定有关 Web 服务器地址的详细信息。

这些相对较低级别的结构不会出现在客户端程序中，因为 OpenSSL 库会将套接字基础设施和地址规范等封装在更高层面的安全结构中。其结果是一个简单的 API。下面首先看一下 client 程序示例中的安全性详细信息。

在与 Web 服务器握手期间，client 程序会接收一个或多个数字证书，以认证服务器的身份。但是，client 程序不会发送自己的证书，这意味着这个身份验证是单向的。（Web 服务器通常配置为 不 需要客户端证书）尽管对 Web 服务器证书的验证失败，但 client 程序仍通过了连接到 Web 服务器的安全通道继续获取 Google 主页。

为什么验证 Google 证书的尝试会失败？典型的 OpenSSL 安装目录为 /etc/ssl/certs，其中包含 ca-certificates.crt 文件。该目录和文件包含着 OpenSSL 自带的数字证书，以此构成 信任库(truststore)。可以根据需要更新信任库，尤其是可以包括新信任的证书，并删除不再受信任的证书。

client 程序从 Google Web 服务器收到了三个证书，但是我的计算机上的 OpenSSL 信任库并不包含完全匹配的证书。如目前所写，client 程序不会通过例如验证 Google 证书上的数字签名（一个用来证明该证书的签名）来解决此问题。如果该签名是受信任的，则包含该签名的证书也应受信任。尽管如此，client 程序仍继续获取页面，然后打印出 Google 的主页。下一节将更详细地介绍这些。

让我们从客户端示例中可见的安全工件（数字证书）开始，然后考虑其他安全工件如何与之相关。数字证书的主要格式标准是 X509，生产级的证书由诸如 Verisign 的 证书颁发机构(Certificate Authority)（CA）颁发。

数字证书中包含各种信息（例如，激活日期和失效日期以及所有者的域名），也包括发行者的身份和数字签名（这是加密过的加密哈希值）。证书还具有未加密的哈希值，用作其标识指纹。

哈希值来自将任意数量的二进制位映射到固定长度的摘要。这些位代表什么（会计报告、小说或数字电影）无关紧要。例如， 消息摘要版本 5(Message Digest version 5)（MD5）哈希算法将任意长度的输入位映射到 128 位哈希值，而 SHA1（ 安全哈希算法版本 1(Secure Hash Algorithm version 1)）算法将输入位映射到 160 位哈希值。不同的输入位会导致不同的（实际上在统计学上是唯一的）哈希值。下一篇文章将会进行更详细的介绍，并着重介绍什么使哈希函数具有加密功能。

数字证书的类型有所不同（例如根证书、中间证书和最终实体证书），并形成了反映这些证书类型的层次结构。顾名思义，根证书位于层次结构的顶部，其下的证书继承了根证书所具有的信任。OpenSSL 库和大多数现代编程语言都具有 X509 数据类型以及处理此类证书的函数。来自 Google 的证书具有 X509 格式，client 程序会检查该证书是否为 X509_V_OK。

X509 证书基于 公共密钥基础结构(public-key infrastructure)（PKI），其中包括的算法（RSA 是占主导地位的算法）用于生成密钥对：公共密钥及其配对的私有密钥。公钥是一种身份： Amazon 的公钥对其进行标识，而我的公钥对我进行标识。私钥应由其所有者负责保密。

成对出现的密钥具有标准用途。可以使用公钥对消息进行加密，然后可以使用同一个密钥对中的私钥对消息进行解密。私钥也可以用于对文档或其他电子工件（例如程序或电子邮件）进行签名，然后可以使用该对密钥中的公钥来验证签名。以下两个示例补充了一些细节。

在第一个示例中，Alice 将她的公钥分发给全世界，包括 Bob。然后，Bob 用 Alice 的公钥加密邮件，然后将加密的邮件发送给 Alice。用 Alice 的公钥加密的邮件将可以用她的私钥解密（假设是她自己的私钥），如下所示：

理论上可以在没有 Alice 的私钥的情况下解密消息，但在实际情况中，如果使用像 RSA 这样的加密密钥对系统，则在计算上做不到。

现在，第二个示例，请对文档签名以证明其真实性。签名算法使用密钥对中的私钥来处理要签名的文档的加密哈希：

假设 Alice 以数字方式签署了发送给 Bob 的合同。然后，Bob 可以使用 Alice 密钥对中的公钥来验证签名：

假若没有 Alice 的私钥，就无法轻松伪造 Alice 的签名：因此，Alice 有必要保密她的私钥。

在 client 程序中，除了数字证书以外，这些安全性都没有明确展示。下一篇文章使用使用 OpenSSL 实用程序和库函数的示例填充更多详细的信息。

同时，让我们看一下 OpenSSL 命令行实用程序：特别是在 TLS 握手期间检查来自 Web 服务器的证书的实用程序。调用 OpenSSL 实用程序可以使用 openssl 命令，然后添加参数和标志的组合以指定所需的 *** 作。

看看以下命令：

该输出是组成 加密算法套件(cipher suite)()的相关算法的列表。下面是列表的开头，加了澄清首字母缩写词的注释：

下一条命令使用参数 s_client 将打开到 www.google.com 的安全连接，并在屏幕上显示有关此连接的所有信息：

诸如 Google 之类的主要网站通常会发送多个证书进行身份验证。

输出以有关 TLS 会话的摘要信息结尾，包括加密算法套件的详细信息：

client 程序中使用了协议 TLS 1.2，Session-ID 唯一地标识了 openssl 实用程序和 Google Web 服务器之间的连接。Cipher 条目可以按以下方式进行解析：

加密算法套件正在不断发展中。例如，不久前，Google 使用 RC4 流加密算法（RSA 的 Ron Rivest 后来开发的 Ron’s Cipher 版本 4）。 RC4 现在有已知的漏洞，这大概部分导致了 Google 转换为 AES128。

我们通过安全的 C Web 客户端和各种命令行示例对 OpenSSL 做了首次了解，使一些需要进一步阐明的主题脱颖而出。 下一篇文章会详细介绍 ，从加密散列开始，到对数字证书如何应对密钥分发挑战为结束的更全面讨论。

via: https://opensource.com/article/19/6/cryptography-basics-openssl-part-1

作者： Marty Kalin 选题： lujun9972 译者： wxy 校对： wxy

对称加解密算法中，当前最为安全的是 AES 加密算法（以前应该是是 DES 加密算法），PHP 提供了两个可以用于 AES 加密算法的函数簇： Mcrypt 和 OpenSSL 。

其中 Mcrypt 在 PHP 7.1.0 中被弃用（The Function Mycrypt is Deprecated)，在 PHP 7.2.0 中被移除，所以即可起你应该使用 OpenSSL 来实现 AES 的数据加解密。

在一些场景下，我们不能保证两套通信系统都使用了相函数簇去实现加密算法，可能 siteA 使用了最新的 OpenSSL 来实现了 AES 加密，但作为第三方服务的 siteB 可能仍在使用 Mcrypt 算法，这就要求我们必须清楚 Mcrypt 同 OpenSSL 之间的差异，以便保证数据加解密的一致性。

下文中我们将分别使用 Mcrypt 和 OpenSSL 来实现 AES-128/192/256-CBC 加解密，二者同步加解密的要点为：

协同好以上两点，就可以让 Mcrypt 和 OpenSSL 之间一致性的对数据进行加解密。

AES 是当前最为常用的安全对称加密算法，关于对称加密这里就不在阐述了。

AES 有三种算法，主要是对数据块的大小存在区别：

AES-128：需要提供 16 位的密钥 key

AES-192：需要提供 24 位的密钥 key

AES-256：需要提供 32 位的密钥 key

AES 是按数据块大小（128/192/256）对待加密内容进行分块处理的，会经常出现最后一段数据长度不足的场景，这时就需要填充数据长度到加密算法对应的数据块大小。

主要的填充算法有填充 NUL("0") 和 PKCS7，Mcrypt 默认使用的 NUL("0") 填充算法，当前已不被推荐，OpenSSL 则默认模式使用 PKCS7 对数据进行填充并对加密后的数据进行了 base64encode 编码，所以建议开发中使用 PKCS7 对待加密数据进行填充，已保证通用性（alipay sdk 中虽然使用了 Mcrypt 加密簇，但使用 PKCS7 算法对数据进行了填充，这样在一定程度上亲和了 OpenSSL 加密算法）。

Mcrypt 的默认填充算法。NUL 即为 Ascii 表的编号为 0 的元素，即空元素，转移字符是 "\0"，PHP 的 pack 打包函数在 'a' 模式下就是以 NUL 字符对内容进行填充的，当然，使用 "\0" 手动拼接也是可以的。

OpenSSL的默认填充算法。下面我们给出 PKCS7 填充算法 PHP 的实现：

默认使用 NUL("\0") 自动对待加密数据进行填充以对齐加密算法数据块长度。

获取 mcrypt 支持的算法，这里我们只关注 AES 算法。

注意：mcrypt 虽然支持 AES 三种算法，但除 MCRYPT_RIJNDAEL_128 外， MCRYPT_RIJNDAEL_192/256 并未遵循 AES-192/256 标准进行加解密的算法，即如果你同其他系统通信（java/.net），使用 MCRYPT_RIJNDAEL_192/256 可能无法被其他严格按照 AES-192/256 标准的系统正确的数据解密。官方文档页面中也有人在 User Contributed Notes 中提及。这里给出如何使用 mcrpyt 做标注的 AES-128/192/256 加解密

即算法统一使用 MCRYPT_RIJNDAEL_128 ，并通过 key 的位数 来选定是以何种 AES 标准做的加密，iv 是建议添加且建议固定为16位（OpenSSL的 AES加密 iv 始终为 16 位，便于统一对齐），mode 选用的 CBC 模式。

mcrypt 在对数据进行加密处理时，如果发现数据长度与使用的加密算法的数据块长度未对齐，则会自动使用 "\0" 对待加密数据进行填充，但 "\0" 填充模式已不再被推荐，为了与其他系统有更好的兼容性，建议大家手动对数据进行 PKCS7 填充。

openssl 簇加密方法更为简单明确，mcrypt 还要将加密算法分为 cipher + mode 去指定，openssl 则只需要直接指定 method 为 AES-128-CBC，AES-192-CBC，AES-256-CBC 即可。且提供了三种数据处理模式，即 默认模式 0 / OPENSSL_RAW_DATA / OPENSSL_ZERO_PADDING 。

openssl 默认的数据填充方式是 PKCS7，为兼容 mcrpty 也提供处理 "0" 填充的数据的模式，具体为下：

options 参数即为重要，它是兼容 mcrpty 算法的关键：

options = 0 : 默认模式，自动对明文进行 pkcs7 padding，且数据做 base64 编码处理。

options = 1 : OPENSSL_RAW_DATA，自动对明文进行 pkcs7 padding， 且数据未经 base64 编码处理。

options = 2 : OPENSSL_ZERO_PADDING，要求待加密的数据长度已按 "0" 填充与加密算法数据块长度对齐，即同 mcrpty 默认填充的方式一致，且对数据做 base64 编码处理。注意，此模式下 openssl 要求待加密数据已按 "0" 填充好，其并不会自动帮你填充数据，如果未填充对齐，则会报错。

故可以得出 mcrpty簇 与 openssl簇 的兼容条件如下：

建议将源码复制到本地运行，根据运行结果更好理解。

1.二者使用的何种填充算法。

2.二者对数据是否有 base64 编码要求。

3.mcrypt 需固定使用 MCRYPT_RIJNDAEL_128，并通过调整 key 的长度 16, 24，32 来实现 ase-128/192/256 加密算法。

---