I believe I've devised a method to conceal the recipient of end-to-end encrypted (E2EE) messages, which I'm calling the Lost in the Shuffle (LITS) network/protocol. This solution requires establishing a new network where the identity of the sender is known—this is an intended feature. The concept is straightforward and efficient, yet I wonder if it might already have been thought of, or if I'm overlooking something obvious. Given my limited experience in writing white papers and working with low-level code, I'm sharing this protocol openly.
Overview of the LITS Protocol and Network:
The network relies on two primary entities: a node and a repeater.
Basic Functionality:
The repeater receives messages from nodes within the network and broadcasts them to everyone. While all nodes receive every broadcasted message, they only process and decrypt those they are equipped and wish to decrypt. The repeater maintains a simple database of all node IPs and their corresponding public keys.
Operational Details:
1. Joining the Network
- A new node (JN) initiates its inclusion in the network by sending its public key and a payment to the repeater. The exact nature of this payment system is still under consideration; it may be beneficial for the repeater to function as an e-cash mint.
- The repeater responds by sending JN a comprehensive list of all the public keys currently active within the network. For a network of 1,000,000 nodes, this list would be approximately 0.5GB in size (assuming 512 bytes per node).
- JN then uses these public keys to encrypt a symmetric key (potentially AES-256) for each node. These encrypted keys are bundled into a message and sent back to the repeater.
2. Key Distribution:
- As both the sender's and receiver's identities are known during this setup phase, the repeater distributes each encrypted key message to the respective node.
- Upon receiving its encrypted key, each node decrypts the message to extract the symmetric key and stores this key in its database, linked to the sender’s public key. Nodes choose which public keys they wish to listen to, with the default setting being none, to optimize processing speed and storage efficiency. Nodes may also choose to monitor messages encrypted with their own public key.
3. Sending Messages:
- To send a message, JN encrypts it with the symmetric key associated with the recipient’s public key and sends this encrypted message to the repeater, possibly accompanied by a small payment.
- The repeater then broadcasts this encrypted message to all nodes. Only the intended recipient, possessing the correct symmetric key, can decrypt and recognize the message.
Network Participation:
Anyone can operate a node or a repeater. However, repeaters benefit from having high bandwidth and being part of a larger network, although the returns diminish beyond a certain size.
Trade-offs:
- Large repeaters may face scalability issues as the number of nodes increases.
- High upload bandwidth is necessary for repeaters to manage effective message distribution.
- Nodes must remain online to receive messages; otherwise, they risk missing transmissions unless the sender rebroadcasts them.
josh
npub1pc5…dmza
2024-05-10 16:32:28
Author Public Key
npub1pc57ls4rad5kvsp733suhzl2d4u9y7h4upt952a2pucnalc59teq33dmzaPublished at
2024-05-10 16:32:28Event JSON
{
"id": "78a445c24d312468442585fd7438eff425bd88291be9e5ef7ba10cd27016e227",
"pubkey": "0e29efc2a3eb6966403e8c61cb8bea6d78527af5e0565a2baa0f313eff142af2",
"created_at": 1715351548,
"kind": 1,
"tags": [],
"content": "I believe I've devised a method to conceal the recipient of end-to-end encrypted (E2EE) messages, which I'm calling the Lost in the Shuffle (LITS) network/protocol. This solution requires establishing a new network where the identity of the sender is known—this is an intended feature. The concept is straightforward and efficient, yet I wonder if it might already have been thought of, or if I'm overlooking something obvious. Given my limited experience in writing white papers and working with low-level code, I'm sharing this protocol openly.\n\nOverview of the LITS Protocol and Network:\n\nThe network relies on two primary entities: a node and a repeater.\n\nBasic Functionality:\n\nThe repeater receives messages from nodes within the network and broadcasts them to everyone. While all nodes receive every broadcasted message, they only process and decrypt those they are equipped and wish to decrypt. The repeater maintains a simple database of all node IPs and their corresponding public keys.\n\nOperational Details:\n\n1. Joining the Network\n\n - A new node (JN) initiates its inclusion in the network by sending its public key and a payment to the repeater. The exact nature of this payment system is still under consideration; it may be beneficial for the repeater to function as an e-cash mint.\n\n- The repeater responds by sending JN a comprehensive list of all the public keys currently active within the network. For a network of 1,000,000 nodes, this list would be approximately 0.5GB in size (assuming 512 bytes per node).\n\n - JN then uses these public keys to encrypt a symmetric key (potentially AES-256) for each node. These encrypted keys are bundled into a message and sent back to the repeater.\n\n2. Key Distribution:\n\n- As both the sender's and receiver's identities are known during this setup phase, the repeater distributes each encrypted key message to the respective node.\n\n- Upon receiving its encrypted key, each node decrypts the message to extract the symmetric key and stores this key in its database, linked to the sender’s public key. Nodes choose which public keys they wish to listen to, with the default setting being none, to optimize processing speed and storage efficiency. Nodes may also choose to monitor messages encrypted with their own public key.\n\n3. Sending Messages:\n\n- To send a message, JN encrypts it with the symmetric key associated with the recipient’s public key and sends this encrypted message to the repeater, possibly accompanied by a small payment.\n\n- The repeater then broadcasts this encrypted message to all nodes. Only the intended recipient, possessing the correct symmetric key, can decrypt and recognize the message.\n\nNetwork Participation:\n\nAnyone can operate a node or a repeater. However, repeaters benefit from having high bandwidth and being part of a larger network, although the returns diminish beyond a certain size.\n\nTrade-offs:\n\n- Large repeaters may face scalability issues as the number of nodes increases.\n\n- High upload bandwidth is necessary for repeaters to manage effective message distribution.\n\n- Nodes must remain online to receive messages; otherwise, they risk missing transmissions unless the sender rebroadcasts them.",
"sig": "c08c481d2329d8bcfd23a9574e2098ece1bc6cded4745b57a94c0d61b5d14656052afd44ca492c1397ac08f69159e55fa91a3c57ab620e5af5bbe842e5a96c8e"
}