PDF物联网、TLS 和真随机数生成器在现实世界中的挑战
不良随机数仍然存在于现代系统中，并且正在激增。
詹姆斯·P·休斯，惠特菲尔德·迪菲
物联网 (Internet of things) 现在是互联网的一级成员，与云基础设施通信。随之而来的是额外的要求，以确保每个客户数据的保密性、完整性和身份验证。IETF TLS（传输层安全）协议几乎用于所有互联网流量安全，但 TLS 并不像公众认为的那么安全。当前的 TLS协议已被证明是安全的，但物联网实现是否能兑现这一承诺？物联网并不总能像服务器、笔记本电脑甚至手机处理器那样，拥有硬件 RNG（随机数生成器）或其他功能。对 RNG 的历史记录表明，RNG 并非总是像预期的那样随机，这引发了这个问题。
TLS 并没有让事情变得容易。它使用了脆弱的结构，例如 DSA（数字签名算法）、RSA（Rivest-Shamir-Adleman）和 GCM（Galois/CounterMode），如果随机数不是完全随机的，则协议本身会在许多方面失效。NIST（国家标准与技术研究院）和其他机构已经创建了构建、测试和标准化 RNG 的标准。这些标准已在开源项目中实施，这些项目已将这些工具提供给社区，但是即使在使用标准化的开源库时，RNG 也可能存在问题。程序员并非完全应该受到责备。
密码学界的许多人嘲笑在实现 RNG 时犯下的错误。许多密码学家和 IETF 成员抵制使 TLS 更能抵抗此类故障的呼吁。本文讨论了 TLS 协议的历史、现状和脆弱性，并以一个如何改进协议的示例结尾。目标不是提出解决方案，而是发起一场对话，通过证明在不假设完美随机数的情况下 TLS 的安全性是可能的，从而使 TLS 更具弹性。
一项成熟的标准
TLS 是大多数通过互联网通信的应用程序首选的安全通信协议。TLS 成熟可靠，经过充分分析并有安全证明，并且有多个可互操作的开源实现。选择 TLS 无疑比创建专有密码协议的风险要小。
然而，在实现使用 TLS 的安全通信方面，物联网却存在缺陷。物联网运行在低成本处理器上，这些处理器缺乏处理能力以及大型处理器上常见的许多标准硬件安全功能。物联网流量使用 TLS，这是一种脆弱的协议，如果随机数不是完全随机的，则会灾难性地失败。物联网开发人员可能不愿意或无法测试随机数是否随机并正确地传递给 TLS 实现。著名的供应商拥有专门关注这些问题的全职员工团队，但几乎没有物联网供应商能够负担得起这种奢侈。
物联网供应商通常利用开源 TLS 软件，但这还不够。最近一项针对往返加州大学圣克鲁兹分校的 TLS 流量使用的随机数进行的为期两年的调查发现，惊人数量的实现由于与随机数的生成和处理相关的编程错误而无法为其客户提供任何安全性。14
物联网处理器
与典型的台式机、服务器甚至手机处理器相比，物联网需要低成本和低功耗的处理器。低成本能够开拓市场，不容忽视，但低成本意味着更低的性能和更少的功能。这些差异可能会显着影响 TLS 的实现。更低的功耗意味着电池续航时间更长。
然而，物联网供应商选择低成本处理器并不能成为供应商不实施足够安全措施的借口。
较便宜的处理器可能缺少安全飞地和基于硬件的 TRNG（真随机数生成器），而软件需要这些功能。没有安全飞地意味着软件必须找到保护私钥和物联网系统需要的其他机密的方法。如果设备丢失、被盗或被丢弃，没有这种保护可能会导致问题。没有 TRNG 的较便宜的处理器需要软件找到熵，测量熵，并确保它可靠地传达给 TLS 层。即使处理器具有 TRNG，也必须将该熵可靠地传达给 TLS 层。
这些问题可以在软件中解决，并且必须完美解决才能为客户提供安全性。没有误差的余地。
脆弱的密码协议
即使没有明确声明这些假设，具有更多或更强假设的算法也被认为是更“脆弱”的。具有更少或更弱假设的算法被认为是更“健壮”的。许多算法在随机数方面都很脆弱，包括 DSA、ECDSA（椭圆曲线数字签名算法5、RSA15 和 GCM4。即使是不脆弱的算法，如果 CSPRNG（密码学安全伪随机数生成器）没有用足够的熵进行播种，也会创建容易被发现的密钥，因为任何两个 TLS 会话都可以为密钥和 nonce 拥有相同的随机数。14
您可能希望易受攻击的流量不会被注意到，但 TLS 协议使查找不安全的实现变得轻而易举，因为该协议将原始随机数直接放入协议中。两次看到相同的 32 字节数字强烈表明 RNG 未正确播种，并且来自该实现的流量是不安全的。
TLS 使查找具有相同实现的多个设备变得简单直接。由于 TLS 实现有如此多的选项可用，因此任何两个实现使用相同选项集的概率都非常小。Zeek JA3 插件1 对选项进行哈希处理，以便能够可靠地对实现进行指纹识别。
测试
测试标准软件很简单，因为如果程序运行两次，它将输出相同的答案。当需要随机数时，软件的确定性行为就会消失。实施者需要测试数字是否随机，以及这些数字是否已传达给 TLS。
NIST 制定了随机数生成和单元测试的标准。2,20 单元测试算法至关重要，但作为系统测试是不够的。播种、随机数如何传递到 TLS 甚至 TLS 如何使用这些数字仍然可能出现问题。系统测试 TLS 需要分析实际的线路协议，以确保 ClientHello 随机值的随机性。
历史
不安全的 RNG 威胁着 TLS 的安全性。有意不安全的 RNG 通常用于创建带有后门的系统，也称为秘密后门。无意不安全的随机数是由在实现已知的正确 RNG 或实现没有完美熵的自定义 RNG 时，简单的编程错误引起的。
有意不安全的 RNG 已被发现并公开。一家名为 Crypto AG 的公司自 1970 年代开始生产的设备使用了一种随机数算法，“该算法由 NSA 创建，因此可以解密该机器加密的任何消息”。19 最近，“NSA 对 Dual EC [随机数生成器] 的后门是削弱密码学标准的有组织方法的一部分”。3 这些系统已被关闭。
无意不安全的 RNG 可能比有意不安全的 RNG 更糟糕。不安全的 RNG 可能会使产品执行某些敏感功能，从而允许任何知道缺陷的人恢复数据。无意不安全的 RNG 的一个例子是使用不良随机数来创建 RSA 密钥。当发现不安全的实现时，供应商可能已经倒闭，或者更糟糕的是，他们不愿意或无法修复其设备。开源项目可能会被其原始开发人员放弃，但它们继续存在。一些组织将有意继续向毫无戒心的公众提供其不安全的产品。
一种无意不安全的 RNG 已经影响了使用 RSA 的物联网设备超过 10 年，但它仍在继续增长。从 2012 年 2 月《纽约时报》上的一篇文章开始，18 一系列学术论文记录了 RSA 在随机数不完美的情况下是脆弱的，并且情况正在变得更糟，而不是更好
- 2012 年 – 研究人员发现，“在我们收集的每千个 RSA 模数中，有两个不提供任何安全性”，这是由 RSA 私钥不是随机的引起的。对已知的公钥运行 GCD（最大公约数），导致破解了这些密钥中的 26,965 个。17 根本原因是“Linux 随机数生成器中的启动时熵漏洞”。13
- 2016 年 – 易受攻击的机器数量激增至“超过 313,000 个密钥容易受到该缺陷的影响”，并且“许多供应商似乎从未发布补丁”。12
- 2019 年 – 泄露的密钥数量上升到 435,000 多个。大多数新的易受攻击的密钥归因于物联网设备。“由于这些物联网设备存在于敏感环境中，因此它们的广泛易感性对公众构成了潜在风险。”15
可以构建安全的 RNG。许多关于安全 RNG 的论文、标准和开源实现已经发布，但工程师仍然会犯错。“事实上，似乎工程师无法做对，并且这已成为密码学中的一个严重问题。”7 当密码学家听到他们的安全性的理论证明是通过使用不安全的随机数来实现时，他们的评论通常等同于“不是我的问题”，并且他们经常贬低工程师是马虎的。
密码学家使用公共随机数来显示“新鲜度”。这确保了对话不会重播旧消息或密文。公共随机数使密码学家的安全性证明更容易，从而将“责任推给”工程师。
考虑一下弗雷德里克·布鲁克斯在他 1975 年的经典著作《人月神话》6 中称之为“工艺的悲哀”中对软件工程的评论：
然而，并非一切都是快乐的，了解固有的悲哀使人们在它们出现时更容易忍受。
首先，必须完美地执行。在这方面，计算机也类似于传说的魔力。如果咒语中的一个字符、一个停顿不是严格按照正确的形式，魔术就不会起作用。人类不习惯完美，也很少有人类活动要求完美。我认为，适应对完美的要求是学习编程最困难的部分。
在许多方面，密码学被认为是魔法。学术密码学家可以使用完美的随机数来创建他们的咒语，但是当事情出错时，他们不应该责怪工程师。实用密码学家应该承认并非所有程序员都是完美的，并在随机数完美时调整他们的协议以获得相同或更好的安全性，同时在随机数不完美时不会出现灾难性的失败。
当前状态
最近，焦点集中在 TLS 协议公开使用的随机数上，以回答有关这些随机数质量的问题。14 设计 SSL（安全套接字层）的密码学家选择使用公共 nonce，以确保连接是新鲜的，而不是旧的流量被重放。SSL 和现在的 TLS 使用两个 32 字节的 nonce，称为 ClientHello 和 ServerHello 随机值。这些数字以明文形式发送，因为没有理由隐藏连接是新鲜的。
在随机数是随机的完美世界中，这些数字与过去或将来使用的数字没有任何关系。在完美的世界中，两次看到相同的 ClientHello 或 ServerHello 随机值的概率非常小，并且基于生日问题，10 该问题指出，在我们看到 n 个值后，来自总体 H 的随机数没有重复的概率为
在您看到 n 个值后，来自总体 H 的随机数至少有一个重复的概率只是上面没有发生的概率。
在看到 10 亿个 Hello 随机值后，找到单个重复数字的概率为 1.85×10−50。以小数点后 50 个零开头的概率与某人连续七次赢得英国国家彩票头奖一样不可能。我们发现了 29,884 个不同的 Hello 随机值，每个值都出现了两次或更多次。大多数实现是物联网级设备，本文总结了其中的一些。
您可能会想，“如果这些证明新鲜度的数字不是完全随机的，那又怎样”，但是这样的说法会忘记这些公共数字来自与密钥材料相同的生成器。如果公共随机数在现实世界中不是完全随机的，那么密钥材料也不是随机的，因为它们来自相同的生成器。对密钥材料的任何洞察力都对数据的隐私构成重大威胁。
卡死实现
由常量播种的 RNG 的实现对于 ClientHello 随机值表现出单个随机数。这些被称为“卡死”RNG。这些系统在每个 TLS 会话开始时播种其 RNG，但它们不添加任何熵。他们可能有一个完美的 RNG，但他们在没有任何熵的情况下重复生成相同的数字。协议使用的密钥值和公开的公共随机数将是恒定的。
例如，如果 ClientHello 随机值为
ad100cbcdb10a926acd41f7214d392887472dff54cbd720481b63e15
被检测到，可能发生了两件事：首先，这是一个使用 CyaSSL 库11 的设备。算法的播种如图 1 所示（代码直接从 CyaSSL 文件 cyassl/ctaocrypt/src/random.c 中复制）。此代码重复四次，并用作四组硬件的占位符。
图 1 来自 CyaSSL 的 GenerateSeed
其次，会话密钥是恒定的并且易于恢复。在这种情况下，TLS 会话没有为流量提供任何安全性。至少发现有三个 TLS 实现存在此特定问题。
在第二个不安全的 TLS 实现示例中，发现了重复的值，如表 1 所示。重复值表显示，最常见的重复值没有尾随 0，并且数据中已出现每个可能的尾随字节数为 0 的情况，包括全 0 值。有趣的是，此数据基于卡死值，但唯一的随机性是有多少字节被复制到 TLS ClientHello 随机值中。令人担忧的是，此实现使用的密钥也可能是恒定的或只有少量可能的值。
表 1 重复值表
图 2 显示了 STS（站到站）协议，该协议扩展了基本的 D-H（Diffie-Hellman）协议8 以验证端点并防止 MITM（中间人）攻击。
图 2 可视化的 Google 碰撞
低熵
不安全的 TLS 实现的第三个示例是物联网设备，它可能是基于 Google Assistant 的设备，因为它与 Google 服务器进行通信。重复的随机数在图 3 中可视化，显示了从 2021 年 1 月 15 日格林威治标准时间下午 6 点开始的四个小时数据子集中的 Google 碰撞。该图显示了一个服务器（蓝色椭圆形）和两个客户端实现（绿色椭圆形）。这些实现复制了随机数（红色椭圆形）。这可能是一个或多个具有相同缺陷的设备。
图 3 站到站认证密钥协商协议
来自此设备的大约 80% 的连接是重复的随机数，并且很可能容易受到攻击。尚未确定实际设备，但 Google 已请求帮助查找和识别此设备。
TLS 是一种脆弱的密码协议
TLS 是电子商务和互联网上绝大多数安全通信的核心，但在对不太完美的随机数的弹性方面却有所不足。构成 TLS 的算法是脆弱的：DSA 和 ECDSA 如果它们使用的随机数即使略微不随机，也会泄漏其密钥材料。5 DSA 的替代方案是 RSA，但当随机数不完美时，RSA 也存在问题。17 使用最广泛的加密模式 GCM，如果对称密钥和 nonce 重复，则会失败。4
这些失败是真实存在的，并且可能对使用具有不完美 RNG 的软件或物联网设备的个人造成灾难性后果。这些问题已经存在了几十年，并且已经进行了讨论和提案，但没有任何措施。TLS 可以借鉴传统的网络安全技术并采用纵深防御，但似乎每次又发现一个糟糕的 RNG 时，答案都是修复 RNG，而不是费心使协议更能抵抗不良随机数。
实现指纹识别
TLS 使查找不良随机数变得容易，原因有多种。首先也是最重要的是对 ClientHello 随机值的要求。TLS 本质上暴露了实现，因为选项未加密，并且选项组合的数量允许通过简单地哈希选项来高保真地对实现进行指纹识别。1
以高保真度确定 TLS 实现可以帮助查找恶意软件命令和控制网络。它对于查找不良 RNG 也很有价值。使不良 RNG 可发现对于寻找它们的安全研究人员来说是合适的，但对于利用这些问题的组织也很有价值。没有任何文件表明以高保真度识别实现是 TLS 想要提供的功能。
站到站协议
自从 1976 年《密码学新方向》8 出版以来，密码学家一直在设计协议来解决新鲜度问题，确保 MITM 和重放攻击是不可能的。自 1995 年至少 SSL 2.0 以来，TLS 一直使用公共 ClientHello 随机值来解决此问题，但当时，这不是唯一已知的方法。
1992 年，在第一个 SSL 版本发布前几年，作者之一（Diffie）在“身份验证和认证密钥交换”9 中描述了新鲜度问题的解决方案，该解决方案建立在可追溯到 1980 年代后期的安全电话工作之上。在这种设计中，随机值不是以明文形式发送的。该协议使用 RNG 创建临时私钥，交换临时公钥。临时密钥的新鲜度提供了 STS 协议的新鲜度。
该协议从系统参数、生成器 g、模数、Alice 的 A 和 Bob 的 B 公共签名密钥 sA 和 sB 开始。Alice 创建一个临时私钥 x 并计算临时公钥 X = gx。Alice 将临时公钥 X 发送给 Bob。然后 Bob 也这样做，创建 y。Bob 现在拥有计算共享密钥 K 所需的信息。Bob 签署值 (Y,X)，然后使用共享密钥 K 对其进行加密。然后 Bob 发送 Y 和 CB。Alice 现在拥有计算 K、解密 CB 和验证 Bob 签名所需的内容。Alice 现在知道她正在与 Bob 交谈。Alice 现在可以计算 CA 并将其发送给 Bob。最后，Bob 通过使用 K 解密 CA 并检查 Alice 的签名来验证他是否正在与 Alice 交谈，认证密钥交换完成。
Naxos–TLS
图 4 提出了现有 TLS 协议的替代方案。Naxos–TLS 协议扩展了 STS 和 Naxos16 协议，以宣布客户端想要连接的证书、交换证书和选项。客户端证书和客户端 TLS 选项以保密方式传输，以便只有 A 才能知道谁在连接，并且被动监控无法确定实现。
图 4 NAXOS–TLS 密钥协商协议
该协议并非旨在成为完整的提案，而是一个起点，以表明可以解决 TLS 的两个漏洞——ClientHello 随机值和客户端的高保真指纹识别。如果客户端的 RNG 没有完全熵，则还有其他对策。
该协议以 STS 开始，并通过创建会话临时密钥 ekA ← {0,1}λ 来利用 Naxos 协议16。然后，Alice 将长期密钥 skA 与此会话的临时密钥 ekA 进行哈希运算，以形成会话的私钥 x 。Alice 缓存（
H1(skA,ekA) 符号）x 以供稍后使用。
Naxos 的优势在于，如果临时密钥 ekA 没有任何熵，则会话将失去 PFS（完美前向保密）。失去 PFS 并不好，但这比失去隐私要好。服务器比客户端更有可能失去 PFS，因为我们的研究发现，服务器往往是更大、功能更强大的系统，它们不像物联网客户端那样存在随机数问题。Alice 将会话公钥 X = gX 以及服务器的 TLS 选项和证书 (optA,certA) 发送给 Bob。
Bob 现在拥有 Alice 的身份 A 和公钥 pkA。与 Alice 类似，Bob 创建了他的会话临时密钥 ekB ← {0,1}λ。协议开始在这里分歧。Bob 通过 y 创建并缓存了他的会话私钥，将 Alice 的公共值 H1(skB,ekB,X)X 添加到哈希中。将值 X 添加到哈希不会增加 y 的熵，因为攻击者已知 X。但是，如果 ekB 的熵不足，则将 X 添加到哈希将掩盖攻击者知道的事实。Bob 将会话公钥 Y = gy 发送给服务器。
TLS 存在客户端实现可以被轻易指纹识别的漏洞，并且如果使用客户端证书，则会发现客户端的身份。为了隐藏客户端证书，TLS 当前执行完全未经身份验证的密钥交换（这会泄漏实现），然后进行密钥重新协商（不需要的复杂性）。加密这些值会更简单。在 Naxos–TLS 中，Bob 计算一个密钥，该密钥已通过身份验证并且对 Alice 是私有的，但仍包含 Bob 的熵和新鲜度保证。
K1 = H2(Xy,pkyA,A)
此密钥具有服务器和客户端的完整熵，但不验证 Bob 的身份。然后 Bob 将他加密的身份和 TLS 选项发送给 Alice。
C1 = eK1 (certB,optB)
加密应使用组合的加密认证模式，该模式不易受到低熵密钥或 nonce 的攻击。4 消息 C1 不会泄漏 Bob 身份的实现。
收到 C1 后，只有 Alice 可以计算
K1 = H2(Yx,YskB,A)
因为她是唯一知道 skB 的另一个人。解密 C1 为 Alice 提供了 Bob B 的身份和 Bob 的公钥 pkB。Alice 知道连接是新鲜的，因为她的 ekA 的熵。
Bob 计算出会话密钥为
K = H2(Xy,XskB,pkyA,A,B)
Alice 也可以计算出会话密钥。
K = H2(Yx,pkxB,YskA,A,B)
最后两条消息 CA 和 CB 证明 Alice 和 Bob 都知道 K。Naxos-TLS 协议比 TLS 更简单，使用的算法更少，并且对低熵随机数的容忍度更高，使其比今天的 TLS 更健壮且更不易出错。2021 年的论文“BadRandom：TLS 中低熵随机数的影响和缓解措施”14 提供了有关此协议的更多详细信息。
结论
不良随机数不是过去的事情；它们在当今部署的系统中是地方性的并且正在激增。随机数正确生成很复杂，物联网制造商面临的压力并没有使其更容易。TLS 协议对不太完美的随机数的脆弱性是密码学家假设随机数很容易正确获取，并且既没有花费时间也没有努力分析，更不用说容纳具有不太完美随机数的系统而造成的缺陷。
如此处所示，可以通过多种方式使 TLS 更加安全：新鲜度不需要原始随机数，并且允许对手分析 RNG。以高保真度对实现进行指纹识别的非目标对依赖 TLS 的个人没有价值，但对于攻击者查找不安全的实现却非常宝贵。TLS 不容纳不太完美的随机数，并且对协议进行简单更改以添加服务器的熵将为客户端提供一些保护，以防他们的随机数不完美。
乐观主义者希望这将引发关于如何使 TLS 更加健壮或考虑缓解不太完美的客户端 RNG 的讨论。TLS 是一种重要的协议，可以更容易使用。使 TLS 更加健壮将导致互联网上更高水平的安全性。
参考文献
1. Althouse, J. 2019. 使用 JA3 和 JA3S 进行 TLS 指纹识别。Salesforce 工程； https://engineering.salesforce.com/tls-fingerprinting-with-ja3-and-ja3s-247362855967。
2. Barker, E.B., Kelsey, J.M., et al. 2007. 使用确定性随机位生成器的随机数生成建议（修订版）。美国商务部国家标准与技术研究院； https://www.nist.gov/publications/recommendation-random-number-generation-using-deterministic-random-bit-generators-2。
3. Bernstein, D.J., Lange, T., Niederhagen, R. 2016. Dual EC：标准化的后门。在计算机科学讲义论文集，《新密码破译者》，第 9100 卷，P.Y.A. Ryan, D. Naccache, 和 J.-J. Quisquater 编辑，256–281。施普林格出版社； https://dl.acm.org/doi/abs/10.1007/978-3-662-49301-4_17。
4. Böck, H., Zauner, A., Devlin, S., Somorovsky, J., Jovanovic, P. 2016. 不尊重 nonce 的攻击者：对 TLS 中 GCM 的实际伪造攻击。在第 10 届 Usenix 进攻性技术研讨会； https://www.usenix.org/conference/woot16/workshop-program/presentation/bock。
5. Breitner, J., Heninger, N. 2019. 有偏差的 nonce 意识：针对加密货币中弱 ECDSA 签名的格密码攻击。在第 23 届金融密码学和数据安全国际会议论文集，I. Godberg 和 T. Moore 编辑，3-20。施普林格国际； https://www.springerprofessional.de/en/biased-nonce-sense-lattice-attacks-against-weak-ecdsa-signatures/17265526。
6. Brooks Jr., F.P. 1995. 人月神话：软件工程论文集。艾迪生-韦斯利专业版。
7. Courtois, N.T., Hulme, D., Hussain, K., Gawinecki, J.A., Grajek, M. 2013. 关于不良随机性和克隆非接触式支付和建筑智能卡。在IEEE 安全与隐私研讨会论文集。IEEE，105–110； https://dl.acm.org/doi/10.1109/SPW.2013.29。
8. Diffie, W., Hellman, M. 1976. 密码学新方向。IEEE 信息论汇刊 22(6), 644–654； https://ee.stanford.edu/~hellman/publications/24.pdf。
9. Diffie, W., Van Oorschot, P.C. Wiener, M.J. 1992. 身份验证和认证密钥交换。设计、代码和密码学 2(2), 107–125； https://dl.acm.org/doi/10.1007/BF00124891。
10. Flajolet, P., Odlyzko, A.M. 1989. 随机映射统计。在密码技术理论与应用研讨会论文集，329–354。施普林格； https://dl.acm.org/doi/10.5555/111563.111596。
11. Garske, D. 2021. 弃用 CyaSSL 库 #151。GitHub； https://github.com/cyassl/cyassl/pull/151。
12. Hastings, M., Fried, J., Heninger, N. 2016. 弱密钥在网络设备中仍然很普遍。在互联网测量会议论文集，49–63； https://dl.acm.org/doi/10.1145/2987443.2987486。
13. Heninger, N., Durumeric, Z., Wustrow, E., Halderman, J.A. 2012. 挖掘您的 Ps 和 Qs：检测网络设备中广泛存在的弱密钥。在第 21 届 Usenix 安全研讨会论文集，35； https://dl.acm.org/doi/10.5555/2362793.2362828。
14. Hughes, J.P. 2021. BadRandom：TLS 中低熵随机数的影响和缓解措施。博士论文。加州大学圣克鲁兹分校； https://escholarship.org/uc/item/9528885m。
15. Kilgallin, J., Vasko, R. 2019. 物联网时代 RSA 密钥的分解。在第一届 IEEE 智能系统与应用信任、隐私和安全国际会议 (TPS-ISA) 论文集，184–189。IEEE； https://ieeexplore.ieee.org/document/9014350。
16. LaMacchia, B., Lauter, K., Mityagin, A. 2007. 更强大的认证密钥交换安全性。在国际可证明安全会议论文集，1-16。施普林格； https://link.springer.com/chapter/10.1007/978-3-540-75670-5_1。
17. Lenstra, A.K., Hughes, J.P., Augier, M., Bos, J.W., Kleinjung, T., Wachter, C. 2012. 公钥。在第 32 届密码学进展年度会议论文集，626–642。施普林格； https://dl.acm.org/doi/10.1007/978-3-642-32009-5_37。
18. Markoff, J. 2012. 在线加密方法中发现缺陷。纽约时报（1 月 14 日）； https://www.nytimes.com/2012/02/15/technology/researchers-find-flaw-in-an-online-encryption-method.html。
19. Paul, J.D. 2021. 最后一款转子密码机的丑闻历史。IEEE Spectrum； https://spectrum.ieee.org/the-scandalous-history-of-the-last-rotor-cipher-machine。
20. Turan, M.S., Barker, E., Kelsey, J., McKay, K.A., Baish, M.L., Boyle, M., et al. 2018. 用于随机位生成的熵源建议。NIST 特别出版物 800-90B。美国商务部国家标准与技术研究院； https://csrc.nist.gov/publications/detail/sp/800-90b/final。
詹姆斯·P·休斯（James P. Hughes） 在存储、网络和密码学领域拥有职业生涯，并拥有超过 50 项专利。他于 2021 年在加州大学圣克鲁兹分校获得博士学位。
惠特菲尔德·迪菲（Whitfield Diffie） 最著名的是在 1970 年代初期开创了公钥密码学。在他 1976 年与马丁·赫尔曼合著的论文《密码学新方向》发表之前，加密技术主要由政府部门掌握。公钥密码学和迪菲-赫尔曼密钥协商协议使密码学能够扩展到互联网，并彻底改变了安全领域。因为这项工作，迪菲和赫尔曼于 2015 年共同获得了 图灵奖。迪菲是美国国家工程院院士、英国皇家学会外籍院士，并于 2020 年入选美国国家安全局密码学名人堂。
版权 © 2022 归所有者/作者所有。出版权已授权给 。
最初发表于《Queue》杂志第 20 卷第 3 期—
在 数字图书馆 中评论本文
更多相关文章
凯瑟琳·海耶斯，大卫·马龙 - 质疑评估非加密哈希函数的标准
尽管加密和非加密哈希函数无处不在，但在它们的设计方式上似乎存在差距。针对各种安全需求，存在许多用于加密哈希的标准，但在非加密方面，存在一定的传统，尽管哈希函数历史悠久，但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义，但当面对具有特定模式的数据集时，这可能是一个挑战。
妮可·福斯格伦，艾里妮·卡利亚姆瓦库，阿比·野田，米凯拉·格雷勒，布赖恩·豪克，玛格丽特-安妮·斯托里 - DevEx 在行动
DevEx（开发者体验）在许多软件组织中越来越受到关注，因为领导者们试图在财政紧缩和人工智能等变革性技术的背景下优化软件交付。直观地看，技术领导者普遍认为良好的开发者体验能够提高软件交付效率和开发者幸福感。然而，在许多组织中，旨在改进 DevEx 的拟议举措和投资难以获得支持，因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉尧，安东尼奥·特里戈，米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示实验室实验的结果，为该主题提供新的见解。这些实验使用基于代码、低代码和超低代码技术进行，以研究生产力方面的差异。低代码技术已明确显示出更高的生产力水平，为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性以及未来研究的机会。
伊瓦尔·雅各布森，阿利斯泰尔·科伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界，其中新的工具、技术和技巧不断被开发出来以服务于商业和社会，但它也很健忘。在其快速前进的匆忙中，它容易受到时尚潮流的影响，并且可能会忘记或忽略针对其面临的一些永恒问题的成熟解决方案。用例，最早于 1986 年引入并在后来普及，就是这些成熟的解决方案之一。
© 公司，版权所有。