我足足准备了两周时间，终于在圆桌的最后一天准备完回答这道题所有的相关资料了。我想在这个回答里介绍两个应用。这两个应用既涉及到相对比较前沿的现代密码学技术，又和我们的生活息息相关。

应用隐私集合求交（PSI）实现口令泄露检查

“用户名和密码”这种描述已经成为了一种惯用表示。实际上，这里的密码指的不是密码学，而是口令（password）。虽然后面读起来可能有些奇怪，但我还是用“口令”这个术语，以便和“密码学”这个术语区分开。

当前各个网站都会希望用户进行注册，此时我们不可避免地需要为网站选一个用户名（username）和口令（password）。为了方便，相信很多知友会统一使用一个用户名和口令来登录大多数网站。我们来设想这样一个场景：如果某个网站没有做好安全保护，导致存储用户名和口令的数据库被黑客拖库，那黑客就可以在其他网站上尝试使用相同的用户名和口令登录。

为了解决这个问题，谷歌于 2019 年 2 月 5 日在谷歌的 Chrome 浏览器应用市场上发布了口令检查器（Password Checkup）扩展插件。谷歌也同步发表了博客文章《应用口令检查器保护你的账户不因数据泄露而遭到入侵》（Protect Your Accounts from Data Breaches），通俗易懂地解释了扩展插件的设计原则。后续，谷歌在 2019 年 12 月 10 日发表的另一篇博客文章《更好的 Chrome 口令保护：工作原理》（Better Password Protection in Chrome - How It Works）中宣布将此功能完全集成在 Chrome 浏览器中（不过原来的扩展插件也一并下线了）。现在，我们可以使用 Chrome 浏览器“Google 密码管理工具”中的“检查”功能来检查口令是否已被泄露。我自己尝试了一下，确实有很多口令已经被泄露了。

我这里给出《应用口令检查器保护你的账户不因数据泄露而遭到入侵》的译文。我们可以通过这篇博客了解口令检查器的设计原则和大致工作原理。

Google helps keep your account safe from hijacking with a defense in depth strategy that spans prevention, detection, and mitigation. As part of this, we regularly reset the passwords of Google accounts affected by third-party data breaches in the event of password reuse. This strategy has helped us protect over 110 million users in the last two years alone. Without these safety measures, users would be at ten times the risk of account hijacking.

谷歌通过设立横跨预防、检测和缓解的全阶段深度防御策略来帮助您的账户免受劫持。考虑到口令可能会被重用，我们会定期重置因第三方数据泄露而不再安全的谷歌账户口令。仅在过去两年，这一策略就帮助我们帮助了超过 1.1 亿位用户。如果没有这些安全措施，用户账户被劫持的风险将增加十倍。

We want to help you stay safe not just on Google, but elsewhere on the web as well. This is where the new Password Checkup Chrome extension can help. Whenever you sign in to a site, Password Checkup will trigger a warning if the username and password you use is one of over 4 billion credentials that Google knows to be unsafe.

我们希望您不仅在谷歌上保持安全，在网络的其他地方也能保持安全。这就是新的“口令检查器 Chrome 扩展插件”所能提供的帮助。谷歌已经收集了超过 40 亿个不安全的凭据。当你登录一个网站时，如果你使用的用户名和口令位于这些凭据之中，则口令检查器就会出发一个警告。

Password Checkup was designed jointly with cryptography experts at Stanford University to ensure that Google never learns your username or password, and that any breach data stays safe from wider exposure. Since Password Checkup is an early experiment, we’re sharing the technical details behind our privacy preserving protocol to be transparent about how we keep your data secure.

口令检查器是谷歌与斯坦福大学的密码学专家共同设计完成的。我们要确保谷歌永远不会知道你的用户名或口令，并且任何已泄露的数据仍然是安全的，其曝光程度不会进一步增加。口令检查器是一个早期的实验。我们将分享我们隐私保护协议背后的技术细节，以帮助用户更透明地了解我们如何保护您的数据安全。

We designed Password Checkup with three key principles in mind:
- Alerts are actionable, not informational: We believe that an alert should provide concise and accurate security advice. For an unsafe account, that means resetting your password. While it’s possible for data breaches to expose other personal data such as a phone number or mailing address, there’s no straightforward next step to re-securing that data. That’s why we focus only on warning you about unsafe usernames and passwords.
- Privacy is at the heart of our design: Your usernames and passwords are incredibly sensitive. We designed Password Checkup with privacy-preserving technologies to never reveal this personal information to Google. We also designed Password Checkup to prevent an attacker from abusing Password Checkup to reveal unsafe usernames and passwords. Finally, all statistics reported by the extension are anonymous. These metrics include the number of lookups that surface an unsafe credential, whether an alert leads to a password change, and the web domain involved for improving site compatibility.
- Advice that avoids fatigue: We designed Password Checkup to only alert you when all of the information necessary to access your account has fallen into the hands of an attacker. We won’t bother you about outdated passwords you’ve already reset or merely weak passwords like “123456”. We only generate an alert when both your current username and password appear in a breach, as that poses the greatest risk.

我们在设计口令检查器时考虑了三个关键原则：

• 告警必须具有可操作性，而不是只有提示性：我们认为告警应该提供简明且准确的安全建议。对于一个已不安全的账户来说，我们的建议是请您的重置口令。虽然数据泄露可能会暴露电话号码、邮寄地址等其他个人数据，但没有很简单易行的方法可以重新保护这类数据。这就是我们为什么只对不安全的用户名和口令发起告警的原因。
• 隐私是我们设计的核心：您的用户名和口令都非常敏感。我们使用隐私保护技术来设计口令检查器，确保永远不会将这些信息泄露给谷歌。我们的设计还可以防止攻击者反过来通过滥用口令检查器来获取不安全的用户名和口令。扩展插件报告的统计信息都是匿名收集的。收集的信息包括查找不安全凭据的次数、告警是否引发口令修改操作、以及改善站点兼容性所涉及的 Web 域。
• 给出不会感到疲劳的建议：只有当访问您账户所需的所有信息都落入攻击者手中时，我们设计的口令检查器才会给出告警。我们不会因为您设置过期的口令、或者设置像“123456”这样的口令而打扰您。只有当您的用户名和口令均已被泄露时，我们才会生成告警，因为这种情况的风险已经达到最大。

At a high level, Password Checkup needs to query Google about the breach status of a username and password without revealing the information queried. At the same time, we need to ensure that no information about other unsafe usernames or passwords leaks in the process, and that brute force guessing is not an option. Password Checkup addresses all of these requirements by using multiple rounds of hashing, k-anonymity, and private set intersection with blinding.

从宏观层面看，口令检查器需要向谷歌查询用户名和口令的泄露状态，但不能泄露所查询的信息。同时，我们需要保证此过程不会泄露其它不安全用户名或口令的相关信息，且攻击者无法通过穷举方法实施攻击。口令检查器通过使用多轮哈希、k- 匿名性、盲化隐私集合求交来满足这些要求。

Our approach strikes a balance between privacy, computation overhead, and network latency. While single-party private information retrieval (PIR) and 1-out-of-N oblivious transfer solve some of our requirements, the communication overhead involved for a database of over 4 billion records is presently intractable. Alternatively, k-party PIR and hardware enclaves present efficient alternatives, but they require user trust in schemes that are not widely deployed yet in practice. For k-party PIR, there is a risk of collusion; for enclaves, there is a risk of hardware vulnerabilities and side-channels.

我们的方法在隐私性、计算开销、网络延迟之前取得了平衡。虽然单服务端隐私信息检索（PIR）和 N 选 1 不经意传输也能解决我们的部分需求，但由于服务端的数据库包含超过 40 亿条数据项，因此这些方案引入的通信开销过大。另外，k 服务端 PIR 和硬件可信执行环境可以提供高效的替代方案，但他们需要用户信任尚未在实践中得到广泛部署的方案。对于 k 服务端 PIR 来说，存在服务端共谋的风险；对于可信执行环境来说，存在硬件漏洞和侧信道攻击的风险。

Here’s how Password Checkup works in practice to satisfy our security and privacy requirements.

以下是口令检查器在实际中的工作原理。这也解释了口令检查器为何能满足我们的安全性和隐私性要求。

1. 每当谷歌发现一组用户名和口令因数据泄露而被暴露时，我们就会存储一份强哈希和加密的数据副本。
2. 当你登录到一个你使用的网站时，密码检查器将向谷歌发送你用户名和口令的强哈希和加密数据副本。这将保证谷歌永远不会知道你账户的详细信息。
3. 在此过程中，我们使用盲化隐私集合求交来搜索每个不安全的用户名和口令，同时不泄露您或其他人的账户详细信息。
4. 您将完全在您的本地检查您的用户名和口令是否已被泄露。如果您的账户信息已被暴露，您应该立即更改口令。

Password Checkup is currently available as an extension for Chrome. Since this is a first version, we will continue refining it over the coming months, including improving site compatibility and username and password field detection.

当前，口令检查器是一个 Chrome 扩展插件。这只是第一个版本，我们将在未来几个月内继续完善，例如改进网站兼容性、发现用户名和口令字段等。

从现代密码学角度看，口令检查器使用了隐私集合求交（Private Set Intersection，PSI）实现泄露口令匹配功能。简单来说，谷歌把所有已泄露的口令看成一个集合

，把用户使用的口令看成一个集合

，如果两个集合有交集（即

），那就意味着用户使用的口令位于已泄露的口令集合之中。使用 PSI 协议可以做到仅让用户得知求交结果，且双方均无法获得有关非交集元素的任何信息。这样一来，用户尚未泄露的口令可以得到保护，他人已被泄露的口令也不会落入其他用户之手。

该如何实现隐私集合求交协议呢？YouTube 上 SFB 1119 CROSSING 的一个视频给出了大致原理，我这里给出一个翻译版本。当然了，这个视频也给出了隐私集合求交的另一个重要应用：隐私保护联系人发现（Private Contact Discovery）。

https://www.zhihu.com/video/1813165783280394241

谷歌将他们的工作总结成论文《Protecting accounts from credential stuffing with password breach alerting》，发表在信息安全顶级会议 USENIX Security 2019 上。此论文获得了 USENIX Security 2019 的最佳论文讲。我在 B 站上发布了论文报告的翻译视频，感兴趣的知友可以前往观看，了解更多的细节。

【双语字幕】（USENIX Security 2019）保护账户免受撞库攻击_哔哩哔哩_bilibili

应用隐匿信息查询（PIR）实现实时来电显示

在 2024 年苹果开发者大会（WWDC 2024）上，苹果宣布了新的实时来电显示查找（Live Caller ID Lookup）功能。我们来看一下苹果给出的介绍。我将实时来电显示查找部分裁剪了出来，并做了翻译。

https://www.zhihu.com/video/1813167529109090306

从视频中可以看出，此功能需要用到隐私信息检索（Private Information Retrieval，PIR），而 PIR 依赖于全同态加密（Fully Homomorphic Encryption，FHE）。为此，苹果同时对外发布了 Swift 语言的 FHE 算法包，并在其博客文章《宣布 Swift 同态加密》（Announcing Swift Homomorphic Encryption）中对外公开了这个工作。我这里也给出译文。

We’re excited to announce a new open source Swift package for homomorphic encryption in Swift: swift-homomorphic-encryption.

我们很高兴地宣布，Swift 提供了一个新的开源同态加密代码包：swift-homomorphic-encryption。

Homomorphic encryption (HE) is a cryptographic technique that enables computation on encrypted data without revealing the underlying unencrypted data to the operating process. It provides a means for clients to send encrypted data to a server, which operates on that encrypted data and returns a result that the client can decrypt. During the execution of the request, the server itself never decrypts the original data or even has access to the decryption key. Such an approach presents new opportunities for cloud services to operate while protecting the privacy and security of a user’s data, which is obviously highly attractive for many scenarios.

同态加密（HE）是一种加密技术，它支持对加密数据进行计算，而不会在运算过程中透露底层未加密的数据。同态加密为客户端提供了一种将加密数据发送到服务端的方法，服务端对加密数据进行运算并返回客户端可以解密的运算结果。在执行请求期间，服务端本身永远无法解密原始数据，甚至无法访问解密密钥。这种方法允许云服务在保护用户数据隐私性和安全性的条件下对数据进行运算，为云服务提供了新的可能。很明显，这对很多场景来说都是一项非常有吸引力的技术。

At Apple, we’re using homomorphic encryption in our own work; we’re therefore delighted to share this Swift implementation in the community for others to use and contribute to.

在苹果，我们在自己的工作中使用了同态加密。我们很高兴能向社区分享这个 Swift 实现，希望其他人也能使用同态加密，并未我们的实现作出贡献。

One example of how we’re using this implementation in iOS 18, is the new Live Caller ID Lookup feature, which provides caller ID and spam blocking services. Live Caller ID Lookup uses homomorphic encryption to send an encrypted query to a server that can provide information about a phone number without the server knowing the specific phone number in the request. To demonstrate this, we are also sharing live-caller-id-lookup-example, which provides a functional example backend to test the Live Caller ID Lookup feature using homomorphic encryption.

我们在 iOS 18 中使用同态加密的一个例子是全新的实时来电显示查找（Live Caller ID Lookup）功能。它可以提供来电显示和垃圾邮件拦截服务。实时来电显示查找使用同态加密向服务端发送加密查询，该查询包含了有关电话号码的相关信息，但服务端无须知道请求里的电话号码是什么。为了演示这一点，我们对外分享了“实时来电显示查找实例”，它提供了一个功能性实例后端代码，以验证同态加密实时来电显示查找功能。

These two packages take full advantage of features such as:
- Swift on Server, including the Hummingbird HTTP framework and cross-platform support
- easy benchmarking with the Benchmark library
- performant low-level cryptography primitives in Swift Crypto.

这两个代码包包含了下述特性：

• 服务端 Swift，包括蜂鸟 HTTP 框架和跨平台支持
• 简单的基准测试与基准库
• Swift Crypto 中的高性能底层密码学原语

Live Caller ID Lookup relies on Private Information Retrieval (PIR), a form of private key-value database lookup. In the PIR setting, a client has a private keyword (such as a phone number) and wants to retrieve the associated value from a server. Because the keyword is private, the client wants to perform this lookup without the server learning the keyword.

实时来电显示查找依赖于面向隐私键值数据库查找的隐私信息检索（PIR）。在 PIR 中，客户端拥有一个私有的关键字（例如电话号码）。客户端希望从服务端中检索此关键字所对应的值。因为关键字是私有的，客户端希望服务端在不知道关键字是什么的条件下完成检索。

A trivial implementation of PIR is to have the server send the entire database to the client for local processing. While this does prevent the server from knowing what queries are being made, it is only feasible for small databases with infrequent updates.

PIR 的一个简单实现方法是让服务端将整个数据库发送给客户端，由客户端在本地完成检索。虽然这确实能做到让服务端无法知道客户端检索的关键字是什么，但此方法只适用于数据不需要经常更新的小规模数据库。

In contrast, our PIR implementation, which relies on homomorphic encryption, only needs to sync a small amount of database metadata with the client. This metadata changes infrequently, which allows efficient handling of very large databases with a high volume of updates.

相反，我们的 PIR 实现依赖于同态加密，只需要向客户端同步少量数据库元数据。元数据更新频率很低，因此这一方法适用于数据需要频繁更新的大规模数据库。

As mentioned above, homomorphic encryption enables computation on encrypted data without decryption or access to the decryption key.

如上所述，同态加密允许在不解密、不访问解密密钥的条件下对加密数据进行计算。

A typical workflow for homomorphic encryption might be as follows:
- The client encrypts its sensitive data and sends the result to the server.
- The server performs computation on the ciphertext (perhaps incorporating its own plaintext inputs), without learning what any ciphertext decrypts to.
- The server sends the resulting ciphertext response to the client.
- The client decrypts the resulting response.

同态加密的典型工作流程如下：

• 客户端加密其敏感数据并将结果发送给服务端。
• 服务端对密文执行计算（计算过程可能涉及自己的明文输入），但不知道密文的解密结果是什么。
• 服务端将生成的响应密文发送给客户端。
• 客户端解密响应密文。

The Swift implementation of homomorphic encryption implements the Brakerski-Fan-Vercauteren (BFV) HE scheme (https://eprint.iacr.org/2012/078, https://eprint.iacr.org/2012/144). BFV is based on the ring learning with errors (RLWE) hardness problem, which is quantum resistant.

Swift 实现的同态加密方案是 Brakerski-Fan-Vercauteren（BFV）方案（https://eprint.iacr.org/2012/078，https://eprint.iacr.org/2012/144）。BFV 基于环错误学习（RLWE）困难问题，这是一个抗量子计算机攻击的困难问题。

The Live Caller ID Lookup feature requires BFV parameters with post-quantum 128-bit security, to provide strong security against both classical and potential future quantum attacks, previously explained in https://security.apple.com/blog/imessage-pq3/.

实时来电显示查找功能要求 BFV 参数满足后量子 128 比特安全性，以抵御经典和未来的潜在量子计算机攻击。我们在之前的博客（https://security.apple.com/blog/imessage-pq3/）中已经介绍过了相关细节。

We believe developers will find homomorphic encryption useful for a wide variety of standalone privacy-preserving applications both inside and outside the Apple ecosystem, including private set intersection, secure aggregation, and machine learning.

我们相信开发者会发现同态加密可以在苹果生态系统内外的各种隐私保护应用程序中得到应用。同态加密可用在隐私集合求教、安全聚合、以及机器学习中。

Below is a basic example for how to use Swift Homomorphic Encryption.

下面是一个如何使用 Swift 同态加密的基本示例。

import HomomorphicEncryption

// We start by choosing some encryption parameters for the Bfv scheme.
// *These encryption parameters are insecure, suitable for testing only.*
let encryptParams =
    try EncryptionParameters<Bfv<UInt64>>(from: .insecure_n_8_logq_5x18_logt_5)
// Perform pre-computation for HE computation with these parameters.
let context = try Context(encryptionParameters: encryptParams)

// We encode N values using coefficient encoding.
let values: [UInt64] = [8, 5, 12, 12, 15, 0, 8, 5]
let plaintext: Bfv<UInt64>.CoeffPlaintext = try context.encode(
    values: values,
    format: .coefficient)

// We generate a secret key and use it to encrypt the plaintext.
let secretKey = try context.generateSecretKey()
let ciphertext = try plaintext.encrypt(using: secretKey)

// Decrypting the plaintext yields the original values.
let decrypted = try ciphertext.decrypt(using: secretKey)
let decoded: [UInt64] = try decrypted.decode(format: .coefficient)
precondition(decoded == values)

We look forward to working with others to enhance this package: you can read more about contributing at the repositories on GitHub. We also encourage you to file issues to swift-homomorphic-encryption and live-caller-id-lookup-examples if you encounter any problems or have suggestions for improvements.

我们期待与其他人合作来增强这个算法包：如果您想了解如何为此算法包作贡献，请前往 GitHub 仓库。如果您遇到任何问题或有任何改进建议，我们鼓励您将问题提交至swift-homomorphic-encryption和live-caller-id-lookup-examples。

We’re excited to see how homomorphic encryption can empower developers and researchers in the Swift community to enable new use cases!

如果 Swift 社区的开发人员和研究人员能实现同态加密的新用例，我们一定会非常激动的！

苹果所使用的 PIR 协议是谷歌在 USENIX Security 2021 的论文《Communication – Computation Trade-offs in PIR》中提出的 MulPIR 协议。MulPIR 协议的基础是 S&P 2018 论文《PIR with Compressed Queries and Amortized Query Processing》中提出的 SealPIR 协议。SealPIR 协议依赖于微软发布的SEAL 同态加密库。这也可以看出，微软、谷歌、苹果等公司都在相应的方向上发力。

现代密码学已经不仅在链路加密、身份认证等场景中得到应用。很多前沿的现代密码学技术也开始为我们生活的方方面面提供保护。

以上。