This piece was first published as part of the EIC Publication and later ported here with minor edits.
Two decades of innovation have endowed us with ubiquitous connectivity and tools to manage every aspect of our lives. Yet, amidst the technological renaissance, our methods for authenticating ourselves over the internet have largely remained unchanged.
Signups are still largely derivative of validating email ownership. For other more rigorous validations, there is little choice aside from uploading documents or scanning physical ideas and waiting for resolution. Meanwhile, much of the data that represents our growing digital footprints is locked away, unable to be used to authenticate our identities and our assets.
Digital signatures offer an elegant solution, providing cryptographic guarantees of data origin and integrity. When coupled with emerging cryptographic techniques, they have the potential to reshape authentication in ways that enhance privacy, improve efficiency, and even unlock new avenues for value exchange.
In this piece, I will:
- Provide a brief overview and history of digital signatures, examining several ubiquitous sources of signed data
- Explore emerging cryptographic techniques that allow digital signatures to become portable and composable
- Showcase a live application incorporating many of these techniques in a practical peer-to-peer solution for exchange
- Highlight the tradeoffs, caveats, and learnings from building with these advanced cryptographic techniques
Foundations of online trust
Digital signatures were conceptualized in 1970 as part of a broader effort to secure digital communications.
They are built on top of public-key cryptography and require a pair of keys: a private key for signing and a public key for verification. The private key is kept secret by the signer, while the public key is openly shared. Together, they enhance communication over the internet with three properties:
- Authentication: ensuring messages are from a certain origin
- Integrity: protecting messages from tampering while in transit
- Non-repudiation: preventing the signer from denying they signed the document
To create a signature, the document or message is hashed to produce a fixed-sized value that serves as the document's fingerprint. The resulting value is then encrypted with the signer's private key, producing a digital signature.
Verification allows anyone to combine this signature, the original data, and the signer’s public key to validate that the signature was produced by the private key. The security of this process relies on the computational difficulty of hard mathematical problems, making forgery virtually impossible without the private key.
Lotus Notes 1.0, released in 1989, was the first widely marketed software package to showcase digital signature functionality, enabling users to electronically sign documents and establish the authenticity and integrity of electronic communications.
Today, their usage is ubiquitous, yet operating behind the scenes across a variety of applications:
- SSL/TLS certificates authenticate websites, preventing phishing attempts. (Introduced by Netscape in 1994, with TLS 1.0 following in 1999)
- Email authentication methods like DKIM (DomainKeys Identified Mail) verify sender identity, ensure email integrity, and mitigate spam. (Developed from earlier methods by Yahoo! and Cisco in the mid-2000s and later ratified in RFC 6376 in 2011)
- Mobile device secure enclaves produce payment authorization and biometric data signatures (secp256 elliptic curve)
- Source version control platforms like GitHub enable signing for contributors to verify the authenticity of code changes
In other words, we rely heavily on the signatures they produce as part of our daily internet use. For example, when you access your online banking portal, your browser uses SSL/TLS certificates to ensure communication with the bank.
Similarly, when you receive an email from the bank, DKIM signatures allow your email client to authenticate various components of the email such as the sender's domain, subject, and body.
Expansion of signed data
Protocols for generating digital signatures have evolved over time, improving in efficiency and security to enable larger and more sensitive communication over the web. As we continue expanding our online presence, there is the potential to use this data to authenticate ourselves and our data.
However, today, there still remains a shortage of exported data and signatures that we can meaningfully apply outside of the platforms that create it. This paradox stems from two primary factors:
First, current signature verification methods require access to the entire original message. In other words, there is no way to selectively disclose parts of a signed message or document without revealing its entirety, limiting flexibility and privacy.
Second, the services we commonly use have little incentive to expose and sign our data. The high value placed on data predates even the AI arms race, as evidenced by the long-standing competition for attribution and targeting data in advertising. On the rare occasions API access is granted, the restrictions often make it impractical and cost-prohibitive to consume.
The scarcity of signed data is particularly evident in API interactions. While APIs facilitate much of the web's data transfer, few implement digital signatures. Accompanying API responses with signatures could significantly enhance internet authenticity.
For instance, imagine if Amazon provided a signed API for your purchase history. This could enable you to prove your purchasing patterns or loyalty status to other services. You could verify to a warranty service that you bought a specific item on a certain date, or demonstrate to a financial app that you have a history of responsible spending. This level of verifiability would enhance the utility of your own data across various services.
This data scarcity extends to the fundamental problem of identity verification where most of the internet still authenticates via email ownership. More important services such as banking may further utilize patchworks of identification methods including uploading unsigned documents, capturing photos of physical IDs, or simply sharing account credentials.
Generative AI models and agents further compound these challenges, making it increasingly simple to produce convincing forgeries and automate synthetic behaviors. This development heightens the urgency for more robust verification methods, leveraging cryptographic proof of authenticity.
The closest attempt at standardized identification in the U.S. is the REAL ID Act of 2005. However, this merely sets standards for state-issued IDs rather than establishing a national identity registry. The formation of a centralized system, akin to India's Aadhaar, remains unpopular across the political spectrum due to privacy concerns and fears of potential discrimination.
Given both the possibilities and challenges in authenticating ourselves in the future, a question emerges: Is there a way for us to securely and efficiently prove to others our data while preserving privacy and preventing misuse?
Next generation cryptography
Research at the intersection of cryptography, mathematics, and computer science has yielded new primitives that might offer a solution. The notable advancements include Zero Knowledge Proofs and Secure Multi-Party Computation, both of which today are accompanied by mechanisms that make them applicable today.
Zero Knowledge Proofs (ZK)
Formally, ZK proofs are a method by which one party can prove to another that a given statement is true without revealing any information beyond the fact of the statement’s truth.
Today, they are most often linked to projects focused on scaling blockchains, utilizing succinctness and computational integrity properties of ZK proofs to assert state updates from a batch of transactions.
However, they truly shine as verifiable statements of computation and are particularly powerful when the computation encapsulates both the verification of a digital signature and extraction of specific details from the signature’s inputs. This capability allows you to make statements on those details to another party while guaranteeing their authenticity, all without revealing the inputs to the computation.
Mentioned earlier, one abundant source of signatures today comes from our email inboxes. Most emails are signed by the sending domain servers using the DKIM protocol, producing a signature over the sender and recipient addresses, subject, and body. When used in a ZK proof, this allows proving statements about the email’s contents without revealing the entire email.
Similar workflows can be applied to other signature sources, including from attested hardware, signed APIs, and even embedded signatures in physical identification like passports. Open-source projects such as ZK Email and Proof of Passport are making these proofs increasingly accessible for developers.
Secure Multi-Party Computation (SMPC)
SMPC allows multiple parties to jointly compute a function while keeping their individual inputs private. It uses secret sharing schemes to ensure that no single party can recover the secret or intermediate results of the computation.
This enables computations like key exchange required for HTTPS, ordinarily between a single client and a server, to be broken up between multiple parties. Key exchanges are a necessary step in symmetric key encryption which clients rely on for efficient payload transfer. However, this means that HTTPS calls don’t natively produce verifiable signatures over responses despite servers possessing certificates of authenticity.
This distributed key exchange process can then be combined with cryptographic commitments to different stages of an API request lifecycle and later proved with ZK proofs, producing verifiable attestations of the API call.
TLSNotary, another open source-protocol, leverages this concept to create proofs of data provenance for web data that uses TLS. It achieves this by introducing a third party, a notary, during the TLS handshake. The notary receives a secret share from the key exchange and collaborates with the user to encrypt requests and decrypt responses without learning the full key or seeing the plaintext contents.
The protocol employs a technique called deferred decryption, which enables efficient selective disclosure of elements of requests and responses. This allows the user to omit sensitive information such as session tokens from requests or personally identifiable details in responses, revealing only the data they wish to prove.
Revolutionizing digital verification
Together, these cryptographic primitives offer a window into how we might prove our identities and interact over the web in the future.
Crucially, these techniques don't require opt-in from the services we interact with. By leveraging existing signatures in our emails and notarizing our web interactions, we can utilize the growing set of data that best authenticates us without relying on services to open APIs.
These methods also unlock new avenues for signup that go beyond simple social, email, and even passkey based logins. By combining multiple sources of signed data, we can create a more robust, multi-faceted proof of identity that ensures membership comprises explicitly targeted qualifications.
Cryptographic proofs of digital signatures also represent the most final form of authentication on the internet, a means of digitally proving data that can be verified synchronously, enabling services to give you immediate resolution on your enrollment or checkout.
When paired with blockchains, these advancements enable new ways to directly exchange value by allowing users to prove statements about off-chain asset ownership and transactions directly to smart contracts. The smart contracts act as trustless escrow agents, settling the exchange without the need for intermediaries, and based solely on verifying cryptographic proofs.
By bridging the gap between our digital and physical identities, and between on-chain and off-chain worlds, these cryptographic techniques pave the way for more efficient, secure, and user-centric digital interactions.
ZKP2P: Showcasing emerging cryptography
Over the past year, our team experimented with these techniques, integrating them into ZKP2P, and showcasing how they can be used to facilitate on-chain verification of off-chain transactions. Here’s how it works:
- Users generate zero-knowledge proofs from a past successful payment confirmation email from Venmo, a popular p2p payment service in America, proving they own a Venmo account
- An off-ramper escrows USDC (Circle's fiat-backed stablecoin) into a smart contract, specifying a conversion rate
- An on-ramper pays the off-ramper the specified amount on Venmo
- Upon receiving a payment confirmation email from Venmo, the on-ramper generates a zero-knowledge proof of the payment using ZK Email
- The on-ramper submits this proof to the escrow contract, and receives the proper amount of USDC
This workflow allows for a trustless exchange of fiat balance for tokenized assets, with the blockchains serving as the arbiters. With the help of ZK proofs, we were able to mitigate manual settlement ordinarily required in similar workflows.
While this approach proved successful for Venmo, our experimentation expanding the system revealed significant challenges. Notably, emails for other p2p payment services often lacked the unique identifiers for the assets or transactions they certified, making it challenging to prevent replay attacks.
In the context of an exchange, this could result in double or multi-spend by the counterparty in a system where a single off chain event should only be eligible for one on chain redemption.
Furthermore, we found that displayed names or other generic identifiers within the email could not be reliably used for verification as many platforms allowed users to update their profile information, enabling the spoofing of valid proofs.
Expanding to APIs: The TLSNotary solution
To address these limitations, we explored APIs of the same services which often contained more of the necessary data for fingerprinting transactions.
We were able to enable Revolut, a popular p2p platform in Europe by incorporating TLSNotary, allowing users to notarize API responses containing their Revolut IDs and balance transfers. Here, privacy and selective disclosure were crucial as many of the responses returned social security numbers.
These attestations function similarly to the ZK email proofs, allowing users to exchange Revolut balances for USDC.
While our research has largely centered around access to stable currencies, this paradigm for peer to peer exchange is applicable to virtually all digitally represented assets, from fungibles such as loyalty points and reservations to event tickets and domain registrations.
Proving ownership also unlocks composability, enabling innovative and flexible mechanisms for exchanging verified assets. They can be seamlessly integrated into complex multi-party trades or conditional exchanges requiring other validations.
ZKP2P serves as an early preview of how we will interact and exchange assets online when the means to securely export and verify our data become more accessible.
Challenges
Like any other advanced computing platform, these techniques are not without their constraints and tradeoffs. Our experience building ZKP2P has revealed the cutting edge and boundaries of both the underlying techniques and the data sources that would serve as meaningful inputs.
Technical Limitations
Generating zero-knowledge proofs is generally resource intensive, often requiring several orders of magnitude more computation than natively performing the operations, mostly from large multi-scalar multiplications. This results in barriers to providing practical experiences at a time when users expect sub-second latencies on operations.
In many cases, computation cost also scales with the size and format of the inputs. Proving neatly shaped data may be optimized, but extracting data embedded in larger JSON API responses or HTML in email often result in even higher resource costs.
Outsourcing the computation to powerful servers is an option, but introduces potential privacy trade-offs due to inputs being revealed to the server.
On the other hand, SMPC and TLSNotary, while more computationally efficient, face prohibitive network bandwidth requirements. The protocol necessitates the transfer of hundreds of megabytes of data during a single TLS handshake, exceeding the capacity of most cellular data plans and limiting their applicability in bandwidth-constrained environments.
From a tooling perspective, translating specific verification logic into arithmetic circuits and properly initializing certain public parameters that secure the verification still require highly specialized knowledge.
Reliable Data Sources
The value of these techniques is also constrained by the availability and content of meaningful data sources, both signed and unsigned.
Incorporating data sources at scale relies on reverse engineering existing platforms to reliably return emails or consistent responses for notarization. This results in significant platform risk as the platforms, which are not required to opt in to support usage of their data in this manner and are beyond our control.
Additionally, much of the existing signed data lacks the unique identifiers that make them resistant to forgery. Without these, malicious actors could potentially spoof statements under the guise of valid proofs. These vulnerabilities undermine the trustworthiness and value of systems that incorporate proofs.
Reconstruction of inputs for second-hand verification also poses several challenges. Email clients often don't make DKIM signatures available to users, despite verifying these signatures themselves. Clients can also alter subject lines and encoding in email bodies to improve the user experience or support their internal handling of data.
These learnings underscore the complexity of implementing these techniques which, while promising, still have significant hurdles to overcome.
Continued research into more efficient proving algorithms could help address some technical barriers. Meanwhile, developments like RFC9421, which calls for HTTP message signatures, offer exciting possibilities for more reliable and standardized data sources.
Conclusion
We stand to benefit greatly from efficient and privacy-preserving authentication of our data. Emerging cryptographic primitives such as zero knowledge proofs and secure multi party computation make this possible by revolutionizing how we can leverage existing signatures and data sources.
Projects like ZKP2P demonstrate how these technologies can facilitate novel forms of proving ownership, bridging on-chain and off-chain ecosystems, and exchanging value by unlocking synchronous verification of transaction data.
While technical and practical challenges remain, these advancements offer a promising solution to the trilemma of digital authentication: achieving security, efficiency, and privacy simultaneously and pave the way for a new era of digital interaction.
Acknowledgements
Thanks to Richard Liang and Abishek Punia for reviewing drafts of this and Andy Guzman and the PSE for supporting our research.