Bitmessage

from Wikipedia, the free encyclopedia
Bitmessage protocol
Family: Internet protocol family
Operation area: Confidential email traffic
Port: 8444 / TCP
Bitmessage in the TCP / IP protocol stack :
application Bitmessage
transport TCP
Internet IP ( IPv4 , IPv6 )
Network access Ethernet Token
bus 		Token
ring 		FDDI ...
Specification: Proposed Bitmessage Protocol
Technical Paper
Version: Revision 1, November 2012
Jonathan Warren
Website: bitmessage.org

Bitmessage is an encryption protocol proposed in 2012 that is intended to enable the confidential and anonymous exchange of email- like messages in a peer-to-peer network . The protocol and the reference implementation are based on Bitcoin technology.

Messages are transmitted encrypted and signed . In contrast to the S / MIME and PGP e-mail encryption protocols, for example , with Bitmessage the sender, recipient and subject line are also transmitted confidentially in order to enable an anonymous exchange of messages. Bitmessage differs from remailing for e-mail in that the anonymity of the sender and recipient is implemented through a broadcast transmission of the messages to all Bitmessage participants.

There is a reference implementation from the developer of the Bitmessage protocol. The PyBitmessage program can be used in a similar way to an e-mail program and, after installation, enables participation in the global Bitmessage network.

Working principle

Recipient anonymity

With the bitmessage protocol, an encrypted message has no direct reference to the sender or recipient. It must therefore be sent to all participants in the Bitmessage network. A subscriber can use the HMAC method to determine whether a message has been encrypted with one of his public keys. If this is the case, he knows that the message is meant for him and he can decrypt it.

As the bitmessage network grows, the number of messages delivered will become large enough to overload a single subscriber's Internet connection. This is why the network divides into groups in good time, the so-called “streams”. A bit message is then only delivered to the members of the stream in which the recipient is located.

Bitmessage addresses

The public key of the recipient is used for encryption. The recipient is the only one who can decrypt the message again, because only he knows the associated private key.

The recipient address is the RIPEMD-160 - hash of the recipient's public key. This reduces the length of the address from 128 bytes to 20 bytes. In order to receive the recipient's public key with the hash, a participant in the respective stream can ask for it using a special message.

The fingerprint, together with the number of the stream in which the recipient is located, is converted into a chain of letters and numbers that can be written down on a piece of paper or dictated on the phone, for example: 

BM‐2nTX1KchxgnmHvy9ntCN9r7sgKTraxczzyE

The prefix "BM-" identifies the character string as a bit message address. The Base58 coding ensures character strings that exclude the confusable characters I and 1 or 0 and O in the display.

Comparison with anonymization of emails

Remailers enable the anonymous transmission of emails . The working principle of remailers is based on the fact that the origin of the e-mail is obscured. Above all, the IP address of the sender should be obscured, since the IP address can be used to identify users.

Remailer

A remailer forwards emails, but removes the sender address and other metadata that could be used to identify the sender. The recipient only sees the IP address of the remailer. In order to increase anonymity, several remailers can be cascaded, i.e. an email is routed through several remailers from different operators. The security of remailing can be further increased by using advanced techniques such as mixing and onion routing . An individual remailer operator or an attacker who can eavesdrop on a remailer should not be able to identify the sender.

Comparison of the operating principles

Remailing aims to anonymize the sender and uses individual servers or server-based networks for this purpose . Remailers interact with the existing e-mail infrastructure so that the recipient can, for example, use their usual e-mail program and mailbox on the server of their e-mail service provider. This allows a sender to send emails anonymously, even if the recipient does not use remailing.

Bitmessage, on the other hand, uses its own peer-to-peer network, in which the sender and recipient are anonymized. E-mail addresses or other parts of the existing e-mail infrastructure are not used. It is therefore not possible to send messages to recipients who do not use Bitmessage.

Vulnerability

The developer Jonathan Warren assumes that an attacker can eavesdrop on or control a single Internet connection, but not the Internet connections of all Bitmessage users. An attacker like the NSA could also eavesdrop on a central Internet node , but also not the Internet connections of all participants.

Under these conditions, an attacker could not determine the exact location or the identity of a Bitmessage user. By listening to Internet nodes, you can narrow down the approximate location of the sender and recipient. By eavesdropping on an Internet connection, an attacker can then identify a bit message user if the attacker suspects a certain bit message user to be connected to an Internet connection.

This article or the following section is not adequately provided with supporting documents ( e.g. individual evidence ). Information without sufficient evidence could be removed soon. Please help Wikipedia by researching the information and including good evidence.
The following three subsections are not used. The listed individual references do not make any statements about bit messages.

Peer attacks

An attacker can take part in the bit message network and operate one or more manipulated bit message clients. The possibilities that result from this are so far unknown.

Deniability

An attacker who succeeds in gaining access to a private key can subsequently decrypt all the messages previously received with the associated bit message address. Even if the messages have been deleted on the computer, it must be assumed that an attacker read and saved them during the transfer. He will also find signatures that prove the authorship of the respective senders. Bitmessage is therefore not suitable for exchanging off-the-record messages , the existence of which those involved subsequently want to deny. Bitmessage shares this weakness with S / MIME, PGP and other asymmetric encryption applications.

However, credible deniability can also be used positively and is achieved when the user makes the address block (including private signing and encryption keys) public. If the address block should be included in the keys.dat file by at least one other person, the original author of the message cannot be determined, since theoretically anyone could have composed the message. However, this step also decrypts all existing messages so that they can be viewed by everyone.

Traffic Analysis

In an attack by Traffic Analysis , only the metadata (sender, recipient, send time, message length, etc.) of a message are considered, not its content. The effects of such an attack on the Bitmessage protocol are still unknown.

Timing attack

Jonathan Warren assumes that a naively implemented bitmessage client is vulnerable to a timing attack . To identify user A, a very large number of messages are sent from user B to node X. Suppose it takes 1 second to forward a message not addressed to user A and 2 seconds for user A to decrypt and view his message. With around 100 messages sent, it would take 100 seconds if A is not using the node, but 200 seconds if A is using the node. This allows A to be identified.

literature

Web links

Individual evidence

  1. ↑ a b c d e f Jonathan Warren: Proposed Bitmessage Protocol Technical Paper. (PDF; 324 kB) Revision 1. In: bitmessage.org. January 14, 2013, accessed February 2, 2018 .
  2. ↑ a b Protocol specification. In: Bitmessage Wiki. Retrieved April 5, 2015 .
  3. ↑ Nikita Borisov, Ian Goldberg, Eric Brewer: Off-the-Record Communication, or, Why Not To Use PGP. (pdf) October 28, 2004, accessed April 5, 2015 (English).
  4. ↑ Plausible deniability. In: Bitmessage Wiki. Retrieved April 5, 2015 .
  5. ↑ Traffic Analysis: Protocols, Attacks, Design Issues, and Open Problems by Jean-François Raymond, July 2000