ERC-7627: Secure Messaging Protocol

ERCs
1

https://github.com/ethereum/ERCs/pull/268

Abstract

This proposal implements the capability to securely exchange encrypted messages on-chain. Users can register their public keys and encryption algorithms by registration and subsequently send encrypted messages to other users using their addresses. The interface also includes enumerations for public key algorithms and a structure for user information to support various encryption algorithms and user information management.

Objectives

  1. Provide a standardized interface for implementing messaging systems in smart contracts, including user registration and message sending functionalities.
  2. Enhance flexibility and scalability for messaging systems by defining enumerations for public key algorithms and a structure for user information.
  3. Define events for tracking message sending to enhance the observability and auditability of the contract.
  4. Using a custom sessionId allows messages to be organized into a conversation.
2

A few non-editorial related comments:

  • I raised a similar idea for an on-chain key registry in Pretty good privacy (PGP / GPG) on-chain keyserver. Happy to see someone else exploring the same space!
  • Using an enumeration for key types might limit the future expandability of the standard. What if a new algorithm comes along?
  • It might be a good idea to allow users to store one public key per algorithm, instead of just one per user, and further, you might want to allow users to store separate signing/encryption keys for validation vs. encryption.
1 Like
3

I agree, which also means the function sendMessage() and event MessageSent will probably need to specify which algorithm the message was encrypted with (or at least the associated public key) so that the recipient can properly decrypt it. This may also make it easier for indexers and clients to process incoming messages if it’s a lot and to switch which one is used if vulnerabilities or other issues are found.

1 Like
4

As you mentioned, having a wallet store only one public key is not a good design. I modified the implementation to allow users to set multiple public keys and specify expiration times.

2 Likes
5

Hello. I came across this EIP only recently, after working on a decentralized messaging system for general use on EVM compatible blockchains. My somewhat different approach was already integrated into a working application, so I have submitted a version of that in another ERC.

I tend to agree with what others have posted here - that the protocol is somewhat restrictive. But that might well be a feature, not a bug, in some specific application. I am curious to know whether you, or anyone else, has used the approach described here in an actual app - whether in development or production. Do you have any information on this?

Also - there is one part of the design that I don’t fully understand the rationale for, which is using a custom session ID to allow messages to be organized into a conversation.

You stated in the ERC that “The use of session IDs in message transactions allows multiple messages to be grouped under specific conversations. This feature is crucial for organizing and managing discussions within a dApp, providing users with a coherent and structured messaging experience.”

However, the simpler approach is to treat events sent between a pair of addresses as a single conversation within any app that is sending data through the sendMessage() function and reading data from the MessageSent event. I would be interested in understanding why you made this design choice, since the necessity of a session ID is not immediately obvious to me.

Scott