蚊章汇 - 公钥
type: channel
link: https://linuxcn.bwsl.wang/tag/%E5%85%AC%E9%92%A5/
items: 公钥基础设施和密码学中的私钥的角色
items: 密码学及公钥基础设施入门

公钥基础设施和密码学中的私钥的角色
type: item
date: 2018-09-26T17:09:11+08:00
description: 了解如何验证某人所声称的身份。在上一篇文章中，我们概述了密码学并讨论了密码学的核心概念： 保密性 confidentiality （让数据保密）、 完整性 integrity （防止数据被篡改）和 身份认证 authentication （确认数据源的 身份 identity ）。由于要在存在各种身份混乱的现实世界中完成身份认证，人们逐渐建立起一个复杂的 技术生态体系 technological ecosystem ，用于证明某人就是其声称的那个人。在本文中，我们将大致介绍这些体系是如何工作的。快速回顾公钥密码学及数字签名互联网世界中的身份认证依赖于公钥密码学，其中密钥分为两部分：拥有者需要保密的私钥和可以对外公开的公钥。经过公钥加密过的数据，只能用对应的私钥解密。举个例子，对于希望与记者建立联系的举报人来说，这个特性非常有用。但就本文介绍的内容而言，私钥更重要的用途是与一个消息一起创建一个 数字签名 digital signature ，用于提供完整性和身份认证。在实际应用中，我们签名的并不是真实消息，而是经过 密码学哈希函数 cryptographic hash function 处理过的消息 摘要 digest 。要发送一个包含源代码的压缩文件，发送者会对该压缩文件的 256 比特长度的 SHA-256 摘要进行签名，而不是文件本身进行签名，然后用明文发送该压缩包（和签名）。接收者会独立计算收到文件的 SHA-256 摘要，然后结合该摘要、收到的签名及发送者的公钥，使用签名验证算法进行验证。验证过程取决于加密算法，加密算法不同，验证过程也相应不同；而且，很微妙的是签名验证漏洞依然层出不穷。如果签名验证通过，说明文件在传输过程中没有被篡改而且来自于发送者，这是因为只有发送者拥有创建签名所需的私钥。方案中缺失的环节上述方案中缺失了一个重要的环节：我们从哪里获得发送者的公钥？发送者可以将公钥与消息一起发送，但除了发送者的自我宣称，我们无法核验其身份。假设你是一名银行柜员，一名顾客走过来向你说，“你好，我是 Jane Doe，我要取一笔钱”。当你要求其证明身份时，她指着衬衫上贴着的姓名标签说道，“看，Jane Doe！”。如果我是这个柜员，我会礼貌的拒绝她的请求。如果你认识发送者，你们可以私下见面并彼此交换公钥。如果你并不认识发送者，你们可以私下见面，检查对方的证件，确认真实性后接受对方的公钥。为提高流程效率，你可以举办聚会并邀请一堆人，检查他们的证件，然后接受他们的公钥。此外，如果你认识并信任 Jane Doe（尽管她在银行的表现比较反常），Jane 可以参加聚会，收集大家的公钥然后交给你。事实上，Jane 可以使用她自己的私钥对这些公钥（及对应的身份信息）进行签名，进而你可以从一个线上密钥库)获取公钥（及对应的身份信息）并信任已被 Jane 签名的那部分。如果一个人的公钥被很多你信任的人（即使你并不认识他们）签名，你也可能选择信任这个人。按照这种方式，你可以建立一个 信任网络 Web of Trust 。但事情也变得更加复杂：我们需要建立一种标准的编码机制，可以将公钥和其对应的身份信息编码成一个 数字捆绑 digital bundle ，以便我们进一步进行签名。更准确的说，这类数字捆绑被称为 证书 cerificate 。我们还需要可以创建、使用和管理这些证书的工具链。满足诸如此类的各种需求的方案构成了 公钥基础设施 public key infrastructure （PKI）。比信任网络更进一步你可以用人际关系网类比信任网络。如果人们之间广泛互信，可以很容易找到（两个人之间的）一条 短信任链 short path of trust ：就像一个社交圈。基于 GPG 加密的邮件依赖于信任网络，（理论上）只适用于与少量朋友、家庭或同事进行联系的情形。（LCTT 译注：作者提到的“短信任链”应该是暗示“六度空间理论”，即任意两个陌生人之间所间隔的人一般不会超过 6 个。对 GPG 的唱衰，一方面是因为密钥管理的复杂性没有改善，另一方面 Yahoo 和 Google 都提出了更便利的端到端加密方案。）在实际应用中，信任网络有一些“ 硬伤 significant problems ”，主要是在可扩展性方面。当网络规模逐渐增大或者人们之间的连接较少时，信任网络就会慢慢失效。如果信任链逐渐变长，信任链中某人有意或无意误签证书的几率也会逐渐增大。如果信任链不存在，你不得不自己创建一条信任链，与其它组织建立联系，验证它们的密钥以符合你的要求。考虑下面的场景，你和你的朋友要访问一个从未使用过的在线商店。你首先需要核验网站所用的公钥属于其对应的公司而不是伪造者，进而建立安全通信信道，最后完成下订单操作。核验公钥的方法包括去实体店、打电话等，都比…

密码学及公钥基础设施入门
type: item
date: 2018-06-30T17:32:00+08:00
description: 学习密码学背后的基本概念，主要是保密性、完整性和身份认证。安全通信正快速成为当今互联网的规范。从 2018 年 7 月起，Google Chrome 将对全部使用 HTTP 传输（而不是 HTTPS 传输）的站点开始显示“不安全”警告。虽然密码学已经逐渐变广为人知，但其本身并没有变得更容易理解。Let's Encrypt 设计并实现了一套令人惊叹的解决方案，可以提供免费安全证书和周期性续签；但如果不了解底层概念和缺陷，你也不过是加入了类似“ 货物崇拜 cargo cult ”的技术崇拜的程序员大军。安全通信的特性密码学最直观明显的目标是 保密性 confidentiality ： 消息 message 传输过程中不会被窥探内容。为了保密性，我们对消息进行加密：对于给定消息，我们结合一个 密钥 key 生成一个无意义的乱码，只有通过相同的密钥逆转加密过程（即解密过程）才能将其转换为可读的消息。假设我们有两个朋友 Alice 和 Bob，以及他们的 八卦 nosy 邻居 Eve。Alice 加密类似 "Eve 很讨厌" 的消息，将其发送给 Bob，期间不用担心 Eve 会窥探到这条消息的内容。对于真正的安全通信，保密性是不够的。假如 Eve 收集了足够多 Alice 和 Bob 之间的消息，发现单词 “Eve” 被加密为 "Xyzzy"。除此之外，Eve 还知道 Alice 和 Bob 正在准备一个派对，Alice 会将访客名单发送给 Bob。如果 Eve 拦截了消息并将 “Xyzzy” 加到访客列表的末尾，那么她已经成功的破坏了这个派对。因此，Alice 和 Bob 需要他们之间的通信可以提供 完整性 integrity ：消息应该不会被篡改。而且我们还有一个问题有待解决。假如 Eve 观察到 Bob 打开了标记为“来自 Alice”的信封，信封中包含一条来自 Alice 的消息“再买一加仑冰淇淋”。Eve 看到 Bob 外出，回家时带着冰淇淋，这样虽然 Eve 并不知道消息的完整内容，但她对消息有了大致的了解。Bob 将上述消息丢弃，但 Eve 找出了它并在下一周中的每一天都向 Bob 的邮箱中投递一封标记为“来自 Alice”的信封，内容拷贝自之前 Bob 丢弃的那封信。这样到了派对的时候，冰淇淋严重超量；派对当晚结束后，Bob 分发剩余的冰淇淋，Eve 带着免费的冰淇淋回到家。消息是加密的，完整性也没问题，但 Bob 被误导了，没有认出发信人的真实身份。 身份认证 Authentication 这个特性用于保证你正在通信的人的确是其声称的那样。信息安全还有其它特性，但保密性、完整性和身份验证是你必须了解的三大特性。加密和加密算法加密都包含哪些部分呢？首先，需要一条消息，我们称之为 明文 plaintext 。接着，需要对明文做一些格式上的初始化，以便用于后续的加密过程（例如，假如我们使用 分组加密算法 block cipher ，需要在明文尾部填充使其达到特定长度）。下一步，需要一个保密的比特序列，我们称之为 密钥 key 。然后，基于私钥，使用一种加密算法将明文转换为 密文 ciphertext 。密文看上去像是随机噪声，只有通过相同的加密算法和相同的密钥（在后面提到的非对称加密算法情况下，是另一个数学上相关的密钥）才能恢复为明文。（LCTT 译注：cipher 一般被翻译为密码，但其具体表达的意思是加密算法，这里采用加密算法的翻译）加密算法使用密钥加密明文。考虑到希望能够解密密文，我们用到的加密算法也必须是 可逆的 reversible 。作为简单示例，我们可以使用 XOR。该算子可逆，而且逆算子就是本身（P ^ K = C; C ^ K = P），故可同时用于加密和解密。该算子的平凡应用可以是 一次性密码本 one-time pad ，不过一般而言并不可行。但可以将 XOR 与一个基于单个密钥生成 任意随机数据流 arbitrary stream of random data 的函数结合起来。现代加密算法 AES 和 Chacha20 就是这么设计的。我们把加密和解密使用同一个密钥的加密算法称为 对称加密算法 symmetric cipher 。对称加密算法分为 流加密算法 stream ciphers 和分组加密算法两类。流加密算法依次对明文中的每个比特或字节进行加密。例如，我们上面提到的 XOR 加密算法就是一个流加密算法。流加密算法适用于明文长度未知的情形，例如数据从管道或 socket 传入。RC4 是最为人知的流加密算法，但在多种不同的攻击面前比较脆弱，以至于最新版本 （1.3）的 TLS （“HTTPS” 中的 “S”）已经不再支持该加密算法。Efforts 正着手创建新的加密算法，候选算法 ChaCha…