Skip to content

Instantly share code, notes, and snippets.

@weakish

weakish/bitmessage-issues.md

Last active August 11, 2018 16:12
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save weakish/cbbd08d81c2c6e205552b9bc1099f944 to your computer and use it in GitHub Desktop.
Save weakish/cbbd08d81c2c6e205552b9bc1099f944 to your computer and use it in GitHub Desktop.
Download ZIP
#bitmessage #issues #email-replacement
Raw
bitmessage-issues.md

Bitmessage Issues

Issues

helpinghand in My Security Analysis of Bitmessage pointed out pitfalls of Bitmessage:

  1. Bitmessage uses an everybody gets everything private information retrieval system.

    This is theoretically proven as anonymous to the set size of users. However, this does not scale well due to huge bandwidth consumption. Thus the size of the user set is limited. Also this causes the network to only hold offline messages for 2 days.

  2. In addition to everybody getting everything, everybody tries to decrypt everything.

    This is very processor intensive.

  3. The addressing system is needlessly complex and could lead to attacks.

    Currently BitMessage does an out of band transfer of address, which is the encoded hashes of the ECC public key, instead of doing out of band transfer of the encoded ECC public keys themselves. The addresses are used to query the network for the public keys. Requesting public keys in this way is probably an attack vector.

  4. Lack of link level encryption leads to total anonymity compromise in the face of a local external attacker

  5. Even with link level encryption and layer encrypting outgoing messages with the acknowledgement system, a local external attacker can link Alice to her BitMessage address with a spam + packet counting attack.

  6. Use separated ECC keys for signatures and encryption is unnecessary.

  7. Using long term public ECC keys for secret derivation is inproper.

    Proper use of ECC involves Alice and Bob exchanging long term public keys, these can be used for ECDSA. When Alice wants to send a message to Bob, first she generates an ephemeral ECC keypair, she uses Bob's long term public ECC key with the ephemeral private ECC key to derive a shared secret (with ECDH presumably) , which is then hashed into the session key. Now Alice can delete her ephemeral private key, she attaches the ephemeral public key to the outgoing message to Bob, and symmetrically encrypts the message payload data using the derived session key. Every single outgoing message should have an ephemeral public key attached to it.

Notes

  1. Alternative approach: every node gets a blockchain of metadata of messages (including an index of objects).

    Message bodies are stored in objects. Unlike metadata and index, Objects are not fully distributed. Instead every node has some objects such that for a network of n nodes, every k nodes have all objects.

    The problem is how to ensure every node keep the objects? Since node get all the metadata, it may only keep related objects and cheat others.

  2. Peter Šurda pointed out "the decrypting is done in a different thread, so the timing attack is more difficult."

    helpinghand suggested a signaling system:

    Have the users pairwise exchange random string pairs (this can be accomplished with the initial long term ECDH key exchange + iterative hashing of the derived shared secret). ... The first message Alice sends to Bob is tagged with the hash of the concatenation of the two strings ... The newly derived string replaces the second string Alice gave to Bob, and the next message Alice sends Bob is tagged with the hash of the concatenation of the string pairs again ... etc. The newly derived string replaces the second string Alice gave to Bob, and the next message Alice sends Bob is tagged with the hash of the concatenation of the string pairs again. Attackers can see the strings messages are tagged with, but they cannot gain any information from them without knowing the original strings derived from the pairwise ECDH key exchange between Alice and Bob.

    The problem is the user need to store/keep secret/sync of the random string pairs for each contact. A workaround is to also include secret string pairs in message bodies, thus if the contact database is lost, the user can fall back to decrypt all messages until contact database is fully rebuilt. To speed up contact database rebuilding, the user may ask the counterpart about the secret pair instead.

    If we choose the alternative approach mentioned above, then everyone only needs to decrypt all metadata, not all messages.

    Although the above signaling system can also be applied to metadata for further optimization. And fallback to decrypting all metadata will be more efficient since metadata is much smaller or preserves long term record.

  3. The address should just be the public key.

    Like ZeroNet.

  4. v0.6.0 (2016-05-03) added TLS.

  5. v0.6.0 (2016-05-03) mitigated this deanonymisation attack.

    Now quickly asking a large number of nodes if they have an ACK object to estimate how an object propagates through the network, eventually pinpointing an originating IP address of the injection, i.e. the IP address of the message recipient, is more difficult than previous versions. Because nodes will stall when asked for a nonexisting object, and also upon connection before sending its own inventory list. It estimates how long a short message takes to propagate through the network based on how many nodes are in a stream and bases the stalling time on that.

  6. Encryption, partially encryption of message body, could use AES.

    AES is fast, especially with recent CPUs with AES New Instrument.

So 2, 3, and 6 are still exist for bitmessage.

License: 0BSD

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment