💾 Archived View for gemini.panda-roux.dev › log › entry › 38 captured on 2023-04-19 at 22:39:00. Gemini links have been rewritten to link to archived content

-=-=-=-=-=-=-

An idea for a gossip messaging protocol (Re: The Monstrosity that Email Has Become)

Posted on Thursday October 21, 2021

I recently read thought-provoking response to another gemininaut's post regarding the late state of e-mail. In that response, the author enumerated some of the characteristics of a physical (paper) letter, and contrasts them with the characteristics of e-mail as we know it today.

The (response) post in question

At the end of their post, the author asks us what we can imagine in terms of a messaging protocol that shares more characteristics with snail mail than conventional e-mail does.

Immediately I was reminded of a file I had written and almost forgotten about, describing an idea I'd had for a decentralized messaging service. The contents of the note are rather technical, and I wrote it back in February of this year so there are several points in it that are misinformed. I wanted to post it to my gemlog nonetheless, in the spirit of sharing knowledge.

I don't have any delusions that this is a particularly novel or unique idea, it's just something that I thought sounded interesting and decided to jot down one day. I'm sure it's already been tried.

What follows is the contents of that file, cleaned up for the gemtext format:

---

Key terms

Agent: A person or program using this protocol, posessing a unique cryptographic key and a (optionally) a nickname (AKA "client")
Message: An encrypted piece of data that is passed between agents in order to ultimately be received (and decrypted) by its intended recipient
Local Web: A WLAN or other method of communicating between agents which allows a single agent to broadcast messages to other agents in the local vicinity

Backround

Encrypted message traffic being transmitted over traditional infrastructure (network cables, transmission lines, undersea cable, ISP backbones) can be intercepted, tracked, or otherwise interfered with by state actors and ISPs. Popular messaging services such as Signal rely on a central network of servers owned and operated by a single entity. Whether or not those service providers can access the contents of the (hopefully) encrypted message traffic they facilitate, the transmission of data to and from their servers still provide ISPs and state actors a means of interference and invasion of privacy.

One possible means of reducing the likelihood of interference with our communications by external actors is by circumventing traditional telecommunications infrastruction entirely. This can be accomplished by passing encrypted messages between users' devices over LAN connections (or other non-internet means). People physically travelling and connecting to networks shared with other people provides a means of moving messages from one point to another. This mechanism of information exchange is analogous to people passing paper notes from one person to another. I'm not sure if the term applies exactly, but I think that this is related to the concept of a "Gossip Protocol".

The obvious drawback to transmitting data this way is that messages can take an unpredictably long time to reach their intended recipients, and indeed may never be received. The likelihood of messages being successfully received can be improved by incentivizing users' traveling and putting themselves in the position to exchange message traffic with other users.

Goals

I want to develop a protocol for facilitating secure, anonymous messaging between disparate users that is transmitted solely via hopping between other users' devices directly without traversing the web. Such a protocol has the potential to enable wide-ranging, unmolested communication that is truly decentralized, having no single point of failure or central authority.

In order to make such a means of communication viable, I want to build a system on top of the protocol that "gameifies" participation in message exchange. Users can be incentivized to compete with one-another by being rewarded for participating in successfully sending messages to their intended recipients.

Design:

Messages

Messages are the data interchange format that make up the content sof all secure traffic that takes place across the decentralized network. Messages are encoded as ASCII (TODO: unicode?) characters in the following format (line breaks added for clarity):

TIME:12345678;
TTL:3600;
ALG:SHA256;
FROM:81b/f...14+a7;
TO:0Abc7...6750b;
KEY:9Ha81...1bacI/;
DATA:aGVsbG8gd...

Each message is comprised of the following named components:

TIME: A timestamp in the Unix integer format indicating the date and time (UTC) at which the message was initially created.
TTL: A time-to-live (TTL) value indicating the number of seconds after its initial creation for which the message should be considered valid. Agents should discard expired messages and not forward them to other agents. Any agent receiving an expired message should ignore it.
ALG: A value indicating the cryptographic hash algorithm that was used to derive FROM and TO (see below). The following values are valid: "SHA256" and "SHA512".
FROM: A hash of the sender's public key, derived using the cryptographic hash algorithm specified in ALG. If the recipient agent has exchanged keys with the sender, then this has can beused to identify and display information about that known sender.
TO: A hash of the intended recipient's public key, derived using the cryptographic hash algorithm specified in ALG. If an agent receives a message with a hash that matches corresponding a hash of its own public key, the agent should consider itself to be the intended recipient of the message, and so should decrypt it and not forward it on to others.
KEY: The RSA signed and encrypted key used for decrypting DATA, described below. The signature should be made using the sender's private key, and should be encrypted for the recipient's public key.
DATA: The AES-encrypted message contents, encrypted with the plaintext contents of KEY after KEY has been decrypted using the recipient's private key.

Agents

Agents are the nodes that make up the decentralized web of communications traffic that this protocol facilitates. They will typically be associated with a single user. It's likely that some users may choose to create agents that are stationary and run on a fixed piece of hardware. So-called "fixed agents" have interesting implications in terms of network reliability and gamification mechanics. Agents must embody the following characteristics:

Each non-fixed agent must possess a cryptographic private/public key pair. This key pair will be used to decrypt messages sent to the agent, and can also be used to sign messages in-transit. Exchanging public keys with another user is analogous to trading "contact information", as each agent involved will then have everything it needs in order to send messages to the other.
In addition to a key pair, each agent may optionally have a non-unique "nickname" associated with itself that is provided alongside its public key for the sake of user-friendliness.
Each agent must be able to store a number of encrypted messages meant for other users.

Broadcasts

While an agent is connected to a WLAN or similar, it must broadcast hashes of its cached messages to other agents on the network. These broadcasts must each consist of a string in the following plaintext ASCII format (line breaks added for clarity):

ALG:SHA256;ADDR:192.168.1.17:12777;HASH:8ab01...ca7bf

The broadcast is message is described as follows:

ALG: A value indicating the cryptographic hashing algorithm used to derive the hash. The following values are valid: "SHA256" and "SHA512".
ADDR: A string representation of the local address and port from which the recipient should request the body of the message being represented.
HASH: A hash of the entire message being referred to, derived based on the value of ALG.

While an agent is connected to a WLAN or similar network it must listen for broadcasts from other agents.

When an agent receives a broadcast, it should compare the message hash contained therein with hashes of the messages stored in its cache. If the broadcast's hash does not match any of the recipient's cached messages, then the recipient should request a copy of the corresponding message from the broadcaster. The request should be sent via TCP to the address and ports specified in the broadcast's ADDR field. It should consist of the following (line breaks added for clarity):

ALG:SHA256;
HASH:18b1a...91a2e

The meanings of the fields are the same as those in the broadcast message format.

Exchange

The broadcaster, upon receiving the above request in response to its broadcast, should respond to the request with the full body ofthe requested message as described at the beginning of this section.

Upon receiving the full body of the requested message from the broadcaster, an agent should perform the following checks:

Does a newly-calculated hash of the message contents match the hash value that was used to request the message? If it does not, then discard the message.
Is the message expired? If so, discard it.
Is the agent the intended recipient of the message? If so, then use the its private key to decrypt KEY. Verify that the signature on KEY matches the sender indicated in FROM and is an otherwise valid signature. Use the plaintext value obtained from decrypting KEY as a key to decrypt DATA, and handle the resulting plaintext however appropriate. Do not forward the message.
Otherwise, cache the message and begin broadcasting it for others to request.

An agent should periodically check for expired messages in its cache and delete them.

Authoring

An agent wishing to send a new message should follow the following procedure:

Append a verifiable signature to the end of the message contents.
Encrypt the contents of the message using a secure symmetric cipher, with a randomly-generated key.
Encrypt the symmetric key using the public key corresponding to the intended recipient.
Build a formatted message body as described above. This involves deciding on a lifespan for the message in question, which can be pre-configured by the user or determined based on some other factor.

An agent caching and forwarding a message should not alter the message's TTL. In the future there should be a safeguard against this.

Example Scenario

Tianliang wishes to send Arthur a message. They have previously met in-person and exchanged contact information, including their public keys.

Tianliang packages up their message and it's stored in their device's cache. They then go to a coffee shop and connect to its wi-fi network.

Also on the wi-fi network is Kain, who happens to be standing in line at the register.

Tianliang's device broadcasts that it has a message. Kain's device receives that broadcast and requests a copy of the message.

Tianliang's device sends a copy of the requested message to Kain's device.

Kain then goes about her day, and a week later is at a grocery store which Arthur happens to be at as well.

Kain's device broadcasts that it has a message to pass along, and Arthur's device requests a copy of that message.

Upon receiving the message, Arthur's device sees that the key hash attached to the message matches his own. Seeing that this message was intended for him, the device decrypts the it and notifies Arthur, who can then read what Tianliang had written for him.

- panda-roux -

next: "Upcoming changes to MoonGem"

prev: "Trade-in and New Lens"

Email me about this post