Wisper - private p2p communication

Mina Navigator Proposals
1

This topic is to discuss the proposal submitted by @atahanyild
Please see below for the details of the proposal and discussion.

3rd Sep, 2024
Current status: Under Consideration.
Opened for community discussion on : 3rd Sep, 2024

1 Like
2

Wisper

Project Background

This project introduces an innovative solution for secure, private, one-to-one communication between clients, leveraging Mina Protocol’s zero-knowledge proofs (ZKPs) and the o1js framework. The primary goal is to facilitate real-time, encrypted messaging that is verifiable by using recursed ZKP’s without relying on centralized servers for data storage, instead utilizing client-side storage and off-chain communication methods.

We have developed a project called “wisper” in ETHGlobal Brussels that enables parties to communicate with no third parties and central servers by setting a “local private network” among users. But we realized that only messaging is not enough, parties may want to prove that if a message is sent. A similar idea was also mentioned at Mina Hackathon Project Ideas documentation Yunus Gurlek wrote.

By integrating with Mina, the project ensures that the messages can be cryptographically verified and securely stored using a decentralized model. This approach guarantees privacy and data integrity while eliminating the need for a backend server.

Proposal Overview

Problem

In the current landscape, most messaging applications rely heavily on centralized servers, which pose risks to privacy and data security. Even if encryption is used, users must trust the service providers not to misuse or expose their data. Even if they claim to do end to end encryption but there is no proof because they are not open source. We all know that our “private” messages are sold since we see specialized ads related to our messages. Additionally, proving the authenticity of messages remains a challenge, particularly in legal or dispute scenarios.

One of the use cases is customer services. In traditional way, companies can manipulate the conversation when it comes to legal problems. We “trust” the customer assistant during the conversation, but they can corrupt, manipulate, delete or “reorder” messages. Imagine you are talking to your phone company’s customer assistant and that’s the conversation:

a: I dropped my phone to the water.
a: My phone sometimes doesn't charge.
b: No worries, you can keep using it.
a: My phone completely stopped working
b: You must send your phone to repair.

In the court, they can manipulate the conversation by reordering the conversation such as:

a: I dropped my phone to the water.
b: No worries, you can keep using it.
a: My phone sometimes doesn't charge.
a:  My phone completely stopped working
b: You must send your phone to repair.

or

a: My phone sometimes doesn't charge.
b: No worries, you can keep using it.
a:  My phone completely stopped working
b: You must send your phone to repair.

Even though they did not change any message or add a message that doesn’t exist, they manipulated the conversation by reordering and now they can accomplish “We were not informed about the phone dropped in water.” To keep the integrity of the conversation, we must know the correct order and if the other party read the message before replying.

Solution

This project proposes a decentralized, private, and secure messaging system using Mina Protocol’s ZKPs and o1js framework. By enabling encrypted off-chain communication between clients (e.g. browser tabs) and settling the chat history on-chain in the form a ZKP that has every message recursively, the solution provides verifiable proof of message authenticity. Communication method and message storage is not the concern of this project. Users have complete control over where their data is stored, be it locally, on a private network, or in a decentralized DA layer, ensuring both privacy and security.

As a solution for the customer service use case, by integrating o1js and client-side messaging, parties could communicate with no central services, and verify the conversation in any conflict. By recursing the messages to 1 proof like p1m2 -> p2m1 -> p1m1, we prove that p1 read the m1 message that p2 sent since it exists in the proof they sent. By that, we prevent message reordering. And since if they delete or manipulate a message in between, the final proof is going to change, they can’t manipulate the conversation.

Impact

The proposal leverages Mina Protocol’s ZKPs and o1js framework to enable a decentralized, private, and secure messaging system. This aligns with the core principles of Mina, which focuses on ensuring privacy and decentralization. By eliminating the need for centralized servers and enabling client-side data storage, this proposal strengthens the ecosystem’s security and trustworthiness.

By integrating cryptographically verified messages without the reliance on centralized storage or servers, the project introduces an innovative use case for Mina’s ZKPs. This can serve as a reference for other projects looking to implement similar decentralized solutions, thereby enhancing the ecosystem’s technological landscape.

The decentralized nature of the messaging system can attract privacy-conscious users, including developers, enterprises, and individuals concerned with data security. This is likely to encourage wider adoption of Mina Protocol, particularly among those who prioritize privacy.

The proposal mentions several potential use cases, such as legal counseling, private health counseling, customer services, and private communication among company employees. These varied applications can drive adoption across different sectors, enhancing the overall utility and reach of the Mina ecosystem.

The shift from centralized servers to a decentralized model improves security, reduces the risk of data breaches, and enhances user control over data. This addresses a significant concern in current messaging platforms, thereby offering a meaningful improvement.

The use of ZKPs to provide verifiable proof of message authenticity adds a layer of trust and transparency, particularly in legal or dispute scenarios. This feature can be particularly appealing to businesses and professionals, offering a tangible improvement over existing messaging systems.

Audience

The target audience includes developers, privacy-conscious users, and enterprises seeking secure communication solutions.

Some of the example use cases are:

  1. Private Legal Counseling

    • Description: Ensures confidential and tamper-proof communication between legal professionals and clients. Mina Protocol’s ZKPs provide verifiable proof of message integrity and order, critical in legal disputes.
    • Benefits:
      • Maintains privacy and confidentiality.
      • Provides a cryptographic audit trail for legal use.

  2. Private Health Counseling

    • Description: Protects sensitive health-related communication between patients and healthcare providers. The system guarantees privacy, integrity, and compliance with healthcare regulations through secure ZKPs.
    • Benefits:
      • Ensures confidential health counseling.
      • Supports regulatory compliance (e.g. HIPAA).

  3. Customer Services

    • Description: Provides a secure and verifiable record of customer interactions, preventing manipulation of conversation history. ZKPs ensure the authenticity and order of messages.
    • Benefits:
      • Prevents tampering with service logs.
      • Enhances trust and transparency.

  4. Corporate Compliance

    • Description: Enables secure, verifiable internal communications to meet corporate compliance standards. The system ensures that sensitive discussions remain private and unaltered.
    • Benefits:
      • Supports compliance with corporate policies.
      • Protects sensitive internal communications.

Additionally, this project appeals to the broader blockchain community interested in decentralized applications, ZKPs, and secure messaging.

Architecture & Design

Detailed Design/Architecture

Architecture Diagram
Architecture Diagram1600Ă—900 93.4 KB

1. Client

Private and Public Key Pair:

  • To ensure privacy and security, end-to-end encryption is used. Diffie-Hellman Key Exchange is employed for the creation of a shared secret, which is then used to derive symmetric encryption keys. Each client generates a pair of cryptographic keys: a private key (kept secret) and a public key (shared with the other party). The private key is used to sign and decrypt messages, while the public key is used to encrypt messages and verify signatures. Both parties will use a symmetric encryption algorithm to encrypt and decrypt messages. AES (Advanced Encryption Standard) or ChaCha20 can be used after deciding which algorithm suits best in our case.

Message Data:

  • The client is responsible for generating, sending, receiving, and processing messages. This includes creating the content of the message, encrypting it using the recipient’s public key, and signing it with the sender’s private key.
    • Message: The actual text or data being communicated between the clients.
    • Signature: A digital signature created using the sender’s private key, ensuring that the message is authentic and has not been altered.
    • Recursed Proof: A recursive zero-knowledge proof (ZKP) that demonstrates the integrity and order of the messages in the conversation without revealing their content.
    • Public Key: The public key of the message sender, which is used by the recipient to verify the signature and decrypt the message.

2. Mina Protocol & o1js

Recursive Proofs:

  • Mina’s ZKPs allow for the generation of recursive proofs that establish the integrity and order of messages within a conversation. This proof is updated with each new message and includes a Merkle tree structure to facilitate individual message verification.

Merkle Tree of Proofs:

  • Each message is represented as a leaf in a Merkle tree, with the root of the tree serving as a comprehensive proof of the entire conversation’s integrity up to that point. The Merkle root, along with the recursive proof, is settled on the Mina blockchain, ensuring tamper-proof verification and allows parties to verify not only the conversation but also every individual message if needed.

On-Chain Settlement:

  • The final recursive proof, along with the Merkle tree root, is submitted to the Mina blockchain for verification. This process ensures that the integrity of the entire conversation is cryptographically guaranteed and can be independently verified by any party.

3. Communication

The real value proposition is that Wisper is communication protocol agnostic. Any of the Server/Network/DA Layer/Bluetooth can be used to communicate.

  • Server: Acts as a relay between clients, facilitating the exchange of data. It does not store any message content or have access to private keys, ensuring that all messages remain encrypted and private. It is fully open source, so there is no need to trust.
  • Wi-Fi/Network: Represents the communication infrastructure that connects the clients, allowing them to exchange encrypted messages. This could be a local network, the internet, or any other form of data transmission.
  • Bluetooth: A wireless communication technology that allows clients to exchange data directly over short distances, providing an alternative to Wi-Fi or network-based communication. This is particularly useful in scenarios where clients are in close proximity but prefer not to use traditional networks.
  • DA Layer (Data Availability Layer): A decentralized storage layer where data is temporarily stored or relayed between clients. This layer does not have access to the content of messages, as everything is encrypted and only the clients hold the keys to decrypt.

4. Data Flow and Mina Protocol Integration

Message Creation and Encryption:

  • The sender generates a message and encrypts it using the recipient’s public key.
  • The message is signed with the sender’s private key to ensure authenticity and non-repudiation.

Proof Generation:

  • Initial Proof: When the first message is sent, a ZKP is generated, proving the authenticity and integrity of the message.
  • Recursive Proofs: As the conversation progresses, each subsequent message includes a recursive proof. This proof encapsulates the previous message’s proof, thereby maintaining a continuous chain of integrity across all messages.

Merkle Tree Construction:

  • Each message is hashed and added as a leaf node in a Merkle tree. The Merkle root serves as a compact representation of all messages exchanged so far.

Data Transmission:

  • The encrypted message, signature, recursive proof, and Merkle root are packaged together as data.
  • This data is then transmitted over the network (Wi-Fi, Bluetooth, or server relay).

Verification and Recursion at the Recipient’s End:

  • The recipient decrypts the message using their private key and verifies the sender’s signature using the sender’s public key.
  • The recipient verifies the recursive proof using Mina’s ZKP verification process, ensuring the message’s integrity and correct order within the conversation.
  • The Merkle tree allows the recipient to verify each individual message independently by checking its corresponding Merkle proof against the root.

On-Chain Settlement in Mina:

  • Final Proof Submission: Periodically, or at the end of a conversation, the final recursive proof and the Merkle root are submitted to the Mina blockchain.
  • Settlement Process: The Mina blockchain verifies the recursive proof and the Merkle root. This ensures that all messages, as well as the overall conversation integrity, are cryptographically secured and can be independently audited.
  • Individual Message Verification: Anyone with access to the Merkle root can verify any individual message by checking the associated Merkle proof against the settled root on the blockchain.

Detailed Considerations

Recursive ZKPs:

  • Mina’s recursive ZKPs are central to this architecture. They allow for the continuous and efficient proof of message integrity throughout the conversation, ensuring that each message builds upon the previous ones, creating an unbroken chain of trust.

Merkle Tree Structure:

  • The Merkle tree plays a critical role in enabling scalable and efficient verification. Each message is hashed and inserted into the tree, with the root representing the entire conversation. This allows for both compact settlement on the blockchain and easy verification of individual messages.

Mina Blockchain Integration:

  • By leveraging the Mina blockchain’s unique features, this system ensures that the proofs are lightweight and efficient to verify with the constant verification time and constant proof size features, making the entire messaging process both secure and practical for real-time use.

Vision

Our long-term vision is to establish this project as the leading decentralized communication platform built on Mina Protocol, setting a new standard for secure, private, and verifiable messaging. If funded, our goal is to create a robust and scalable system that can be adopted across various industries, including legal, healthcare, corporate, and personal communications where privacy and data integrity are paramount.

We envision this platform being a go-to solution for enterprises and individuals who require not only encrypted messaging but also the ability to prove the authenticity and integrity of their communications. Over time, we plan to expand the platform’s capabilities to support more complex interactions and integrations with other decentralized applications (dApps) within the Mina ecosystem.

As the project matures, we aim to contribute to the broader Mina community by open-sourcing key components, providing educational resources, and collaborating with other developers and organizations to enhance the ecosystem. Ultimately, we see this project as a catalyst for the widespread adoption of Mina Protocol, demonstrating the power and potential of zero-knowledge proofs and decentralized technologies in everyday applications.

During the grant process, our goal is to develop a fully functional product. Once the product is complete, we will shift our focus to marketing and growth efforts, particularly because our product is aimed at end-users. We aim to attract users to wisper by implementing targeted strategies. By growing our user base, we aim to make wisper accessible to a wide audience.

Existing Work

We have developed wisper in ETHGlobal Brussels, but both the idea and the technical architecture and requirements are different from this product we are going to develop. However, branding design (Logo, name etc.) and some of the front-end work can be used after a revision on the UI/UX.

Production Timeline

In 2 months, we aim to finish the project and be ready to use with the features listed:

  1. Encryption/Decryption on client side. Creating of shared secrets using Diffie-Hellman Key Exchange and deriving public-private keypair, signing and crypting messages with them.
  2. Proof generation. Generating proofs with the encrypted messages and the other inputs (more details in Detailed Design/Architecture section). Verification of the proof of incoming message.
  3. Communication. Implementation of open source relayer server, enabling using and testing the other parts developed.
  4. Settlement. Generating the merkle tree and the proof, settling it to Mina.

At the end of the 2 months, project will be ready to finding the other party, sending messages, receiving messages, verifying messages, settling to Mina, verifying the messages from the merkle tree settled to Mina.

Budget & Milestones

Deliverables

  • Mid-Point milestones: Working PoC front-end to implement and test the ready parts, client side encryption integration and communication between clients through one of the 5 communication protocols listed.

  • Project Timeline: 2 month.

  • Budget Requested: 32,000 Mina

  • Budget Breakdown: Funding the team, Covering the expenses such as domain, server.Here is the breakdown of the product by topics and approximately how long will they take.
    1- Revision of UI/UX(~15h)
    As informed, we have some design work from ETHGlobal, but it needs big adjustments such as it was supporting groupchats and used QR codes to find each other etc. We need to work about the flow scenerios and some other UX work.
    2- Research and client side implementation of Cryptography(~40h - 45h):
    We are going to do some research about end to end encryption to decide which algorithms and formulas works best for our case. Afterwards we’ll decide which libraries/packages are most suitable for our tech stack and needs.
    After this research process, in front end we’ll implement these to ensure end to end encryption. We’ll connect clients with each other and test this work.
    3- o1js integration(~25h-35h):
    Deciding on what is a ZKP going to contain as fields, what functions our ZKProgram needs, figuring out what kind of verification of message/signature/key we need to do inside the circuit.
    Programming the circuit also implementing the test codes for the ZKP generation and verification parts.
    4- Communication protocols(~25h-45h)
    Implementation of open source relayer server that is responsible for ensuring the communication between clients. We will merge the other parts and start testing process.After that, we also want to develop and integrate one more communication way from the list in the Detailed Design/Architecture section.
    5-Performance tests(~10h)
    Analyzing the performance of the system, observing how long proof generation takes and finding ways to optimize the system.
    6-Marketing(~25h)
    • Market Research
    Conduct thorough market research to understand the landscape of wisper. This includes analyzing competitors, identifying our target audience and user,understanding their needs.
    • Branding & Messaging
    . We’re aiming creating a unique value proposition and positioning wisper.
    • Content Strategy & Creation
    Creating content that highlights the features and benefits of wisper This could include blog posts, infographics, case studies, and how-to guides.
    • Social Media & Community Engagement
    • Launch Campaign

  • Wallet Address: B62qoXwa3MkRST54MgLwJth7cUkL8N52BiaDFymDuVaiNdmSDr1Bbvw

Team Info

This section provides details about the team.

  • Proposer GitHub:

    • Atahan Yıldırım
    • Kutay Sarı
    • Berkay GĂĽndĂĽz
    • Ä°rem Koçi

  • Proposer Experience: If you have relevant experience building zkApps or other dApps, provide that information here. If available, include links.

  • Team Members:

    • Atahan Yıldırım

      • GitHub: atahanyild
      • Role: Lead the technical team, develop shared secrets, encryption-decryption, and secure data storage, and work on ZKProgram and Mina smart contracts with Berkay.
      • Experience: Lead developer at YTU Blockchain club, with over a year of experience. Specialized in backend development using Node.js and developed ZKProgram with o1js for the LambdaClass hackathon-winning project, CosmicProof.

    • Kutay Sarı

      • GitHub: KkutaySarii
      • Role: Frontend Developer.
      • Experience: Developed dozens of websites, including banking interfaces, ticket platforms, and review sites. Skilled in React.js, Next.js, and Redux.

    • Berkay GĂĽndĂĽz

      • GitHub: berkay1532
      • Role: Developer for o1js ZKPrograms, Mina smart contracts, and servers.
      • Experience: Extensive experience with EVM contracts, backend, and DevOps. Co-founded a startup with a focus on NFT ticketing, winning awards in several hackathons.

    • Ä°rem Koçi

      • GitHub: irmkoci
      • Role: Design, UI/UX, marketing, and business development.
      • Experience: Managed marketing campaigns, business development strategies, and project management for multiple hackathon projects.

Achievements

  • CosmicProof:

    • LambdaClass hackathon winner, first place in the MinaProtocol and node101 tracks.

  • Orchave:

    • First place at Filecoin, with a pool prize in the Avail Project track at ETHGlobal Brussels.

  • NEVO:

    • Bounties in NEAR and MACI categories at ETHDam 2024.

  • NFTICKET:

    • First place at YTU Teknopark Startup House Bootcamp among experienced teams.

  • Greedysnap:

    • Second place in “Metamask Snap” category and fourth overall in the Ethereum track at ETH Belgrade hackathon.

  • MarketMaker:

    • Top spot at PythNetwork, with a pool prize in the Worldcoin track.

Risks & Mitigations

Description:

Off-chain communication between clients raises concerns about data integrity, especially if messages are stored on a local network or private server.

Mitigation:
To mitigate this, we will implement cryptographic proofs of data integrity that can be periodically anchored on-chain. This ensures that even if off-chain data is tampered with, discrepancies can be identified and resolved.

Description:

Privacy-focused solutions often require users to manage their own keys and understand complex concepts, which can hinder adoption.

Mitigation:
To mitigate this, we will focus on developing a user-friendly interface and clear educational materials to simplify the onboarding process. We will also explore integrating with existing identity solutions that are familiar to users, such as wallets they may already be using.

2 Likes
3

Great Project idea. Can I integrate the communication into Pin Save, for example?

Is it possible to abstract the communication for more than 2 users, which should enable comment section.

image
image1920Ă—1010 59.4 KB

1 Like
4

Thank you for your proposal.

  1. Regarding end-to-end encryption, are you planning to use existing JavaScript libraries? Could you please elaborate more on that?
  2. For message authentication, have you considered using an AEAD algorithm instead of a standard encryption algorithm?
  3. How do you plan to prevent MITM attacks?
3 Likes
5

Hey Pfedprod,

Wisper’s core focus is on private, one-to-one messaging with recursive zero-knowledge proofs (ZKPs) for verifiable, encrypted communication. While it’s technically possible to extend this system to support group chats (of coures it’s a much more complex implementation). One limitation is that messages are only stored client-side, meaning new participants wouldn’t be able to access historical messages. Because of this, the use case for a comment section might not be ideal.

However, the concept of verifiable communication using recursive ZKPs can certainly be abstracted and adapted to fit a comment section scenario. This would involve designing a system where each comment is cryptographically verified, ensuring message integrity while maintaining the decentralized and privacy-focused nature of the platform.

Let me know if you’d like to explore this further!

6

  1. Regarding the libraries:
    While we haven’t finalized the exact libraries we will use in development, we are considering several options:

    • We could leverage the native “crypto” library provided by Node.js. Although this requires more development effort, it avoids the use of third-party dependencies and provides fine control over cryptographic operations.

    • Alternatively, we are exploring third-party libraries like Libsodium.js and OpenPGP.js. These libraries offer robust cryptographic functions out of the box, significantly accelerating the development process while maintaining high security standards.

    • We are also considering using the Signal Protocol (libsignal-protocol-js), which is widely trusted by secure messaging applications such as Signal and WhatsApp due to its advanced E2EE capabilities.

  2. AEAD algorithms:
    Thank you for the suggestion regarding authenticated encryption. We are planning to dive deeper into the cryptographic architecture for this project, and AEAD (Authenticated Encryption with Associated Data) is definitely on our radar. It offers both encryption and message authentication, which we recognize as a valuable addition to our security approach.

  3. Preventing MITM attacks:
    Since we are employing end-to-end encryption and messages are encrypted and stored only on the client side, MITM attacks are mitigated as attackers cannot decrypt the messages without possessing the private keys. We also plan to implement additional measures, such as mutual authentication and key verification, to further strengthen our defense against MITM attacks.

1 Like
7

Thank you for your comprehensive response and the time you took to address these points.

  1. The idea of data integrity does make sense, but I’m still unclear about how this would make end-to-end encryption provable, as raised in the proposal. Are you suggesting that encryption should happen within a popular JS library rather than in a zkProgram? In the scenario you described, it seems like we would only be storing ciphertext in a Merkle tree, which wouldn’t allow to verify which key signed the message. Could you please clarify?

  2. I’m also unsure about the claim that end-to-end encryption alone prevents MITM (Man-in-the-Middle) attacks. The key challenge is ensuring that both clients have the correct public keys: your client must have the same public key for me that my client has, and my client must have the same public key for you that your client has. If both clients agree on these keys and we trust the client software, we can be reasonably confident that a MITM attack isn’t happening…
    That’s why apps like Signal include “verify safety numbers,” and WhatsApp has “verify security codes.”

Also, as far as I know, a simple Diffie-Hellman key exchange (DHKE) is still vulnerable to MITM attacks. While it’s not common, integration with CA (Certificate Authority) keys helps mitigate this vulnerability. You can find more details in the following resources:

Excited for the project and looking forward to your thoughts!

1 Like