More Instant Messaging Interoperability (mimi) G. Hogben Internet-Draft F. Olumofin Intended status: Informational Google Expires: 17 February 2024 16 August 2023 Interoperable Private Identity Discovery for E2EE Messaging draft-party-mimi-user-private-discovery-00 Abstract This document specifies how users can find each other privately when using end-to-end encrypted messaging services. Users can retrieve the key materials and message delivery endpoints of other users without revealing their social graphs to the key material service hosts. Users can search for phone numbers or user IDs, either individually or in batches, using private information retrieval (PIR). Our specification is based on a state-of-the-art lattice- based homomorphic PIR scheme, which provides a reasonable tradeoff between privacy and cost in a keyword-based sparse PIR setting. About This Document This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://datatracker.ietf.org/doc/giles-interop-user-private- discovery/. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-party-mimi-user-private- discovery/. Discussion of this document takes place on the mimi Working Group mailing list (mailto:mimi@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/mimi/. Subscribe at https://www.ietf.org/mailman/listinfo/mimi/. Source for this draft and an issue tracker can be found at https://github.com/femigolu/giles-interop-user-private-discovery. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Hogben & Olumofin Expires 17 February 2024 [Page 1] Internet-Draft E2EE Messaging Private User Discovery August 2023 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 17 February 2024. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Functional Requirements . . . . . . . . . . . . . . . . . 4 2.2. Privacy Requirements . . . . . . . . . . . . . . . . . . 5 2.3. Privacy Non-requirement . . . . . . . . . . . . . . . . . 5 3. Proposed solution . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Key distribution . . . . . . . . . . . . . . . . . . . . 5 3.2. Resolver registration . . . . . . . . . . . . . . . . . . 7 3.3. Preferred service integrity . . . . . . . . . . . . . . . 7 3.4. Cross-service identity spoofing . . . . . . . . . . . . . 8 4. Privacy of resolver lookup queries . . . . . . . . . . . . . 9 4.1. Proposed protocols . . . . . . . . . . . . . . . . . . . 9 4.1.1. Server database setup . . . . . . . . . . . . . . . . 10 4.1.2. Client key initialization . . . . . . . . . . . . . . 11 4.1.3. Client query generation . . . . . . . . . . . . . . . 12 4.1.4. Server response computation . . . . . . . . . . . . . 12 4.1.5. Client response decryption . . . . . . . . . . . . . 13 4.2. FHE key requirements . . . . . . . . . . . . . . . . . . 13 4.3. Cost estimates . . . . . . . . . . . . . . . . . . . . . 13 4.4. Notes . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 6. Normative References . . . . . . . . . . . . . . . . . . . . 14 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 Hogben & Olumofin Expires 17 February 2024 [Page 2] Internet-Draft E2EE Messaging Private User Discovery August 2023 1. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. Glossary of terms: * Authoritative Name Server: Final holder of the IP addresses for a specific domain or set of domains. * Client: A software application running on a user's device or computer. * Database: A collection of records all of equal sizes (i.e., padded as appropriate). * Dense PIR: A type of PIR scheme that is used to retrieve information from a database using the index or position of each record as key. This is equivalent to the standard PIR schemes from the literature. * DNS: See Domain Name Service. * Domain Name Service: A system that accepts domain names and returns their IP addresses. * FHE: See Fully Homomorphic Encryption. * Fully Homomorphic Encryption: A type of encryption that allows arithmetic operations to be performed on encrypted data without decrypting it first. * KDS Resolver: A service that helps clients find and download the public keys of other users. * KDS: See Key Distribution Server. * Key Distribution Server: A server holding the public key material that enables a user to securely communicate with other users. * Name Server: Stores DNS records that map a domain name to an IP address. * Partition: A smaller division of a shard that is used to facilitate recursion with PIR. Hogben & Olumofin Expires 17 February 2024 [Page 3] Internet-Draft E2EE Messaging Private User Discovery August 2023 * PIR: See Private Information Retrieval * Preferred Service: A messaging service that a user has chosen as the default. * Private Information Retrieval: A cryptographic technique that allows a client to query a database server without the server being able to learn anything about the query or the record retrieved. * Public Key Bundle: Cryptographic key and other metadata that are used to encrypt and decrypt messages. * Public Key PIR: A type of PIR scheme that uses a small amount of client storage to gain communication and computation efficiencies over multiple queries. * Resolver: A service that helps clients find the IP address for a domain through recursive queries over Name Servers hierarchy. * Shard: A subset of a large database that is divided into smaller, more manageable pieces. * Sparse PIR: A type of PIR scheme that is used to retrieve information from a database of key-value pairs. This is the same as Keyword PIR in the literature. * Transform: A process of converting the partitions in a shard into a format that is suitable for homomorphic encryption computations. 2. Introduction Outline of design for message delivery bridge and key distribution server discovery mechanisms for interoperable E2EE messaging clients. A DNS-like resolver service stores UserID <-> service pairs that map to key distribution and message delivery endpoints (e.g. Platform1 Bridges). Each service is responsible for an "authoritative name server" that covers its own users and this can be replicated/cached by other providers and retrieved by sender clients using a privacy preserving protocol to prevent social graph leakage. 2.1. Functional Requirements For a given messaging service identity handle (Phone number or alphanumeric UserID): Hogben & Olumofin Expires 17 February 2024 [Page 4] Internet-Draft E2EE Messaging Private User Discovery August 2023 1. P0 Return receiver service ID to send message payload: can be mapped to endpoints for message delivery and key distribution using standard mechanism -> e.g. Platform1.org/send/ (matrix.org/send/), Platform1.org/kds (matrix.org/kds) 2. P0 Return optional default receiver service ID user preference for a given PN/UserID (e.g. default:Platform1.org) 2.2. Privacy Requirements 1. P0 Resolver service should not learn the PN/UserID a client is querying for (i.e. who is sending a message to who) 2. P0 Resolver service should not learn the public identity of the querying client. 3. P0 Resolver service should not learn the exact timing of when a message is sent 2.3. Privacy Non-requirement Hiding service reachability. All major E2EE messaging services already publish unACL'd reachability information without opt-out i.e. +16501234567, reachable on Messages, Whatsapp, Telegram (not including name or any other info). Therefore this should not be a goal (and would not be feasible to implement). 3. Proposed solution 3.1. Key distribution ┌───────┐ ┌──────────┐ ┌────────────┐ ┌────────────────┐ ┌────┐ ┌──────┐ │P1 │ │P1 │ │P1 │ │Authoritative P2│ │P2 │ │P2 │ │ Client│ │ Front End│ │ Name Server│ │Name Server │ │ KDS│ │Client│ └───┬───┘ └────┬─────┘ └─────┬──────┘ └───────┬────────┘ └─┬──┘ └──┬───┘ │ │ │ Request P2 │ │ │ │ │ │ Name Records │ │ │ │ │ │ ────────────────────────> │ │ │ │ │ │ │ │ │ │ │ Replicate P2 │ │ │ │ │ │ Name Records │ │ │ │ │ │ <──────────────────────── │ │ │ │ │ │ │ │ │ PIR Query │ │ │ │ │ │ PN/UserID │ │ │ │ │ │───────────────────> │ │ │ │ │ │ │ │ │ │ │ │ PIR Query │ │ │ │ Hogben & Olumofin Expires 17 February 2024 [Page 5] Internet-Draft E2EE Messaging Private User Discovery August 2023 │ │ PN/UserID │ │ │ │ │ │ ─────────────────────> │ │ │ │ │ │ │ │ │ │ ╔═════╧══════════════════════╧═══════╗ │ │ │ │ ║Supported service IDs ░║ │ │ │ │ ║ + default service ║ │ │ │ │ ╚═════╤══════════════════════╤═══════╝ │ │ │ │ │ Service IDs │ │ │ │ │ │ & default service │ │ │ │ │ │ <───────────────────── │ │ │ │ │ │ │ │ │ │ │ │ Query │ │ │ │ │ │ PN/UserID │ │ │ │ │ ─────────────────────────────────────────────────────────────────────> │ │ │ │ │ │ │ │ │ │ Return Public │ │ │ │ │ │ Key Bundle │ │ │ │ │ <───────────────────────────────────────────────────────────────────── │ │ │ │ │ │ │ │ Return Public │ │ │ │ │ │ Key Bundle │ │ │ │ │ │<─────────────────── │ │ │ │ │ │ │ │ │ │ ────┐ │ │ │ │ │ Encrypt Message │ │ │ │ <───┘ │ │ │ │ │ │ │ │ │ │ │ │ Send Encrypted Message via messaging providers │ │ │───────────────────────────────────────────────────────────────────────────────────────────────────────────> ┌───┴───┐ ┌────┴─────┐ ┌─────┴──────┐ ┌───────┴────────┐ ┌─┴──┐ ┌──┴───┐ │P1 │ │P1 │ │P1 │ │Authoritative P2│ │P2 │ │P2 │ │ Client│ │ Front End│ │ Name Server│ │Name Server │ │ KDS│ │Client│ └───────┘ └──────────┘ └────────────┘ └────────────────┘ └────┘ └──────┘ Taking Platform1 client sending to a Platform2 user as an example: 1. Platform1 name server replicates authoritative Platform2 NS records. There will need to be a shared list of participating services and name server endpoints. 2. Platform1 client sends key bundle request to Platform1 front end (PIR encrypted PN/UserID) 3. Platform1 FE gets supported key distribution service IDs, version number + default service=Platform2 via PIR protocol from its own name server. 4. Platform1 FE queries Platform2 KDS to retrieve public keys. Hogben & Olumofin Expires 17 February 2024 [Page 6] Internet-Draft E2EE Messaging Private User Discovery August 2023 * 4.1 Platform1 Client first sends (query and session key) encrypted with Platform2 public key to Platform1 FE. * 4.2 Platform1 FE sends encrypted query to Platform2 KDS * 4.3 Platform2 KDS decrypts query and session key, encrypts response with session key * 4.4 Platform2 KDS sends encrypted response to Platform1 FE * 4.5 Platform1 FE forwards to Platform1 client 5. Platform 1 Client and Platform 2 Client exchange messages through their respective messaging providers. This provides E2EE interop while only disclosing to gateway service which services a phone number is registered to. In all other respects, gateway services learn no more information than in the non- interop case. 3.2. Resolver registration Each service is responsible for registering user enrollments with the resolver. 3.3. Preferred service integrity While the preferred service is public, the user should control its value/integrity. As well as ensuring user control, it also prevents spoofing attacks where an attacker A could create an account on a new service that B does not have an account on, and then set it to B's preferred service (see cross-service identity spoofing below). Therefore to prevent anyone but the user modifying the default service value, records must be signed with the user's private key and verified by the sender against their public key. For multiple key pairs across different services, the last key pair to sign the default service bit must be used to change the default. Hogben & Olumofin Expires 17 February 2024 [Page 7] Internet-Draft E2EE Messaging Private User Discovery August 2023 ┌──────┐ ┌──────────┐ ┌────────┐ │Client│ │Service UI│ │Resolver│ └──┬───┘ └────┬─────┘ └───┬────┘ │ │ Register Preferred Service + Signature│ │ │ ──────────────────────────────────────> │ │ │ │ Query PN/UserID │ │ ─────────────────────────────────────────────────────────────────────────────────> │ │ │ │ Return supported service IDs + default service preference + signature │ │ <───────────────────────────────────────────────────────────────────────────────── │ │ │ │────┐ │ │ │ Verify default service pref signature │ │<───┘ │ ┌──┴───┐ ┌────┴─────┐ ┌───┴────┐ │Client│ │Service UI│ │Resolver│ └──────┘ └──────────┘ └────────┘ 3.4. Cross-service identity spoofing Today, a messaging service may support one or more ways of identifying a user including email address, phone number, or service specific user name. Messaging interoperability introduces a new problem that traditionally has been resolvable at the service level: cross-service identity spoofing, where a user on a given E2EE may or may not be addressable at the same ID on another service due to a lack of global uniqueness constraints across providers. As a result, a user may be registered at multiple services with the same handles, e.g. if Bob's email is bob@example.com (mailto:bob@example.com) and his phone number is 555-111-2222 and he is registered with Signal and iMessage, he would be addressable at bob@example.com (mailto:bob@example.com):iMessage, 555-111-2222:iMessage, and 555-111-2222:Signal. In this case, the same userId on iMessage and Signal is acceptable as the phone number can map to only one individual who proves their identity by validating ownership of the SIM card. On services where a user can log in with a username _alone_, however e.g. Threema and FooService, the challenge becomes: * Alice messages Bob at Bob's preferred service (bob@Threema) * Eve messages Alice impersonating Bob using bob@FooService Hogben & Olumofin Expires 17 February 2024 [Page 8] Internet-Draft E2EE Messaging Private User Discovery August 2023 * Alice needs some indicator or UI to know that bob@Threema isn't bob@FooSercice and that when bob@FooService messages, it should not be assumed that bob@FooService is bob@Threema. Options for solving this are: 1. Storing the supported services for a contact in Contacts and if a receipt receives a message from an unknown sender, to treat it as spam or otherwise untrusted from the start. 2. Requiring the fully qualified username for services that rely on usernames only - e.g. bob@threema.com vs bob. 4. Privacy of resolver lookup queries Resolver lookup queries leak the user's social graph - i.e. who is communicating with whom, since the IP address of the querying client can be tied to user identity, especially when operating over a mobile data network. Therefore we propose to use Private Information Retrieval (PIR) to perform the resolver queries. We have evaluated multiple alternative schemes. The proposed solution is based on the Public Key PIR framework by Patel et al[PIRFramework] with sharded databases. This framework is applicable with any standard PIR scheme such as the open source implementation here (https://github.com/google/private-retrieval). Cost estimates suggest this is feasible even for very large resolver databases (10 billion records). 4.1. Proposed protocols A private information retrieval protocol enables a client holding an index (or keyword) to retrieve the database record corresponding to that index from a remote server. PIR schemes have communication complexities sublinear in the database size and they provide access privacy for clients which precludes the server from being able to learn any information about either the query index or the record retrieved. A standard single-server PIR scheme provides clients with algorithms to generate a query and decrypt a response from the server. It also provides an algorithm for the server to compute a response. The Public Key PIR framework [PIRFramework] can be wrapped around any standard lattice-based PIR scheme. This framework consists of server database setup, client key initialization, client query generation, server response computation, and client response decryption sub- protocols. All operations are over a set of integers with a plaintext modulus. Hogben & Olumofin Expires 17 February 2024 [Page 9] Internet-Draft E2EE Messaging Private User Discovery August 2023 4.1.1. Server database setup * *Sharding*: If the database is over 2^20 records, sub-divide it into shards of ~1 million unique records each, which is a good balance for privacy and costs. Performing PIR over the databases gives stronger privacy but is more costly. Similarly, running PIR queries over the shards is less costly but gives weaker privacy. - Sample a hash key *K_s* for sharding. - Using *K_s*, shard the large database of *r* records into *⌈r/2^20⌉* shards based on the hash prefix of the record's unique identifier. - *N.B.* The hash key will be provided to clients to determine the shard to query. * *Set partitioning boundaries for each shard D*: Given a *n* key- value pairs shard *D = {(k_1,v_1),...,(k_n,v_n)}*, then - Compute the number of database partitions as *b = n/d_1*. Where *d_1* is the desired size for each partition. A value of 128 for *d_1* works well. - Sample a partitioning boundary hash key *K_1* to generate a target partition for each shard key. - Compute the hash *F_1(K_1,k_i)* for each record identifier *k_i*. - Sort the hash values alphanumerically and then divide the list into *b* partitions *P_1,...,P_b*. - Store the b partition boundaries beginning hash values *B_0, ..., B_b*. Note that *B_0 = 0*, and *B_b = |U|-1* where U is the rage for *F_1(K_1,k_i)*. - *N.B.* The partition boundaries will be provided to clients and can be stored efficiently (e.g., ~11KB for *n* = 2^(*20*), *d_1* = 128, *|U|* = 2^(*64*)). * *Transform each shard*: Sample two hash keys *K_2* and *K_r* where *K_2* will be used to generate a row vector within each partition, and *K_r* is used to generate a representation for the transformed database as *F(K_r,k_i)||v*. * *N.B.* *F(K,k)* is the output value from hashing *k* with key *K* and *||* is a concatenation. Hogben & Olumofin Expires 17 February 2024 [Page 10] Internet-Draft E2EE Messaging Private User Discovery August 2023 * For each partition *P_i* - Construct a *|P_i| x d_1* Platform1 *M_i* by appending a random row vector from the bit vector derived from *(F_2(K_2,k||1),...,F_2(K_2,k||d_1))*. - Construct a *|P_i|* vector *y_i* by appending *F_r(K_r,k)||v* for each *(k,v)* in *P_i*. - Solve for *e_i* that satisfies *M_ie_i = y_i*. * Construct the transformed *d_1 x b* Platform1 as *E = [e_1 ... e_b]*. * The Platform1 *E* is the transformed Platform1 for shard *D*. * The clients must download parameters *(K_1,K_2,K_r)* to query each shard, plus *K_s* to inform the server of the target shard for a query. This protocol is completed by the server without any client participation and before answering any client query. Note that a shard must be re-transformed after an update. Shard transform only takes a few minutes. 4.1.2. Client key initialization * The client generates a per-key unique identifier (*UID*), *private key* and *public key* using a fully homomorphic encryption (FHE) scheme relying on hardness assumptions similar to Ring Learning with Errors problem. * The client persists the *UID* and *private key* into its local key store, and uploads query-independent parameters *UID* and *public key* to the server. These later parameters will enable the server to perform cryptographic operations (i.e., FHE) efficiently. * The server needs to maintain an up-to-date mapping of *UID* to *public key* for all clients. * Each client completes this offline initialization protocol before running any query. It also needs to perform it periodically (e.g., weekly or monthly) to prevent server linkability of private queries to the user over an extended period. * The client downloads query parameters from the server: Hogben & Olumofin Expires 17 February 2024 [Page 11] Internet-Draft E2EE Messaging Private User Discovery August 2023 - Sharding hash key *K_s* to inform the server of the target shard for a query. * Sets of parameters (*K_1,K_2,K_r,B_0, ..., B_b*) for each shard. 4.1.3. Client query generation * The client creates a query to retrieve the value corresponding to a database key *k* as follows: * Select a standard PIR algorithm with server-supported implementation as the underlying PIR scheme. * Compute *d = F_s(K_s,k)* to identify the shard to query. * Compute *j = F_1(K_1,k)* to learn which partition contains the desired entry from the downloaded partition boundaries for the shard. * Generate *z* vector *v* of length *d_1 , ... , d_z* . Compute a *d_1*-length random bit vector *v_1* from *(F_2(K_2,k||1),...,F_2(K_2,k||d_1))*. Compute *v_2* as a zero bit vector of *d_2* length with only the bit set at *⌊j/⌈n/d_1d_2⌉⌋*. Similarly compute *v_3 , ... , v_z*. * Finally use the underlying PIR scheme and the private key to encrypt the *z* vector *v.* * Send *v, d* and the *UID* to the server. * *N.B.* The dimension *d_z* is typically small; a size of 2 or 4 works well. 4.1.4. Server response computation * The server retrieves the public key for the client's *UID*, and computes the ciphertext of the value corresponding to the key of interest for the shard *d*, as follows. * Take the transformed shard *E* as a *d_1x ⌈n/d_1⌉* Platform1 *E_1*, use the underlying PIR response answering algorithm to compute *v_1.E_1*, and rearrange the resulting *⌈n/d_1⌉* vector as a *d_2x ⌈n/d_1d_2⌉* Platform1 *E_2*. Hogben & Olumofin Expires 17 February 2024 [Page 12] Internet-Draft E2EE Messaging Private User Discovery August 2023 * Next, compute *v_2.E_2*, and rearrange the resulting *⌈n/ d_1d_2⌉* vector as a *d_3x ⌈n/d_1d_2d_3⌉* Platform1 *E_3*. * The server similarly repeats the computation for the remaining dimensions *v_3 ,... , v_z*. * The end result is a ciphertext *r* of the database value corresponding to *k*. The server sends *r* back to the client. 4.1.5. Client response decryption * The client uses the underlying PIR response decryption algorithm and *private key* to decrypt the response *r* as *k_r||v*. If *F_r(K_r,k) == k_r* then returns *v* otherwise returns *null* (key not found). 4.2. FHE key requirements * At least 128-bit of security - ElGamal, NIST P-224r1 curve and a 4 bytes plaintext size for fast decryption. - Gentry-Ramzan, used a 2048-bit modulus - Damgaerd-Jurik, used 1160-bit primes 4.3. Cost estimates In these estimates, we propose using shards of size ~1 million of identifiers. For 1.28 TB (10 billion records), breaking this down into 10,000 shards each of size 1 million records gives a cost estimate for each query as below: Hogben & Olumofin Expires 17 February 2024 [Page 13] Internet-Draft E2EE Messaging Private User Discovery August 2023 +=======================================+===============+ | Parameter | Cost estimate | +=======================================+===============+ | PIR Public Key Size Per Device, | 14 MB | | including metadata (storage required) | | +---------------------------------------+---------------+ | Upload Bandwidth Per Query | 14 KB | +---------------------------------------+---------------+ | Download Bandwidth Per Query | 21 KB | +---------------------------------------+---------------+ | Client Time Per Query | 0.1s | +---------------------------------------+---------------+ | Server Time Per Query (Single Thread) | 0.8-1s | +---------------------------------------+---------------+ Table 1 Note on some assumptions for feasibility: 1. Resolver queries will be cached (vs requiring a roundtrip for every message) and asynchronous with message sending, therefore 1s latency is acceptable. 2. It is acceptable for key changes to be communicated reactively on decrypt failure. 3. Group messaging E2EE is bootstrapped using individual users' public keys and for V1, group state will be stored by the initiating user's service provider. Therefore no additional discovery mechanism is required. 4.4. Notes 5. IANA Considerations This document has no IANA actions. 6. Normative References [PIRFramework] Patel, S., Seo, J. Y., and K. Yeo, "Don't be Dense: Efficient Keyword PIR for Sparse Databases", 32nd USENIX Security Symposium, USENIX Security 2023 , n.d.. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Hogben & Olumofin Expires 17 February 2024 [Page 14] Internet-Draft E2EE Messaging Private User Discovery August 2023 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . Acknowledgments The technical description of the private information retrieval framework is based on Sarvar Patel, Joon Young Seo and Kevin Yeo's USENIX Security '23 paper titled "Don't be Dense: Efficient Keyword PIR for Sparse Databases " (https://www.usenix.org/conference/usenixsecurity23/presentation/ patel). Authors' Addresses Giles Hogben Google Email: gih@google.com Femi Olumofin Google Email: fgolu@google.com Hogben & Olumofin Expires 17 February 2024 [Page 15]