User:0x20545446

From Bitmessage Wiki
Revision as of 20:19, 6 September 2013 by 0x20545446 (talk | contribs) (trying to figure out a next step for this page;)
Jump to navigation Jump to search

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. Thanks.

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. [1]

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.

  1. News, Among the specific accomplishments for 2013, the NSA expects the program to obtain access to "data flowing through a hub for a major communications provider" and to a "major internet peer-to-peer voice and text communications system".

Reference Test

Bob's Reference[1]

Template:RefList


Protocol Specification - Network Data Structure

 message

[4][12][4][4][...]