The problem Crunch solves

Our solution aims to address the challenge of verifying the authenticity of encrypted conversations (such as those over HTTPS) in a decentralized and privacy-preserving manner. It leverages Risc0 proofs to enable smart contracts to interact with Web3 actions based on potentially private Web2 data. A normal TLS client can have confidence in the security of its own connection, but because the encryption keys required to decrypt the communications are the same ones needed to forge it, this security cannot be proved to a third party.

For instance, validation of a conversation with a cloud-based AI model like ChatGPT is possible only by checking the server certificate provided by a TLS connection with the OpenAI API, but this would require public disclosure of authentication tokens to be handled via a traditional oracle-based system. Our system employs Multi-Party Computation to establish trust without revealing content, allowing you to prove to the world that ChatGPT really did cast aspersions on your mother.

In constrast to existing solutions, our approach acheives scalability by offloading most work from the MPC domain to a Risc0 proof generated by the client, is not limited to TLS 1.2 and below, and does not require the server to support deprecated ciphersuites to function.

Challenges we ran into

• Our initial design was focused on ECDHE over the NIST P256 curve, but as it turns out most webservers use X25519 instead. A significant amount of domain-specific boolean circuit work was thus rendered irrelevant.
• We used the cutting edge of MPC protocol development and benchmarking, MP-SPDZ. Unfortunately, this requires writing your MPC code in untyped Python, and disassembling bytecode for a domain-specific virtual machine is par for the course while debugging.
• Several Rust libraries we wanted to use required massaging to function within Risc0; notably, TLS libraries tend to like to access the system time to check certificate validity, but no clock is available inside the Risc0 guest.