diff --git a/translated/tech/20180521 An introduction to cryptography and public key infrastructure.md b/translated/tech/20180521 An introduction to cryptography and public key infrastructure.md
index ede14e282e..b15e629991 100644
--- a/translated/tech/20180521 An introduction to cryptography and public key infrastructure.md	
+++ b/translated/tech/20180521 An introduction to cryptography and public key infrastructure.md	
@@ -1,16 +1,19 @@
 密码学及公钥基础设施入门
 ======
+
+> 学习密码学背后的基本概念，主要是保密性、完整性和身份认证。
+
 ![](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/locks_keys_bridge_paris.png?itok=Bp0dsEc9)
 
-安全通信正快速成为当今互联网的规范。从 2018 年 7 月起，Google Chrome 将对**全部**使用 HTTP 传输（而不是 HTTPS 传输）的站点[开始显示“不安全”警告][1]。虽然密码学已经逐渐变广为人知，但其本身并没有变得更容易理解。[Let's Encrypt][3] 设计并实现了一套令人惊叹的解决方案，可以提供免费安全证书和周期性续签；但如果不了解底层概念和缺陷，你也不过是加入了类似”[<ruby>船货崇拜<rt>cargo cult</rt></ruby>][4]“的技术崇拜的程序员大军。
+安全通信正快速成为当今互联网的规范。从 2018 年 7 月起，Google Chrome 将对**全部**使用 HTTP 传输（而不是 HTTPS 传输）的站点[开始显示“不安全”警告][1]。虽然密码学已经逐渐变广为人知，但其本身并没有变得更容易理解。[Let's Encrypt][3] 设计并实现了一套令人惊叹的解决方案，可以提供免费安全证书和周期性续签；但如果不了解底层概念和缺陷，你也不过是加入了类似“[<ruby>货物崇拜<rt>cargo cult</rt></ruby>][4]”的技术崇拜的程序员大军。
 
 ### 安全通信的特性
 
 密码学最直观明显的目标是<ruby>保密性<rt>confidentiality</rt></ruby>：<ruby>消息<rt>message</rt></ruby>传输过程中不会被窥探内容。为了保密性，我们对消息进行加密：对于给定消息，我们结合一个<ruby>密钥<rt>key</rt></ruby>生成一个无意义的乱码，只有通过相同的密钥逆转加密过程（即解密过程）才能将其转换为可读的消息。假设我们有两个朋友 [Alice 和 Bob][5]，以及他们的<ruby>八卦<rt>nosy</rt></ruby>邻居 Eve。Alice 加密类似 "Eve 很讨厌" 的消息，将其发送给 Bob，期间不用担心 Eve 会窥探到这条消息的内容。
 
-对于真正的安全通信，保密性是不够的。假如 Eve 收集了足够多 Alice 和 Bob 之间的消息，发现单词 "Eve" 被加密为 "Xyzzy"。除此之外，Eve 还知道 Alice 和 Bob 正在准备一个派对，Alice 会将访客名单发送给 Bob。如果 Eve 拦截了消息并将 "Xyzzy" 加到访客列表的末尾，那么她已经成功的破坏了这个派对。因此，Alice 和 Bob 需要他们之间的通信可以提供<ruby>完整性<rt>integrity</rt></ruby>：消息应该不会被篡改。
+对于真正的安全通信，保密性是不够的。假如 Eve 收集了足够多 Alice 和 Bob 之间的消息，发现单词 “Eve” 被加密为 "Xyzzy"。除此之外，Eve 还知道 Alice 和 Bob 正在准备一个派对，Alice 会将访客名单发送给 Bob。如果 Eve 拦截了消息并将 “Xyzzy” 加到访客列表的末尾，那么她已经成功的破坏了这个派对。因此，Alice 和 Bob 需要他们之间的通信可以提供<ruby>完整性<rt>integrity</rt></ruby>：消息应该不会被篡改。
 
-而且我们还有一个问题有待解决。假如 Eve 观察到 Bob 打开了标记为”来自 Alice“的信封，信封中包含一条来自 Alice 的消息”再买一加仑冰淇淋“。Eve 看到 Bob 外出，回家时带着冰淇淋，这样虽然 Eve 并不知道消息的完整内容，但她对消息有了大致的了解。Bob 将上述消息丢弃，但 Eve 找出了它并在下一周中的每一天都向 Bob 的邮箱中投递一封标记为”来自 Alice“的信封，内容拷贝自之前 Bob 丢弃的那封信。这样到了派对的时候，冰淇淋严重超量；派对当晚结束后，Bob 分发剩余的冰淇淋，Eve 带着免费的冰淇淋回到家。消息是加密的，完整性也没问题，但 Bob 被误导了，没有认出发信人的真实身份。<ruby>身份认证<rt>Authentication</rt></ruby>这个特性用于保证你正在通信的人的确是其声称的那样。
+而且我们还有一个问题有待解决。假如 Eve 观察到 Bob 打开了标记为“来自 Alice”的信封，信封中包含一条来自 Alice 的消息“再买一加仑冰淇淋”。Eve 看到 Bob 外出，回家时带着冰淇淋，这样虽然 Eve 并不知道消息的完整内容，但她对消息有了大致的了解。Bob 将上述消息丢弃，但 Eve 找出了它并在下一周中的每一天都向 Bob 的邮箱中投递一封标记为“来自 Alice”的信封，内容拷贝自之前 Bob 丢弃的那封信。这样到了派对的时候，冰淇淋严重超量；派对当晚结束后，Bob 分发剩余的冰淇淋，Eve 带着免费的冰淇淋回到家。消息是加密的，完整性也没问题，但 Bob 被误导了，没有认出发信人的真实身份。<ruby>身份认证<rt>Authentication</rt></ruby>这个特性用于保证你正在通信的人的确是其声称的那样。
 
 信息安全还有[其它特性][6]，但保密性、完整性和身份验证是你必须了解的三大特性。
 
@@ -20,17 +23,17 @@
 
 （LCTT 译注：cipher 一般被翻译为密码，但其具体表达的意思是加密算法，这里采用加密算法的翻译）
 
-加密算法使用密钥加密明文。考虑到希望能够解密密文，我们用到的加密算法也必须是<ruby>可逆的<rt>reversible</rt></ruby>。作为简单示例，我们可以使用 [XOR][7]。该算子可逆，而且逆算子就是本身（P ^ K = C; C ^ K = P），故可同时用于加密和解密。该算子的平凡应用可以是<ruby>一次性密码本<rt>one-time pad</rt></ruby>，但一般而言并不[可行][9]。但可以将 XOR 与一个基于单个密钥生成<ruby>任意随机数据流<rt>arbitrary stream of random data</rt></ruby>的函数结合起来。现代加密算法 AES 和 Chacha20 就是这么设计的。
+加密算法使用密钥加密明文。考虑到希望能够解密密文，我们用到的加密算法也必须是<ruby>可逆的<rt>reversible</rt></ruby>。作为简单示例，我们可以使用 [XOR][7]。该算子可逆，而且逆算子就是本身（`P ^ K = C; C ^ K = P`），故可同时用于加密和解密。该算子的平凡应用可以是<ruby>一次性密码本<rt>one-time pad</rt></ruby>，不过一般而言并不[可行][9]。但可以将 XOR 与一个基于单个密钥生成<ruby>任意随机数据流<rt>arbitrary stream of random data</rt></ruby>的函数结合起来。现代加密算法 AES 和 Chacha20 就是这么设计的。
 
-我们把加密和解密使用同一个密钥的加密算法称为<ruby>对称加密算法<rt>symmetric cipher</rt></ruby>。对称加密算法分为<ruby>流加密算法<rt>stream ciphers</rt></ruby>和分组加密算法两类。流加密算法依次对明文中的每个比特或字节进行加密。例如，我们上面提到的 XOR 加密算法就是一个流加密算法。流加密算法适用于明文长度未知的情形，例如数据从管道或 socket 传入。[RC4][10] 是最为人知的流加密算法，但在多种不同的攻击面前比较脆弱，以至于最新版本 （1.3）的 TLS （"HTTPS" 中的 "S"）已经不再支持该加密算法。[Efforts][11] 正着手创建新的加密算法，候选算法 [ChaCha20][12] 已经被 TLS 支持。
+我们把加密和解密使用同一个密钥的加密算法称为<ruby>对称加密算法<rt>symmetric cipher</rt></ruby>。对称加密算法分为<ruby>流加密算法<rt>stream ciphers</rt></ruby>和分组加密算法两类。流加密算法依次对明文中的每个比特或字节进行加密。例如，我们上面提到的 XOR 加密算法就是一个流加密算法。流加密算法适用于明文长度未知的情形，例如数据从管道或 socket 传入。[RC4][10] 是最为人知的流加密算法，但在多种不同的攻击面前比较脆弱，以至于最新版本 （1.3）的 TLS （“HTTPS” 中的 “S”）已经不再支持该加密算法。[Efforts][11] 正着手创建新的加密算法，候选算法 [ChaCha20][12] 已经被 TLS 支持。
 
-分组加密算法对固定长度的分组，使用固定长度的密钥加密。在分组加密算法领域，排行第一的是 [<ruby>先进加密标准<rt>Advanced Encryption Standard, AES</rt></ruby>][13]，使用的分组长度为 128 比特。分组包含的数据并不多，因而分组加密算法包含一个[工作模式][14]，用于描述如何对任意长度的明文执行分组加密。最简单的工作模式是 [<ruby>电子密码本<rt>Electronic Code Book, ECB</rt></ruby>][15]，将明文按分组大小划分成多个分组（在必要情况下，填充最后一个分组），使用密钥独立的加密各个分组。
+分组加密算法对固定长度的分组，使用固定长度的密钥加密。在分组加密算法领域，排行第一的是 [<ruby>先进加密标准<rt>Advanced Encryption Standard</rt></ruby>][13]（AES），使用的分组长度为 128 比特。分组包含的数据并不多，因而分组加密算法包含一个[工作模式][14]，用于描述如何对任意长度的明文执行分组加密。最简单的工作模式是 [<ruby>电子密码本<rt>Electronic Code Book</rt></ruby>][15]（ECB），将明文按分组大小划分成多个分组（在必要情况下，填充最后一个分组），使用密钥独立的加密各个分组。
 
 ![](https://opensource.com/sites/default/files/uploads/ecb_encryption.png)
 
-这里我们留意到一个问题：如果相同的分组在明文中出现多次（例如互联网流量中的 "GET / HTTP/1.1" 词组），由于我们使用相同的密钥加密分组，我们会得到相同的加密结果。我们的安全通信中会出现一种<ruby>模式规律<rt>pattern</rt></ruby>，容易受到攻击。
+这里我们留意到一个问题：如果相同的分组在明文中出现多次（例如互联网流量中的 `GET / HTTP/1.1` 词组），由于我们使用相同的密钥加密分组，我们会得到相同的加密结果。我们的安全通信中会出现一种<ruby>模式规律<rt>pattern</rt></ruby>，容易受到攻击。
 
-因此还有很多高级的工作模式，例如 [<ruby>密码分组链接<rt>Cipher Block Chaining, CBC</rt></ruby>][16]，其中每个分组的明文在加密前会与前一个分组的密文进行 XOR 操作，而第一个分组的明文与一个随机数构成的初始化向量进行 XOR 操作。还有其它一些工作模式，在安全性和执行速度方面各有优缺点。甚至还有 Counter (CTR) 这种工作模式，可以将分组加密算法转换为流加密算法。
+因此还有很多高级的工作模式，例如 [<ruby>密码分组链接<rt>Cipher Block Chaining</rt></ruby>][16]（CBC），其中每个分组的明文在加密前会与前一个分组的密文进行 XOR 操作，而第一个分组的明文与一个随机数构成的初始化向量进行 XOR 操作。还有其它一些工作模式，在安全性和执行速度方面各有优缺点。甚至还有 Counter (CTR) 这种工作模式，可以将分组加密算法转换为流加密算法。
 
 ![](https://opensource.com/sites/default/files/uploads/cbc_encryption.png)
 
@@ -54,7 +57,7 @@
 
 如果我们同时发送消息及其摘要，接收者可以使用相同的哈希函数独立计算摘要。如果两个摘要相同，可以认为消息没有被篡改。考虑到 [SHA-1][25] 已经变得[有些过时][26]，目前最流行的密码散列函数是 [SHA-256][24]。
 
-散列函数看起来不错，但如果有人可以同时篡改消息及其摘要，那么消息发送仍然是不安全的。我们需要将哈希与加密算法结合起来。在对称加密算法领域，我们有<ruby>消息认证码<rt>message authentication codes, MACs</rt></ruby>技术。MACs 有多种形式，但<ruby>哈希消息认证码<rt>hash message authentication codes, HMAC</rt></ruby> 这类是基于哈希的。[HMAC][27] 使用哈希函数 H 处理密钥 K、消息 M，公式为 H(K + H(K + M))，其中 "+" 代表<ruby>连接<rt>concatenation</rt></ruby>。公式的独特之处并不在本文讨论范围内，大致来说与保护 HMAC 自身的完整性有关。发送加密消息的同时也发送 MAC。Eve 可以任意篡改消息，但一旦 Bob 独立计算 MAC 并与接收到的 MAC 做比较，就会发现消息已经被篡改。
+散列函数看起来不错，但如果有人可以同时篡改消息及其摘要，那么消息发送仍然是不安全的。我们需要将哈希与加密算法结合起来。在对称加密算法领域，我们有<ruby>消息认证码<rt>message authentication codes</rt></ruby>（MAC）技术。MAC 有多种形式，但<ruby>哈希消息认证码<rt>hash message authentication codes</rt></ruby>（HMAC） 这类是基于哈希的。[HMAC][27] 使用哈希函数 H 处理密钥 K、消息 M，公式为 `H(K + H(K + M))`，其中 `+` 代表<ruby>连接<rt>concatenation</rt></ruby>。公式的独特之处并不在本文讨论范围内，大致来说与保护 HMAC 自身的完整性有关。发送加密消息的同时也发送 MAC。Eve 可以任意篡改消息，但一旦 Bob 独立计算 MAC 并与接收到的 MAC 做比较，就会发现消息已经被篡改。
 
 在非对称加密算法领域，我们有<ruby>数字签名<rt>digital signatures</rt></ruby>技术。如果使用 RSA，使用公钥加密的内容只能通过私钥解密，反过来也是如此；这种机制可用于创建一种签名。如果只有我持有私钥并用其加密文档，那么只有我的公钥可以用于解密，那么大家潜在的承认文档是我写的：这是一种身份验证。事实上，我们无需加密整个文档。如果生成文档的摘要，只要对这个指纹加密即可。对摘要签名比对整个文档签名要快得多，而且可以解决非对称加密存在的消息长度限制问题。接收者解密出摘要信息，独立计算消息的摘要并进行比对，可以确保消息的完整性。对于不同的非对称加密算法，数字签名的方法也各不相同；但核心都是使用公钥来检验已有签名。
 
@@ -64,7 +67,7 @@
 
 密码学的世界博大精深，我希望这篇文章能让你对密码学的核心目标及其组件有一个大致的了解。这些概念为你打下坚实的基础，让你可以继续深入学习。
 
-感谢 Hubert Kario，Florian Weimer 和 Mike Bursell 在本文写作过程中提供的帮助。
+感谢 Hubert Kario、Florian Weimer 和 Mike Bursell 在本文写作过程中提供的帮助。
 
 --------------------------------------------------------------------------------
 
@@ -73,7 +76,7 @@ via: https://opensource.com/article/18/5/cryptography-pki
 作者：[Alex Wood][a]
 选题：[lujun9972](https://github.com/lujun9972)
 译者：[pinewall](https://github.com/pinewall)
-校对：[校对者ID](https://github.com/校对者ID)
+校对：[wxy](https://github.com/wxy)
 
 本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出