User:0x20545446

About Me

You can reach me at BM-2DB621eNPkjJi3MMpSTqE3YvqKxnz8ZAji

Note: If there is a paper or proof showing the Bitmessage protocol is immune from man-in-the-middle attacks please bitmessage me the link. Or better yet add it to this wiki. Thanks.

I think my current concerns could be addressed if an encrypted transfer was made between each of the p2p nodes using encryption keys unique to each node pair. For this when a node "registers" on the network it needs to establish a encrypted link with each other peer node and be able to verify that none of the nodes have been compromised by a man in the middle attack. By using unique channels between each node the ability of a man in the middle is to operate is made more complex. The man in the middle would have to impersonate all of the node pairs at one time, not just the public/private key pairs for each individual node. In a 5 node network that would mean impersonating 5! (120) data channels instead of 5 nodes. If we can make the channels in some way self validating through a consensus approach, then once the network is established the man in the middle would have to compromise many data channels at once to sustain a comprise of the network. If we add this on top of the existing protocol that may be enough to ensure privacy.

We need to think of the internet as a having all nodes interconnected through a single central, compromised location/router.

Thoughts On Bitmessage

As my mind rambles around the current political and operational environment that Bitmessage finds itself in I feel that:

1. The protocol is very easy to compromise with a reasonably robust man-in-the-middle attack--and that capability is in place now.
2. The code base is controlled, but fragmented, not independently verified in operation, and has not been peer reviewed to ensure it follows a defined protocol with no other "operating mode(s)."
3. The protocol appears to not have been peer reviewed to ensure it accomplishes the goals defined.
4. Besides a forum and this "self organizing" wiki there does not appear to be any standards organization or formal documentation design or repository.

It may be useful to begin to define an overall structure for the needed documentation and discussions, in highly managed configuration control environment, to help focus and protect the good work being done. As part of this structure we could defined trust or verification rankings for work products and validation suites for code and tools against a validated protocol.

Possible Stucture?

1. Introduction
   1. Description of the Need
   2. Vision / Goals of the Protocol and Tools
   3. Current Operating Environment
   4. Non-Technical Key Risks
   5. Cryptography Key Risks
   6. Other Risks
2. Theory and Proof of Operation
3. Protocol Specification
   1. Network Transmission Data Structure
   2. Payload Routing

Protocol Goals

• Asynchronous, Queued, Batched Delivery
• Delivery Confirmation
• Anonymous, If Desired
• Sending Address Non-Repudiation
• Private to Receiving Address

Protocol's Assumed Operational Environment

• All data packets are intercepted en-route from originating host to the terminating host.
  • Metadata about all data packets are captured and made available for real-time and historical analysis. This includes size, time, route, payload, etc.
  • All data packets subject to man-in-the-middle attacks. e.g. The originating host is not sure the packet sent is the one received by the terminating host. The terminating host is unsure of the true source of the data packet received.
  • All man-in-the-middle attacks may use significant amounts of captured metadata from previous transmissions across the entire internet and operate in real-time so as not to be detectable. e.g. Linking data packet through metadata relationships for point-to-point transmissions based on size, timing, content, source, destination, route, etc. This represents core routers collection and analyzing numerous bitmessage data streams in real-time.

Current Protocol Deficiencies

• Published public keys can be compromised by man-in-the-middle attacks during backbone routing.
  • While P2P may be hard to intercept, The Guardian has reported that a P2P protocol/network will be or already is

compromised.

Do I need to put some text here?

Man In The Middle

Given recent revelations in The Guardian and other sources it should be clear by now that as soon as a packet hits the network of any service provider it is likely being scooped up and stored with all of the metadata you could imagine. Given this, how can you be sure that the "man" is in the middle and is always the other party in any two way data exchange?? I mean any information I send out from my client, including my public key, could be intercepted and a man0in-the-middle public key could be forwarded on to the recipient.

The only solution I can see at the moment is a pre-shared encryption key that is used to initially establish the network in a secure fashion. Any ideas on how to do this? My initial thought was postcards or postal letters.

Reference Test

Bob's Reference

More junk.

Protocol Specification - Network Transport Layers

||Layer||Purpose||Description|| | BM-0 | Encrypted Transport | Provides secure and private point to point data transfer between nodes in the peer to peer network mesh. All hosts participating in the peer to peer network mesh are 'nodes' of the mesh. | | BM- | Block Structure and Contents | | BM-1 | Message Routing | Provides routing of messages originating at a client node and traveling through a number of other network mesh nodes and finally to the client node terminating the message. | | BM- | Message Structure | Enables multiple messages or message fragments to be part of the | BM-2 | Message Encryption | Encapsulates a message to ensure it is available only to the desired terminating client node. Other nodes may accept and route the encrypted message during delivery. | | BM-3 | Message Signature | Provides verification of the originating client node. | | BM-4 | Message Structure | Enables | BM-5 | Message Data |

1. An encrypted channel can be created between any two nodes in the network mesh.

 BM-0          (A) >>--encrypted-block-->> (B)
 BM-1          

a. The message is signed using the sender's private key. b. The signed message is encrypted using the recipient's public key. c. The message is broken up into chunks. d. Each chunk is addressed to the terminating client node. e. A mesh node is chosen for each chunk and sent to that mesh node through the encrypted channel. f. Each mesh node receives the chunk, and forwards it to another node until finally all of the chunks have arrived at the terminating client node. g. The terminating client node reassembles the chunks into a message. h. The terminating client decrypts the message.

i. The terminating client node verifies the signature.