RFP - Zcash Memo Field Secure Messaging Extension

[wobbzz]

Hello everyone - here is our first RFP for 2023 to extend the Zcash memo field to enable secure messaging.

The RFP is available in PDF format for sharing here.

Proposals for this RFP can be submitted here.

1. Project Description

The Zcash Community Grants (ZCG) committee is inviting qualified individuals or companies (Grantee(s)) to submit a proposal to extend the Zcash memo field to enable secure messaging for the Zcash community. The current memo field in Zcash lacks several essential features necessary for secure messaging, such as being signed to verify the origin of messages and being forward-secure to protect against future key compromises. The project will address these issues by developing a reference implementation of a secure messaging application built on top of the extended memo field and a ZIP proposal to support the inclusion of these changes in a future Zcash network upgrade. The project will include a thorough security analysis of the extended memo field and the reference implementation, as well as user documentation for the reference implementation. The project deliverables will include a detailed design document outlining the proposed extension of the memo field, a ZIP proposal for the inclusion of the extension in a future Zcash network upgrade, implementation of the extended memo field and reference implementation, security analysis, and user documentation.

The relationship between the Grantee(s) and ZCG shall be that of a grantee and grantor, governed by standard grant terms and conditions and additional RFP standard terms and conditions.

2. Project Assumptions

The following assumptions were made in the development of this Scope of Work:

• The Zcash network will support the extended memo field and the proposed network upgrade.
• The Zcash community will support the ZIP proposal and its inclusion in a future network upgrade.
• The reference implementation of the secure messaging application will be built on top of the Zcash network and will utilize the extended memo field.
• The reference implementation will meet the needs of typical users for secure messaging and will be user-friendly.
• The security analysis will identify any potential vulnerabilities in the extended memo field and the reference implementation and provide recommendations for addressing them.
• The implementation of the extended memo field and the reference implementation of the secure messaging application will be completed within the proposed timeline.
• The reference implementation will be well-documented and easy to understand for users and developers.
• The team will have the necessary experience and qualifications to complete the project successfully.

3. Scope of Work

Problem statement:

• The memo field in Zcash is currently lacking several features necessary for secure messaging, making it difficult to verify the origin of messages and protect against future key compromises. The goal of this project is to extend the memo field with additional features to enable the creation of secure messaging applications with Signal-like security properties.

Project goals and Required Elements:

1. The goal of this project is to extend the Zcash memo field to support secure messaging by:

• Signing the memo field to enable verification of the origin of messages.
• Implementing forward-security for the memo field to protect against future key compromises.
• Developing a ZIP proposal to support the inclusion of these changes in a future Zcash network upgrade.
• Supporting the ZIP proposal through the inclusion process and helping to ensure its successful implementation.
• Developing a reference implementation of a secure messaging application built on top of the extended memo field.

Project tasks:

1. Stage 1: ZIP Proposal:

• Develop a detailed design document outlining the proposed extension of the memo field and the reference implementation of the secure messaging application.
• Conduct a thorough security and performance analysis of the extended memo field design.
• Develop a ZIP proposal for the extension of the memo field and its inclusion in a future Zcash network upgrade.
• Engage the Zcash community to establish consensus on whether or not to implement the proposal.

2. Stage 2: Implementation

• Implement the extended memo field and the reference implementation of the secure messaging application.
• Conduct a thorough security analysis of the reference implementation of the extended memo field.
• Provide user documentation for the reference implementation.

Project deliverables:

The contractor(s) will be required to deliver:

• A detailed design document outlining the proposed extension of the memo field and the reference implementation of the secure messaging application.
• Security and performance analysis of the extended memo field design.
• A ZIP proposal for the extension of the memo field and its inclusion in a future Zcash network upgrade.
• Implementation of the extended memo field and the reference implementation of the secure messaging application.
• Security and performance analysis of the extended memo field reference implementation.
• User documentation for the reference implementation.

4. Proposal Requirements

The Proposal shall outline the Grantee’s Scope of Services, which at minimum must include the criteria set forth within this Request for Proposal, and the Grantee’s approach to administer and complete the project.

A detailed project approach will assist ZCG in understanding the Grantee’s comprehension of the project and the opportunities and constraints that a project of this complexity may contain. At a minimum the Proposal shall include the following:

• Cover letter detailing what specifically qualifies them to execute the project (maximum 1 page)
• Project approach including any details on the design approach and clearly identify all assumptions such as estimated increase to transaction size and client performance cost (appropriate length for the complexity of the specific project)
• Project process (check-ins, sign-offs, other applicable process actions)
• Project team organizational chart
• Response to Section 10, if applicable
• Resumes (2 page maximum per resume) for key project personnel and any subcontractors to be used (unless prohibited by a specific SOW)
• Samples of applicable work (attachments or links)
• Itemized budget with any milestone payments clearly tied to completed intermediate deliverables
• Any supplementary materials relevant to the project

5. Additional Comments

Extending the Zcash memo field will require changes in the consensus mechanisms within zcashd and zebrad. Ideally, we prefer proposals for which the applicant is able and willing to contribute code to these code bases. However, we will also accept proposals from applicants who can design and deliver the ZIP proposal and a separate reference implementation with the expectation that ECC/ZF may implement the ZIP in zcashd/zebrad themselves.

[pacu]

What kind of messaging is this targeting? Can it be scoped clearly?

Is it in the sense of sporadic piece of interchangeable data shared between parties? or is it in the sense of Instant Messaging?

Have the authors of this RFP factored in hurdles of previous developers of similar endeavors like the ZBay team?

[wobbzz]

The scope of this proposal was left intentionally vague with the intent of delivering a generic capability that could be leveraged by a variety of applications.

We did not consult with the Zbay team on their prior hurdles encountered with similar endeavors, but would certainly welcome their input! @holmesworcester

[holmesworcester]

Hey! I just saw this. I wouldn’t be able to focus on this but I passed it along to the team that I worked with on Zbay to see if they’d like to propose something.

[earthrise]

@pacu

Have the authors of this RFP factored in hurdles of previous developers of similar endeavors like the ZBay team?

There’s two pieces to this, one is the security/privacy properties of the memo field and the other is performance-related issues. I interpret this RFP to be about the former, whereas the latter has been a roadblock for projects like Zbay. The two issues are intertwined because if the latter is solved, then it may become feasible to just run the Signal protocol over the memo field. Solving the performance issues is a much harder problem, so it makes sense to add additional security features to the memo field (authentication, forward secrecy, etc.) in a way that’s hopefully compatible with any future performance upgrades.

[aure]

In the proposal, you include as deliverables “A detailed design document outlining the proposed extension of the memo field” and “Implementation of the extended memo field”. But I believe that a secure messaging application can be implemented without changing memo field at all, and respecting the guidelines defined in ZIP-302.

Is acceptable a proposal for this RFP that does not change the memo field at all? If not, what are you expecting regarding that?

[earthrise]

You could in theory do it without any protocol-level changes to the memo field, e.g. providing forward secrecy by doing ratchet-like key exchanges in the memo field itself. Doing it this way might not be as efficient, since you may end up with ciphertexts-within-ciphertexts and may have to split things over multiple memos, so the RFP opens up the possibility of making protocol-level changes.

I can’t speak for ZCG but if you can provide Signal-like properties efficiently without any protocol level changes I’d say that would be great!

[ambimorph]

@aure

But I believe that a secure messaging application can be implemented without changing memo field at all, and respecting the guidelines defined in ZIP-302.

Is acceptable a proposal for this RFP that does not change the memo field at all? If not, what are you expecting regarding that?

If I’m understanding your question, I think you’re asking about creating an app that entails secure messaging without implementing the ZIP. If so this could either address what the RFP is asking for (if you designed a protocol that does it a different way than envisioned), making the ZIP unnecessary, OR it could be just an app that’s independent of the ZIP that we would consider on its own as a submission not related to the RFP.

I guess I’d need more detail to understand which it is.

Does that make sense?

[hanh]

Not sure what the technical requirements are. What are the benefits of forward secrecy when memos are encrypted with an ephemeral key part of zcash protocol already.

[earthrise]

Let’s say you have a sensitive conversation with a friend and after the conversation you both decide that you really don’t want anyone else to ever see those messages, even someone who later hacks into your or your friend’s phone.

With the current memo field design, you’d have to delete all of your copies of your viewing key, which removes your access to all of your other messages too, and forces you to send a new address to all your contacts, and then you’d have to ask your friend to do the same.

With a forward-secure protocol you and your friend can selectively delete just the sensitive messages you both don’t want to be kept around in your histories. After the messages are deleted locally, they can’t be recovered from any keys that could be stolen from your phone.

But people probably expect and want their messages to be restored when they restore from a seed phrase, so a challenge that maybe this grant can solve is how do we let users’ wallets restore/sync their messages while still allowing for permanent deletion?

[hanh]

Yeah, I understand forward secrecy but I don’t understand where it fits with having messages stored on the blockchain. If you want to have additional session keys exchanged out of band, what’s the policy for their management and storage? IMO without a requirement doc, you’ll get very diverse designs that may not be compatible or usable in practice.

[GGuy]

It almost sounds like someone had an idea of how to do this then the RFP was made super generic to allow for other ideas .

What’s the assumption for the protocol level change? A method of storing/associating pre-computed keys on-chain?

[GGuy]

I’ve always thought “Zcash Object Signing and Encryption” would be a good idea (think COSE/JOSE… ZOSE). Could be super compact in instances when you are reusing some of the cryptographic properties of the transaction yet generic enough to change the properties when necessary.

[wobbzz]

Hi everyone,

The committee has decided to reprioritize our RFP efforts and place this initiative on hold for now in light of market uncertainty and the need to focus on core issues within the Zcash ecosystem.

Thank you to both of the CoinFabrik and Eiger teams for their recent submissions on this proposal and understanding regarding this decision.

Zcash Community Grants Committee

[Dsrdrk11a]

Hi @wobbzz and the Committee members.
I’m Alex from the Bela Supernova team and we plan to build a p2p crypto messenger. I’ve found this RFP was put on hold some time ago, but not dismissed at all. Is it still interesting for the Zcash community to build a private messenger on the Zcash network?
Actually, we are thinking of smt that is built a little different from the entire RFP - we want to build a private messenger that uses WebRTC for setting up p2p channels for message passing. SDP offers will be exchanged in the Zcash network and all messages will be encrypted on a front end using a public key of a receiving user.

If this could be of interest of the Zcash community and the Committee, we’ll prepare a detailed grant proposal.

[ambimorph]

Interesting. If I’m understanding correctly, the memo will be used to establish secure connection, but then the messaging will be out of network, something like what I suggested in this related RFP?

@ambimorph

The memo field is limited to 512 bytes, so by itself cannot carry long messages or high-information-content images. The protocol design should specify standard ways to either combine messages, or optionally to use out-of-band file storage and operate by transmitting capabilities to files, such as with IPFS, Magic Wormhole, or Tahoe-LAFS, and demonstrate how this would work in practice.

[Dsrdrk11a]

@ambimorph exactly! After establishing a connection using the memo, all messages will pass out of the network. Each opened dialogue will be stored only on the user’s front end. Honestly, we see several use case intricacies on further steps, like storing chat history on-chain (with mutual consent for saving history), or on-chain private contact lists, which would be easy to put in a smart contract (if it was), but fundamentally we see no constraints, this is just a matter of implementation. So we propose to split the development on milestones and start from a PoC with the WebRTC implementation and a basic front-end for messaging and we could sketch out a rough plan for addressing these UX-related issues.