[ANNOUNCE] Bitmessage - P2P Messaging system based partially on Bitcoin

[caffeinewriter]

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/

So right now it's nothing more than a novel toy. Definitely not ready for the big time, but it's still a neat concept. There are definitely numerous improvements needed, but I still think it's a novel idea.

[1714145277]

1714145277

[1714145277]

1714145277

[Atheros]

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/

So right now it's nothing more than a novel toy. Definitely not ready for the big time, but it's still a neat concept. There are definitely numerous improvements needed, but I still think it's a novel idea.

It's true that it isn't ready for the big time. I used a Python RSA library that I did not create myself in the hopes that releasing a working program would create interest and that if people liked the Bitmessage concept, we could upgrade to ECC.  It was never my wish to use RSA but I could not find a Python ECC library at the time. Bitmessage addresses purposely include a version number so that the upgrade to ECC can be smooth. I had previously said the same thing on Reddit.

I'm thankful to Sergio for digging into the RSA code and alerting us to the problem. I will put a prominent message on the bitmessage.org page. I apologise for not displaying a more prominent warning about the relatively-unstudied encryption algorithm earlier. If people believe in the Bitmessage concept, we can upgrade to ECC, let everyone who is interested check the encryption implementation, and hopefully end with a useful tool and protocol. One person has already pointed out a potentially useful OpenSSL wrapper.

[caffeinewriter]

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/

So right now it's nothing more than a novel toy. Definitely not ready for the big time, but it's still a neat concept. There are definitely numerous improvements needed, but I still think it's a novel idea.

It's true that it isn't ready for the big time. I used a Python RSA library that I did not create myself in the hopes that releasing a working program would create interest and that if people liked the Bitmessage concept, we could upgrade to ECC.  It was never my wish to use RSA but I could not find a Python ECC library at the time. Bitmessage addresses purposely include a version number so that the upgrade to ECC can be smooth. I had previously said the same thing on Reddit.

I'm thankful to Sergio for digging into the RSA code and alerting us to the problem. I will put a prominent message on the bitmessage.org page. I apologise for not displaying a more prominent warning about the relatively-unstudied encryption algorithm earlier. If people believe in the Bitmessage concept, we can upgrade to ECC, let everyone who is interested check the encryption implementation, and hopefully end with a useful tool and protocol. One person has already pointed out a potentially useful OpenSSL wrapper.

I hope to see continued development of this project. And perhaps a "key exchange" where users can get in touch with each other. And an "ignore function", where it will refuse to give up the public key to ignored users. I'm not sure of the difficulty of implementing this, but it'd be nice to see.

[Atheros]

A few complaints. Due to firewall restrictions, I'm only able to connect through a handful of whitelisted ports. It'd be nice if the program could automatically determine an open one to use. Second of all, I have to click on my "From" address in order for it to populate the from field, despite it being selected by default.

I purposely have one of the default bootstrap nodes running on port 8080 for this reason. It is usually a whitelisted port.
When you say you want the program to automatically determine an open port, do you mean for outgoing connections? In this case the port is up to the listening node to set. Hopefully some people will use ports that your firewall will allow and if they do, your client will connect to them.

About the 'From' Address issue, the software has been patched so that it will automatically select the address if you have only one address. If you have more than one, you still must select the desired address. In the case that there is more than one address, if people dislike that it shows an address by default, I suppose we can make it blank by default.

Also I'd like to see the ability to use proxies, which would circumvent my problem I'm having with ports.

This is also a feature I would like.

Looks like its doing some bootstrapping over port 8332 (bitcoin rpc) had me worried for a minute about backdoors.

This may be a silly question, but sending messages is a pretty simple feature and something thats been available for long time in many different p2p softwares.. Retroshare for example is p2p, using cryptographic keys for encryption and privacy.. it allows sending of messages and forums etc.

Not sure what makes BitMessage special?

It appears that someone changed their port to 8332.
About Retroshare I must admit that I did not know about it but I will research it.

[Atheros]

Based on reading the paper I have a few comments. I don't know if the design is set in stone by now or if you're still open to modifications.

Thank you for your long and thoughtful reply Mike. I'm perfectly open to modifications. It's easier to adjust a protocol earlier rather than later. And it appears that encryption algorithm will have to be changed soon regardless.

The streams construction is very clever and I think it could work well. One question is what if I have an old and widely propagated address in a root stream, and eventually it gets overloaded? Some people have to move. But nobody wants to give up their old and well known address.

This is a valid concern. I'm not sure of a solution except that the normal rate of address abandonment could be sufficient to make up for it.
Do allow me a bit of time to digest your other ideas!

[Sergio_Demian_Lerner]

I'm thankful to Sergio for digging into the RSA code and alerting us to the problem. I will put a prominent message on the bitmessage.org page. I apologise for not displaying a more prominent warning about the relatively-unstudied encryption algorithm earlier. If people believe in the Bitmessage concept, we can upgrade to ECC, let everyone who is interested check the encryption implementation, and hopefully end with a useful tool and protocol. One person has already pointed out a potentially useful OpenSSL wrapper.

I think the protocol can be secured but first some things would need to be done:

1. Much better documentation of the inner workings of the message structure / cryptographic functions

This information is missing from the White paper and is crucial to understand the protocol.

2. Find a Security researcher to develop a proven encryption/signature design.

Either you hire it or you find a one that would do it for free but it must be a guy with deep crypto knowledge.

3. Clean up the source code. Refactor and comment. Isolate security critical parts.

It's a bit messy and does not help in understanding the inner workings of the protocol.

4. RSA is not itself the problem. OAEP padding would have been be much better. But hybrid encryption with chaining is a must.

I suggest using the Integrated Encryption Scheme (DLIES or ECIES).

Good luck!

 Sergio.

[caffeinewriter]

While my software is still unable to connect to peers at all (Red Status) on my current network, I successfully sent a message apparently. Looks like it's working as planned

I'd also love to see default tagging for addresses, in order to maintain the easy sending even with multiple addresses.

[Atheros]

While my software is still unable to connect to peers at all (Red Status) on my current network, I successfully sent a message apparently. Looks like it's working as planned

I'd also love to see default tagging for addresses, in order to maintain the easy sending even with multiple addresses.

If you are disconnected from the network it does the Proof of Work ahead of time and will send it whenever it connects to a peer. The message status probably shouldn't say "message sent" in this case.

Although what if an attacker can separate you from most other peers, like by cutting off the Internet connectivity of an entire country? In this case it Has been sent to peers. The word "Sent" is ill-defined. Ultimately one should just depend on the acknowledgement to judge whether the message has been received I think.

I'll have Bitmessage display a warning in the status bar if you aren't connected to any peers at the time.

[Atheros]

Completely broken security of Bitmessage...

Check my blog post: http://bitslog.wordpress.com/2012/11/30/bitmessage-completely-broken-crypto/

I have been considering the attacks you have described. I still want to move away from RSA, Adaptive chosen-ciphertext attacks (despite being expensive due to Bitmessage's POW requirement) must be more carefully guarded against, and separate keys can be used for encryption and signing after the upgrade as a matter of best-practices. But while the encrypt and decrypt_bigfile function is flawed, I don't believe the flaw you have described could be implemented as an attack against Bitmessage. If an attacker modifies an encrypted message, the receiver will decrypt it but then see that the message signature is invalid: the message signature algorithm is just a signed hash and makes no use of the flawed blocks. The receiver will reject the message as invalid and ignore it.

[doublec]

Because i can not post on the Bitmessage forum,
for some reason

the bitmessage domain seems to be down.

[lenny_]

Website offline: http://www.downforeveryoneorjustme.com/http://www.bitmessage.org/

It's not just you! http://www.bitmessage.org looks down from here.

[Lethn]

Did someone say backdoor?

How do you mean?

Its a term used by hackers and I suspect he's right, what it will probably do is create a security flaw for peoples bitcoin clients that a skilled hacker could probably use to get at their Bitcoins, I suspect if the site is down someone has already found it.

[Deafboy]

Website seems to be down. Please don't let the project die. We need some user-friendly app to communicate privately.

[HostFat]

Even if the site is down and/or the main dev disappeared, there is the source code here
https://github.com/Bitmessage/PyBitmessage

[marcus_of_augustus]

Did someone say backdoor?

How do you mean?

Its a term used by hackers and I suspect he's right, what it will probably do is create a security flaw for peoples bitcoin clients that a skilled hacker could probably use to get at their Bitcoins, I suspect if the site is down someone has already found it.

I'm aware of what a backdoor is .... I just don't see how BitMessage represents a "backdoor". Just throwing out the term does not make it so, just makes the person doing look like a FUD-monger.

I'm sure there are people on slashdot that were saying "bitcoin is a backdoor" also ... it sounds cool if you don't know what you are talking about I suppose.

[Atheros]

Great idea. If you implement discussion boards it may become even more popular than Freenet-Frost.
You can send message to me - BM-2neVjntfgA38WbRufTFoooUrtRpGeNATJ1m

Yes, cool project.
I too would like to add forum-like
functionality to BitMessage.

@Atheros
Do you have any plans for "discussion board" feature' integration ?

Also it would be cool to have deterministically generated addresses
( from some meaningful text, like this :
 "My super cool BM addr_My-TOP-Secret-Password"

PS. I really like your idea.
 Maybe, if you won't do it yourself,
 i will start parallel forum-like
 BM system project.

I hadn't given thought to a forum-like feature. It would be neat indeed. My initial idea on how it could work is this: A 'forum' type message with a field for the thread-name which would be specified by the person who starts the thread and spread through word-of-mouth through some other centralized mechanism OR via search functionality. To join the thread, you would would put the thread name in your Bitmessage client and it would display all messages that have been posted in that thread thus far. This idea has the following problems:
* Spam bots would see popular threads and would be willing to put fourth the POW to spam therein.
* Messages could appear in slightly different orders for different people.

Another option is having the software of the person who started the thread (let us call him Bob) be responsible for receiving thread submissions and broadcasting them. To submit to the thread, other clients would do the POW and Bob would sign the broadcasts and broadcast them. This would guarantee message order because the time in each message from Bob would be accurate (as long as Bob doesn't modify his software and lie). This idea has the problem that Bob could ignore messages from people he doesn't like. I suppose this would give him the ability to act as a moderator. This seems like a workable idea.

Other ideas are welcome and I will politely confirm or deny what I think would or wouldn't work.

Concerning deterministic addresses, if they are possible with Bitcoin then they'll be possible with Bitmessage with one issue: You would also have to remember and specify the address version number and the stream number OR they would have to be stored on disk.  After Bitcoin moves onto the next address version number then Bitcoin deterministic addresses will face the same problem.

[Atheros]

Even if the site is down and/or the main dev disappeared, there is the source code here
https://github.com/Bitmessage/PyBitmessage

Yes, the code is still up to download and run. The main site will be back shortly; I'm abruptly switching hosts.

[Atheros]

Did someone say backdoor?

How do you mean?

Its a term used by hackers and I suspect he's right, what it will probably do is create a security flaw for peoples bitcoin clients that a skilled hacker could probably use to get at their Bitcoins, I suspect if the site is down someone has already found it.

To mitigate this, I hope to host the binaries on SourceForge and used the same management practices used for Bitcoin. I completely understand that many people are hesitant to trust binaries. For them Bitmessage can be run from the source code and there are step-by-step directions on how [Windows] user can do that on the Wiki (which will return tomorrow).

[Atheros]

I hope to see continued development of this project. And perhaps a "key exchange" where users can get in touch with each other. And an "ignore function", where it will refuse to give up the public key to ignored users. I'm not sure of the difficulty of implementing this, but it'd be nice to see.

It's slightly counter-intuitive to try to hide one's public key from a specific person. The current Bitmessage client implements "ignoring" using the blacklist.  So it's already done!

[HostFat]

There is already a project that works as a forum:
http://www.osiris-sps.org

But it isn't completed and it isn't open source.
Anyway devs are still working on it, and they will probably release the new version ( v1.0 ) in 2013 and it will be completely open source