Title: Proposing a new approach for BitMessage V2 Post by: greBit on September 20, 2013, 07:53:09 PM Inspired by BitMessage, I would like to develop an 'offline-messaging' solution that is NSA-resistant, and this is an extract from a very early draft of a paper I am writing. I would love some feedback :)
tl;dr
2. System model The network We model the system as a collection of N nodes. Each node maintains at least one connection to another, such that all N nodes can be arranged to form a connected graph. Threat model In line with related work[refs] we opt to exclude consideration of a global active adversary – i.e. one who is capable of controlling the entire network and observing all network traffic. Our threat model, as in [Oct11] and [Salsa06], is that of a partial adversary. The adversary is able to control at most 20% of nodes on our network and act in an arbitrarily malicious manner. Communications can be intercepted, manipulated, forged or silently dropped on any links under the control of the adversary. Design goals The major functional goal is to simply enable one party to efficiently send a message to another, where the recipient can be reasonably assumed to be ‘offline’. It follows that a sender will need to transmit a message to the network where it will be subsequently stored for later retrieval by the intended recipient. The mode of message retrieval remains to be determined and we note that it could operate as either push (like SMS) or pull (like email). We shall therefore state that for the sake of simplicity, we will consider only a pull approach. Our focus is on solving the messaging problem within the context of our specified threat model. End-users should be offered the best protection possible against leaks of their personal data and meta-data, on an increasingly surveilled and hostile internet. The ‘amount of protection’ offered by a solution will be evaluated objectively, using the properties of anonymity [Pfitz05]. 3. A distributed hash table as an overlay network In this section we examine the general case where a DHT forms the underlying overlay network for asynchronous messaging systems. A simple DHT At this point, we deliberately refrain from specifying any single DHT implementation upon which to implement our solutions. There are many in the literature - of particular interest are the renowned Kademlia [Kadem] and the more recent Octopus [Oct11]. We opt to ignore the implementation details and model a simplistic DHT as one which provides the following primitives: Code: DHT-GET(key) # find the value associated with key It is generally the case [Refs] that the key is derived directly from the value itself by performing some hash function. A key of this form will be denoted as a Content Hash Key (CHK), in common with [Freenet02]. Limitations of CHK based DHTs Whilst the simple DHT scales well and enables the efficient storage and retrieval of data, it is too restrictive to be used as-is for our overlay network. Critically we note that CHKs prevent the use cases which rely on having access to a key whilst having no knowledge about the value associated with it. Forcing recipients to have prior knowledge of each message before they can be retrieved is clearly counterproductive. To solve this we must introduce another value-keying scheme – the Random Hash Key (RHK). RHKs bear no relation to the values with which they are associated. They can be considered as simply a random sequence of bytes. Messaging primitives and message-slots We can introduce the following primitives for the sending and receiving of messages, implemented analogously to DHT-PUT and DHT-GET: Code: MSG-SEND(msg-slot, msg) # DHT-PUT(msg-slot, msg) We should stress that each message is uniquely identified by its message-slot (RHK) and that in order for two parties to communicate they must previously agree on which message-slots to use. For example, Alice can send a message to Bob, over a previously agreed message-slot (msg-slotBob), as follows: Code: Alice) MSG-SEND(msg-slot_Bob, “hello Bob”) Deterministic message-slots Since a message-slot can only ever be used once, it is important that ‘fresh’ message slots be communicated to the other party on a regular basis. A better solution would be to use a deterministic slot-generation mechanism, in which case only the initial ‘seed’ has to be shared. The following example shows how this could work:
Code: msg-slot_0 = SHA256( seed_Alice + 0 ) Keeping messages private Since all values stored in the DHT are readable by anyone, the only way to keep messages private is by employing encryption. Prior to engaging in communication, two parties must therefore agree on a message-slot sequence and a set of cryptographic keys to use. In order to simplify the process we propose a pragmatic solution, based on the idea of ‘deterministic wallets’ in Bitcoin [Refs], where a sequence of public-private key pairs are deterministically generated from a seed value. To see how this could work in practice, let us reconsider the example of Alice sending a message to Bob:
Code: public-seed_Bob = private-seed_Bob × G # where G is the ECC generator
Code: public-key_0 = public-seed_Bob + 1×G
Code: msg-slot_i = SHA256( public-key_i ) # for any integer i
Code: private-key_0 = G×(private-seed_Bob + 1) Starting a conversation: handshake over a back-channel Every communication medium has, to some small degree, a setup-phase where the conversation participants share enough information in order to proceed. For example, email conversations start by sharing knowledge of email addresses while users of BitMessage must share their public-keys. From the recipient’s point of view, the setup-phase is passive. It is enough to publish an email address or a BitMessage public-key to invite people to converse with you. However, In our system the process requires a ‘handshake’. A recipient, Bob, has to actively provide seed values to anyone he wishes to receive messages from. This is especially advantageous as an anti-SPAM measure:
The drawback of this approach is that it requires this extra handshake step before a message can be sent to a recipient. Although this is not a huge problem, it may be a cause of frustration for some users who just want a simple email-like paradigm, where a textual address is all that is needed to send someone a message. We will later show how this can be achieved through the use of message relay providers. One-one communication (private messaging) Having previously exchanged their seed values, Bob can proceed to send a message to Alice.
We assume that there is some back-channel over which Alice and Bob can ‘discover’ each other and exchange their respective message-slot/public-key generation seeds.
One-many communication (publishing) To publish a message to a group of people we need to transmit (over a back-channel) the public-seed value, as well as any cryptographic keys, to every intended recipient. This allows a recipient to know which message-slots to check and how to decipher any messages that arrive. However, the problem with each member being aware of the message-slot sequence is that it leaves the publisher open to attack, namely:
To solve this we need to introduce a new DHT value-keying scheme called Signed Hash Keys (SHKs). Each SHK will include the public-key of the authorised entity, who has the sole ability to perform a DHT-PUT to keys of this form. Many-many communication (forum) We can consider the ‘forum’ mode of operation, where there are many senders and recipients in a single conversation, as follows:
The problem with this is that it could become quite chaotic. There is no protection against SPAM nor denial-of-service replies (maliciously using up large quantities of message-slots). Some things we could do:
4. Improvements
... Title: Re: Proposing a new approach for a BitMessage sequel Post by: greBit on September 21, 2013, 11:05:00 AM Edit: a new title
Title: Re: Proposing a new approach for a BitMessage sequel Post by: virtualmaster on September 22, 2013, 01:06:27 PM It seems to be an interesting project.
4. Improvements This would be the advantages over Bitmessage ?
How could be compared to Bitmessage in anonymity, comfortability and speed ? Title: Re: Proposing a new approach for a BitMessage sequel Post by: greBit on September 22, 2013, 04:37:39 PM 4. Improvements This would be the advantages over Bitmessage ?
How could be compared to Bitmessage in anonymity, comfortability and speed ? Im not really try to compete with BitMessage in terms of features. BitMessage is fantastic but its claims about keeping you anonymous cannot be justified. The attack surface is large, the protocol is loosely defined and there is no proper whitepaper that can allow security researchers to fully understand the system. I think we need to take a step back, examine the core problem of `sending/receiving offline messages` in the context of existing, peer reviewed, research. We can immediately see that BM is by no means novel. Freenet/I2P/... have been around for a decade and solve an almost identical problem. My attempt here is to try and build a simple messaging solution as a very light abstraction layer above a distributed hash table (like Freenet).
|