《哈希函数中的数字签名技术.doc》由会员分享，可在线阅读，更多相关《哈希函数中的数字签名技术.doc（8页珍藏版）》请在三一文库上搜索。
1、哈希函数中的数字签名技术文中所讲的数字签名技术，就是我们在密码学中保证身份同一性所用到的最重要的工具。身份同一性的意思即是，如何证明某条消息就是“我”发出的，别人不能伪造，我也不能抵赖。虽然数字签名技术也会用到成对的密钥对，但与我们所说的公钥密码学重点却有所不同。（2）可以将本文视为思考密码学工具的一个教程或者范本，能耐心读下去，也就明白了密码学是怎么样一回事、我们在密码学中是如何思考的。回首近几年，我有幸经历了两个相互冲突、却又令人着迷的时代潮流变迁。第一个潮流变迁是：专家学者们耗费四十年设计的密码学，终于派上用场；从信息加密、电话安全、到加密数字货币，我们可以在生活的方方面面发现使用密码学
2、的例子。第二个潮流变迁是：所有密码学家已经做好准备，迎接以上美好的幻灭。正文开始之前我得重申一下，本文所讲的不是所谓量子计算启示录（末日预言），也不是要讲 21 世纪密码学的成功。我们要谈论的是另一件未成定局的事情密码学有史以来最简单的（也是最酷炫的）技术之一：基于散列函数的签名。在 20 世纪 70 年代末，Leslie Lamport 发明了基于哈希函数（Hash Function，又称散列函数）的签名 ，并经过 Ralph Merkle 等人进一步改进。而后的很多年，这被视为密码学领域一滩有趣的“死水”，因为除了相应地产生冗长的（对比其他复杂方案）签名，基于哈希函数的签名好像没有什么作用
3、。然而近几年来，这项技术似乎有了复苏的迹象。这很大程度归因于它的特性不同于其他基于RSA或离散对数假设的签名，哈希函数签名被视为可以抵抗量子计算攻击（如 Shors 算法）。首先，我们进行一些背景介绍。背景：哈希函数和签名方法在正式介绍哈希函数签名之前，首先你得知道密码学中的哈希函数是什么。哈希函数可以接受一串字符（任意长度）作为输入，经过“消化”后，产生固定长度的输出。常见的密码学哈希运算，像是 SHA2、SHA3 或 Blake2 等，经运算会产生长度介于 256 512 位的输出。一个函数 H（。） 要被称作“密码学”哈希函数，必须满足一些安全性的要求。这些要求有很多，不过我们主要聚焦在
4、以下三个方面：抗-原像攻击 Pre-image resistance （或俗称“单向性”）：给定输出 Y=H（X），想要找到对应的输入 X 使得 H（X）=Y 是一件“极度费时”的工作。（这里当然存在许多例外，但最棒的部分在于，不论 X 属于什么分布，找到 X 的时间成本和暴力搜寻相同。）抗-次原像攻击：这和前者有些微的差别。给定输入 X，对于攻击者来说，要找到另一个 X 使得 H（X）=H（X） 是非常困难的。抗-碰撞：很难找到两个输入 X1， X2，使得 H（X1）=H（X2）。要注意的是，这个假设的条件比 抗-次原像攻击还要严苛。因为攻击者可以从无垠的选择中寻找任意两个输入。我们相信所有
5、本文提到的哈希函数示例都能提供上述的所有特性。换言之，没有任何可行的（甚至是概念上的）方法能破解它。当然这种情况也是会变的，如果破解的方法被找到，我们当然会立即停用哈希函数（稍后会讨论关于量子计算攻击的特例）。我们的目标是使用哈希函数构造数字签名方案，因此简要回顾数字签名这个词能带来很大的帮助。数字签名方法源于公钥的使用，使用者（签署人）生成一对密钥：公钥和私钥。使用者自行保管私钥，并能够用私钥“签署”任何消息，从而产生相应的数字签名。任何一个持有公钥的人都能验证该消息正确性和相关签名。从安全的角度来说，我们希望签名是不可伪造的，或是说“存在不可伪造性”。这意味着攻击者（没有私钥控制权的人）无
6、法在某段消息上伪造你的签名。Lamport 一次性签名在 1979 年，一位名叫 Leslie Lamport 的数学家发明了世界上第一个基于哈希函数的签名。Lamport 发现只要使用简单的哈希函数，或是单向函数，就可以构建出非常强大的数字签名方法。强大的前提是，用户只需要做一次签名的动作就能保证安全性！后续会做更详细的阐述。为了更好的讨论，我们假设以下条件：一个哈希函数，它能接受 256 位的输入并产生 256 位的输出； SHA256 哈希函数就是个绝佳的示范工具；我们也需要能产生随机输入的方法。假设我们的目标是对 256 位的消息进行签名。要得到我们需要的密钥，首先需要生成随机的 51
7、2 个位字符串，每个位字符串长度为 256 位。为了便于理解，我们将这些字串列为两个独立的表，并以符号代指：sk0= sk10， sk20， 。.，sk2560sk1= sk11， sk21， 。.，sk2561我们以列表 （sk0， sk1） 表示用来签名的 密钥。接下来为了生成公钥，我们将随机的位字符串通过 H（。） 进行哈希运算，得到公钥如下表：pk0= H（sk10）， H（sk20）， 。.，H（sk2560）pk1= H（sk11）， H（sk21）， 。.，H（sk2561）现在我们可以将公钥 （pk0，pk1） 公布给所有人知道。比如说，我们可以把公钥发给朋友，嵌入证书中，或是
8、发布在 Keybase 上。接着我们使用密钥对 256 位消息 M 进行签名。首先我们得将消息 M 重现为独立的 256 位元（Bit，又称“比特”）：M1， M2， 。.， M256 0， 1签名算法的其余部分非常简单。我们从消息 M 的第 1 位至第 256 位，逐一相应在密钥列表中的其中一个密钥上取出字符串。而所选密钥取决于我们要签名的消息每一位（bit）的值。具体一点地说，对于 i = 1，256，如果第 i 位的消息位元 Mi = 0，我们会从 sk0 表中选择第 i 个字符 （ski0） ，作为我们签名的一部分；如果第 i 位的消息位元 Mi = 1，我们则从 sk1 表进行前述过
9、程（即，如果我们要对消息 M 中的第 3 位进行签名，而该位值为 0，则使用 sk0 中的第三位，sk03，作为我们签名的一部分）。对每个消息位元完成此操作后，我们将选中的字符串连接，得到签名。过程如图示说明，因为部分过程化简，密钥和消息长度只有 8 个 bit（位元）。要注意的是，每个色块代表的都是不同的随机 256 位字符串。当某个用户（已经知道公钥 （pk0， pk1）收到消息 M 和签名，她能够轻易地验证这个签名。我们以 si 表示签名中第 i 个组成部分，用户能够检查相应的消息 Mi 并计算哈希值 H（si） 。如果 Mi = 0 ，则哈希值必须匹配公钥 pk0 中的元素；如果 Mi
10、 = 1 ，则哈希值必须匹配公钥 pk1 中的元素。如果签名中的每个元素经过哈希运算后，都能找到对应的正确部分的公钥，我们就会说这个签名是有效的。以下是验证过程图示，签名中至少有一个签名元素：如果你开始觉得 Lamport 的计划有些疯狂，你既是对的，也是错的。首先探讨下这个数字签名方法的弊端。我们会发现， Lamport 方法的签名和密钥实在太大了，大约有数千 bits。而且更要命的是，这个方法存在严重的安全局限：每个密钥只能被用来签名一个消息，所以 Lamport 方法作为“一次性签名” 在这里被拿来举例。这种安全局限为什么存在呢？回想一下， Lamport 签名表明了在各个消息位元上可能
11、的两个密钥之一。假如只需要签署一条信息，这个签名方法完全没问题。然而，如果我签署了两条在每一个对应位置 i 的 bit 值都不同的消息，然后连同密钥一起发送出去，这可能导致大问题！假设攻击者从不同的消息得到两个有效的签名，她便能够发起 “混合搭配（mix and match）”攻击，成功伪造签署第三条我从未签名过的信息。以下图示说明这个攻击过程：这个问题的严重程度取决于你签名的消息的相异程度，以及有多少消息被攻击者给截获了。但总的来说，这肯定不是件好事。让我们总结一下 Lamport 签名方法；它很简单、快速，但它在实际应用上还有很多不足之处。或许我们可以做一点优化？从一次性签名到多次签名：基
12、于默克尔树 （Merkles tree） 的签名Lamport 签名方法是个好的开端，但是无法用单一密钥签名多条信息，是它最大的弊端。MarTIn Hellman 的学生 Ralph Merkle 由此得到大量启发，他很快地想到了一个聪明的解决办法。虽然我们不打算在这里展开解释默克尔方法的步骤，我们还是来试着理清 Ralph 的想法。我们现在的目标是用 Lamport 签名方法签署 N 条信息。最直观的方法是，以最初的 Lamport 方法生成 N 个不同的密钥对，然后将所有公钥关联起来，集合成一个超巨大的 mega-key。（mega-key是我现编的术语。）如果签名者继续拿着这么一把密钥集
13、合，她就可以对 N 条不同消息进行签名，严格上来讲这也只是一把 Lamport 密钥。看起来，这样就解决了密钥重用的问题。验证者也有对应的公钥能够验证所有收到的消息。没有任何的 Lamport 密钥被使用两次。很明显的，这种方法很糟糕，因为时间成本太高了。具体地说，上述这种天真的方法中，为了达到要求的签名次数，签名者必须分发比普通 Lamport 公钥还要大数倍的公钥（签名者还要继续拿着同样巨大的私钥）。人们很可能会对这种结果感到不满，也会反思有没有办法避免这种负作用产生。接下来，让我们进入 Merkle 方法。Merkle 方法希望能找到一个能签署多条不同消息的方法，同时避免公钥的成本线性激
14、增。Merkle 方法的实现如下：1.首先，生成 N 个独立的 Lamport 密钥，我们以 （PK1， SK1）， 。.， （PKN， SKN） 表示之。2.接下来，将每一个公钥分别放到 Merkle hash tree （见下图），并计算根节点哈希值。这个根节点就会成为Merkle签名方法中的 “主公钥”。3.签名者报关全部的 Lamport 密钥（公钥和私钥），用于签名。关于 Merkle tree 的更多描述请点击这里。概略地说，Merkle 方法提供了一种能收集不同的值，并用一个 “根” 哈希（例子中使用的哈希函数，长度为 256 bits）代表所收集的值的方法。给出这个根哈希，就能
15、简单“证明” 某个元素存在于这个给出的哈希树。而且这个证明的大小和叶节点数量成对数关系。-Merkle tree，来自维基百科的解释。Lamport 公钥被放进叶节点中，然后根节点成为主公钥。-要签名的时候，签名者从 Merkle tree 中直接选择公钥，并用对应的 Lamport 密钥签名。接着她将得到的签名结果连接 Lamport 公钥并附上“Merkle 证明”。Merkle root 可以来佐证该默克尔树中包含选中的公钥（即整个方法使用的公钥）。最后签名者将整个集合当作消息签名发送出去。（验证者只要直接将这个“签名”分别解压为 Lamport 签名、 Lamport 公钥、 Merk
16、le 证明，就能进行验证。验证者能够依靠拿到的 Lamport 公钥验证 Lamport 签名，并用 Merkle 证明这把公钥的确存在于 Merkle tree 中。只要满足这三个条件，验证者就能确信签名是有效的。）这个方法的缺点是会将“签名”大小增加两倍以上。不过，现在 Merkle 方法主要的公钥只是一串简单的哈希值，使得这个方法比上面提到的原始 Lamport 方法更为简洁。最后还有个优化部分，密码学强度的伪随机数发生器能够输出生成各式各样的密钥，同时“压缩”密钥数据本身。这使得原先庞大的位元（显然是随机的）能够转换为简短的“种子（seed）”。很赞啦！让签名和密钥更有效率一点Merk
17、le 方法使得一次性签名转变为 N 次性签名。构造这种方法仍然需要基于某些一次性签名方法，比如 Lamport 方法；但不幸的是，Lamport 方法的（带宽）成本仍相对高昂。有两种主要的方法可以降低这些成本。第一种也是 Merkle 提出的；为了更好的解释许多强大的签名方法，我们优先说明这项技术。回想一下 Lamport 方法，要对一条 256 位的消息进行签名，我们需要一个包含 512 个独立密钥（和公钥）位串的向量，签名本身就是 256 个密钥位串的集合。（这些数字会被需要签名的消息位元激活，位元可以是 “0” 或 “1” ，因此需要从两张不同的密钥表中提取适合的密钥元素。 ）这里引发了
18、新的思考：如果我们不对所有的消息位元进行签名，会怎么样呢？更详细点说，在 Lamport 方法中，我们通过输出密钥位串对一条消息的每个位元进行签名无论它的值是什么。如果我们不要同时签名一条消息中 0 和 1 的位元，而是只签名 1 的位元，那又会如何呢？这么做能够将公钥和私钥的大小减半，因为我们可以完全丢掉整条 sk0 列。现在我们只有单一列位串的密钥 sk1，。.，sk256，对消息的每个位元 Mi = 1我们都会输出一个字符串 ski；对于消息的每个位元 Mi = 0我们都会输出。.。.无（因为许多消息都会包含很多的 0 位元，这么做能缩减签名大小，这些 0 位元将不再带来任何成本）。这种
19、方法的明显缺陷是：它极度不安全，所以请不要这么做！举例来说，假设有个攻击者观察到一条已经被签名的消息，消息开头是“1111.。.”。现在攻击者想要在不破坏签名的情况下，将消息编辑成“0000.。.”，只需要删掉这条签名中的几个组成部分即可！简言之，虽然要将 0 位元“翻转” 成 1 位元很困难，但反之要将 1 换成 0 就非常简单了。现在有了个解决办法，而且它非常巧妙。让我们接着瞧瞧。虽然无法避免攻击者将消息中的 1 改成 0 ，但我们能发现这些改动。只要将一个简单的“校验和（checksum）”附加到消息上，然后将消息和校验和一起签名。对于签名验证者来说，她必须验证整份签名的两个值，也需要确
20、定收到的校验和是正确的。我们使用的校验和非常小：它由简单的二进制整数组成，表示原始消息中的所有 0 位元数。如果攻击者试图修改消息内容（或是校验和），使得部分 1 位元变成 0 位元，并没有手段可以阻止她。但是这种攻击会增加消息中的 0 位元数，这会使得校验和无效，验证者从而会拒绝这个签名。当然，机智的攻击者可能还会试图混淆校验和（校验和也和消息一起被签名），增加校验和的整数值来匹配她篡改的位元数。然而最关键的是，因为校验和是二进制整数，如果要增加校验和的值，攻击者势必得将一些 0 位元转换成 1 位元。又因为校验和也被签过名，这种签名方法从源头阻止这种转换（将 0 换成 1），因此攻击者无法得逞。（如果你继续记录下去，的确会增加被签名的“消息”的大小。在我们的例子中，一条 256 位的消息的校验和，需要额外的 8 位元及增加相应的签名成本。不过，如果这条消息包含许多 0 位元，这么做对于缩减签名大小仍然非常有效。）