Crescent cryptographic library from Microsoft Research brings privacy to digital identity systems

Digital identities, the electronic credentials embedded in phone wallets, workplace logins, and other apps, are becoming ubiquitous. While they offer unprecedented convenience, they also create new privacy risks, particularly around tracking and surveillance.

One of these risks is linkability, the ability to associate one or more uses of a credential to a specific person. Currently, when people use their mobile driver's license or log into various apps, hidden identifiers can link these separate activities together, building detailed profiles of user behavior.

To address this, we have released Crescent(opens in new tab), a cryptographic library that adds unlinkability to widely used identity formats, protecting privacy. These include JSON Web Tokens (the authentication standard behind many app logins) and mobile driver's licenses. Crescent also works without requiring the organizations that issue these credentials to update their systems.

The protection goes beyond existing privacy features. Some digital identity systems already offer selective disclosure, allowing users to share only specific pieces of information in each interaction.

But even with selective disclosure, credentials can still be linked through serial numbers, cryptographic signatures, or embedded identifiers. Crescent's unlinkability feature is designed to prevent anything in the credential, beyond what a user explicitly chooses to reveal, from being used to connect their separate digital interactions.

Two paths to unlinkability

To understand how Crescent works, it helps to examine the two main approaches researchers have developed for adding unlinkability to identity systems:

1. Specialized cryptographic signature schemes. These schemes can provide unlinkability but require extensive changes to existing infrastructure. New algorithms must be standardized, implemented, and integrated into software and hardware platforms. For example, the BBS(opens in new tab) signature scheme is currently being standardized by the Internet Engineering Task Force (IETF), but even after completion, adoption may be slow.

1. Zero-knowledge proofs with existing credentials. This approach, used by Crescent(opens in new tab), allows users to prove specific facts about their credentials without revealing the underlying data that could enable tracking. For example, someone could prove they hold a valid driver's license and live in a particular ZIP code without exposing any other personal information or identifiers that could link this interaction to future ones.

Zero-knowledge proofs have become more practical since they were first developed 40 years ago but they are not as efficient as the cryptographic algorithms used in today's credentials. Crescent addresses this computational challenge through preprocessing, performing the most complex calculations once in advance so that later proof generation is quick and efficient for mobile devices.

Beyond unlinkability, Crescent supports selective disclosure, allowing users to prove specific facts without revealing unnecessary details. For example, it can confirm that a credential is valid and unexpired without disclosing the exact expiration date, which might otherwise serve as a unique identifier. These privacy protections work even when credentials are stored in a phone's secure hardware, which keeps them tied to the device and prevents unauthorized access.

Behind the cryptographic curtain

At its core, Crescent uses a sophisticated form of cryptographic proof called a zero-knowledge SNARK (Zero-Knowledge Succinct Noninteractive Argument of Knowledge). This method allows one party to prove possession of information or credentials without revealing the underlying data itself.

Crescent specifically uses the Groth16 proof system, one of the first practical implementations of this technology. What makes Groth16 particularly useful is that its proofs are small in size, quick to verify, and can be shared in a single step without back-and-forth communication between the user and verifier.

The system works by first establishing shared cryptographic parameters based on a credential template. Multiple organizations issuing similar credentials, such as different state motor vehicle departments issuing mobile driver's licenses, can use the same parameters as long as they follow compatible data formats and security standards.

The mathematical rules that define what each proof will verify are written using specialized programming tools that convert them into a Rank-1 Constraint System (R1CS), a mathematical framework that describes exactly what needs to be proven about a credential.

To make the system fast enough for real-world use, Crescent splits the proof generation into two distinct stages:

1. Prepare stage. This step runs once and generates cryptographic values that can be stored on the user's device for repeated use.

1. Show stage. When a user needs to present their credential, this quicker step takes the stored values and randomizes them to prevent any connection to previous presentations. It also creates a compact cryptographic summary that reveals only the specific information needed for that particular interaction.

Figures 2 and 3 illustrate this credential-proving workflow and the division between the prepare and show steps.

A sample application

To demonstrate how Crescent works, we created a sample application covering two real-world scenarios: verifying employment and proving age for online access. The application includes sample code for setting up fictional issuers and verifiers as Rust servers, along with a browser-extension wallet for the user. The step numbers correspond to the steps in Figure 4.

Setup

1. A Crescent service pre-generates the zero-knowledge parameters for creating and verifying proofs from JSON Web Tokens and mobile driver's licenses.

1. The user obtains a mobile driver's license from their Department of Motor Vehicles.

1. The user obtains a proof-of-employment JSON Web Token from their employer, Contoso.

1. These credentials and their private keys are stored in the Crescent wallet.

Scenarios

1. Employment verification: The user presents their JSON Web Token to Fabrikam, an online health clinic, to prove they are employed at Contoso and eligible for workplace benefits. Fabrikam learns that the user works at Contoso but not the user's identity, while Contoso remains unaware of the interaction.

1. Age verification:The user presents their mobile driver's license to a social network, proving they are over 18. The proof confirms eligibility without revealing their age or identity.

Across both scenarios, Crescent ensures that credential presentations remain unlinkable, preventing any party from connecting them to the user.

For simplicity, the sample defines its own issuance and presentation protocol, but it could be integrated into higher-level identity frameworks such as OpenID/OAuth, Verifiable Credentials, or the mobile driver's license ecosystem.

To learn more about the project, visit the Crescent project GitHub(opens in new tab) page, or check out our recent presentations given at the Real-Word Crypto 2025(opens in new tab) and North Sec 2025(opens in new tab) conferences.

Opens in a new tab