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

[Sergio_Demian_Lerner]

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.

Right. It seems at a first glance that the signature verification would stop the ACK from being sent.

Still the attack can be executed using a timing attack. It's easy to detect if 100 RSA blocks are being decrypted or just only two. You send another message right after the Bleichenbacher message. If it takes one second to process, then 100 blocks have been decrypted. If it takes 100 msec, then only two blocks have been decrypted.
I'm sure there are still other ways to detect the correct/incorrect PKCS padding and carry the attack.

When a crypto protocol shows many vulnerabilities, then is better to make a pause and re-design carefully from scratch than to start patching.

I recommend you that you first write a technical paper on the crypto protocol, and send it to some researchers for them to analyze. If they say is ok, then go on and implement it. I offer my free advise to read the paper and give it some thought.

Last, there is still another vulnerability in the anonymization logic: If a node X receives a message and immediately sends an ACK then an attacker Z connected to X can detect that X is the receiver of the message.

To deter this attack nodes should continuously send messages at a fixed rate, creating new ones (with no destination) when no new message is received. Other solution is that nodes should be protected with Tor at all times. I will post about this in the bitmessage forum.


Best regards,
 Sergio.

PS: I never meant to say that the idea is bad. Go ahead and improve it!

[1714773071]

1714773071

[kjlimo]

I didn't have time to catch up on this forum yet, but I thought I'd leave these two thoughts/links:

http://bitcoinmagazine.net/bitmessage-a-model-for-a-new-web-2-0/

How is this better/different from https://www.mywickr.com/

I'll be back later to read responses.

[caffeinewriter]

I didn't have time to catch up on this forum yet, but I thought I'd leave these two thoughts/links:

http://bitcoinmagazine.net/bitmessage-a-model-for-a-new-web-2-0/

How is this better/different from https://www.mywickr.com/

I'll be back later to read responses.

Wickr -

• Closed Source
• Only for iPhone (Android coming soon)
• Written in (Objective-C? Cocoa?)

BitMessage -

• Open Source
• Cross-platform
• Written in Python

Its architecture is also "based partially on Bitcoin", which I'm going to guess %99 of us use.

[kjlimo]

I didn't have time to catch up on this forum yet, but I thought I'd leave these two thoughts/links:

http://bitcoinmagazine.net/bitmessage-a-model-for-a-new-web-2-0/

How is this better/different from https://www.mywickr.com/

I'll be back later to read responses.

Wickr -

• Closed Source
• Only for iPhone (Android coming soon)
• Written in (Objective-C? Cocoa?)

BitMessage -

• Open Source
• Cross-platform
• Written in Python

Its architecture is also "based partially on Bitcoin", which I'm going to guess %99 of us use.

What is this "bitcoin" you speak of?  

thanks for the response!  Very helpful.

I'll add that Wickr has been mentioned on NPR; while Bitmessage has not.

[caffeinewriter]

I didn't have time to catch up on this forum yet, but I thought I'd leave these two thoughts/links:

http://bitcoinmagazine.net/bitmessage-a-model-for-a-new-web-2-0/

How is this better/different from https://www.mywickr.com/

I'll be back later to read responses.

Wickr -

• Closed Source
• Only for iPhone (Android coming soon)
• Written in (Objective-C? Cocoa?)

BitMessage -

• Open Source
• Cross-platform
• Written in Python

Its architecture is also "based partially on Bitcoin", which I'm going to guess %99 of us use.

What is this "bitcoin" you speak of?  

thanks for the response!  Very helpful.

I'll add that Wickr has been mentioned on NPR; while Bitmessage has not.

Well BitMessage has been around for only about a week from what I can tell. (OP Date is November 28, 2012, 06:13:37 PM), and Wickr was first mentioned on Forbes back on June 27th, so it's got a little bit of a head start.

Edit: Ocay, it was apparently up on Nov. 11th, and second commit to Github was on the 18th.

Also, a message to Atheros, I miss the website   Any ETA on it being not not up?

[Atheros]

Also, a message to Atheros, I miss the website   Any ETA on it being not not up?

The forum is up but I am having database corruption with the Wiki and may have to restore from the backup which is a couple days old which I am trying to avoid.

All back up. The wiki database is from a backup several days old. I expect no problems on my new host. Please pardon the downtime.

[bracek]

Does it require the receiver and sender to be online at the same time like retroshare does ?

[bracek]

woow, I just tried it with a friend,
it really works

p2p e-mail, I have been looking for this for a long time.

[Atheros]

Does it require the receiver and sender to be online at the same time like retroshare does ?

No, although if the receiver is offline for more than two days then the sender will have to resend the message (the client does this automatically) because the network will clear the old message from memory.

This "two days" value can very easily be changed if people agree that it should be changed.

[lenny_]

New version 0.1.3 released 18th of December. Where is changelog? Why there is not update on forum thread?

[Atheros]

New version 0.1.3 released 18th of December. Where is changelog? Why there is not update on forum thread?

Here is the Changelog: http://bitmessage.org/wiki/Changelog
New version 0.1.4 released today.
I'll update the forum thread more when Bitmessage is upgraded to use ECC.

New features in 0.1.4:

    Added support for SOCKS4a and SOCKS5 proxies
    Adjusted UI so that it looks appropriate on OS X
    Changed UI to accept Bitmessage addresses which lack a "BM-". This makes copying and pasting easier.
    Fixed OS X issue: if user minimized client to tray then restored, segmentation fault occured
    Added locks to prevent ill-effect if the client receives the same object from two different nodes at the exact same time
    Commented out code that prevents the client from accepting a second connection from the same IP since this prevents users from running two clients within the same local network. When the Bitmessage network grows, this code will be re-enabled.

[Xenland]

Whoa... How did i miss this, I'm working on a C version of P2P encrypted messaging using RSA, I like your white paper looks like it describes an anti-spam measure like hashcash(or comparable to bitcoin)

https://github.com/Xenland/P2P-Crypt

[Red Emerald]

Reminds me of Liberté Linux's cables.

http://dee.su/cables

http://webcache.googleusercontent.com/search?q=cache:XllaEDPyAjAJ:dee.su/cables+liberte+linux+cable&cd=2&hl=en&ct=clnk&gl=us

[OpenYourEyes]

I'm excited for this, and I hope it gets more attention and developers on board; pretty amazing concept IMO.

[HostFat]

I'm trying to use Bitmessage through Tor proxy, but it doesn't seem to work.
It connects, but it seems not sending/receiving anything.

[lenny_]

New version 0.1.3 released 18th of December. Where is changelog? Why there is not update on forum thread?

Here is the Changelog: http://bitmessage.org/wiki/Changelog
New version 0.1.4 released today.
I'll update the forum thread more when Bitmessage is upgraded to use ECC.

New features in 0.1.4:

    Added support for SOCKS4a and SOCKS5 proxies
    Adjusted UI so that it looks appropriate on OS X
    Changed UI to accept Bitmessage addresses which lack a "BM-". This makes copying and pasting easier.
    Fixed OS X issue: if user minimized client to tray then restored, segmentation fault occured
    Added locks to prevent ill-effect if the client receives the same object from two different nodes at the exact same time
    Commented out code that prevents the client from accepting a second connection from the same IP since this prevents users from running two clients within the same local network. When the Bitmessage network grows, this code will be re-enabled.

Link to changelog should be visible on main page - http://bitmessage.org/wiki/Main_Page
Right now, there is no way to find it.

[fbastage]

very cool. glad to find this.

would like to see if this could be a good fit to replace our reliance on IRC for OTC trading.

the issues with using IRC are:
- multiplicity of systems (irc with nickserv identification vs. bot-based gpg/btc authentication), not tightly integrated
- relying on third party to provide network of irc servers
- IRC very liberal in allowing anyone to use any name (except where registered and enforced through nickserv)
- no default IRC security/authentication

it's a big headache for new users and a gold mine for scammers.  but even if you are not directly a victim, the prevalence of scamming still adds to the cost of doing business or discourages new adopters in the economy.

I understand that bitmessage might not be ready for primetime, but I'd be glad to explore it and see what we can make of it for future use.

[Atheros]

very cool. glad to find this.

would like to see if this could be a good fit to replace our reliance on IRC for OTC trading.

the issues with using IRC are:
- multiplicity of systems (irc with nickserv identification vs. bot-based gpg/btc authentication), not tightly integrated
- relying on third party to provide network of irc servers
- IRC very liberal in allowing anyone to use any name (except where registered and enforced through nickserv)
- no default IRC security/authentication

it's a big headache for new users and a gold mine for scammers.  but even if you are not directly a victim, the prevalence of scamming still adds to the cost of doing business or discourages new adopters in the economy.

I understand that bitmessage might not be ready for primetime, but I'd be glad to explore it and see what we can make of it for future use.

I've never used the OTC market but if those are the issues then it certainly seems like it would be useful. Identities could simply be a Bitmessage address and wouldn't need to be registered. People might want a way of displaying nicknames in the market but it must be clear to newbies that anyone can set their nickname to anything they want. Pardon my ignorance but I have a question: If the web-of-trust is centralized (which I am currently under the impression is the case), why isn't the messaging system also?

-------------------------------------------

Current upgrade status: New encryption library is working; Currently writing paper describing updated protocol; new protocol message specification is up on the wiki though it is still subject to change.

[fbastage]

If the web-of-trust is centralized (which I am currently under the impression is the case), why isn't the messaging system also?

I think IRC is used as a messaging platform out of convenience.  but this lends to various issues in the system (imposters, unauthenticated/unverified users, confusion).

since we don't control the connect/login process of IRC (most newer users use the webchat irc client, and have no pre-registered NickServ identity) we can't enforce or even educate new users at that point about registrations.  While we could make the formal OTC channel require registration and identification, that will either exclude such users that don't know about registration, or push them to another channel (often called the "foyer") with less supervision of experienced and helpful users; there they are even more vulnerable to malicious users.

one solution might be to run our own ircd, with perhaps some modifications or an informative MOTD (but who reads those, really? especially among new users?), but this has it's own challenges and requires resources.  and this is getting off topic for this thread so I'll stop here.

--------

given these concerns, how could they be addressed or remedied with bitmessage?  (and maybe this merits a separate thread as well, rather than cluttering up this one)

-fb

[Atheros]

given these concerns, how could they be addressed or remedied with bitmessage?  

I suppose that depends on how the imposters confuse people. If they trick people into believe that they are someone else by using a trusted username in the wrong channel or if they pretend to be new users by changing their nick to that of the new user who failed to register it, then Bitmessage would help by
1. Making it impossible to change one's identity to that of another person
2. Avoiding the whole registering a username issue except to add your Bitmessage address to the web-of-trust.

However Bitmessage lacks the same chatroom interface as IRC. Bitmessage is more like email currently. Chatrooms could be implemented if users reveal their IP to a server (or use Tor). So far I haven't thought of, and no one has suggested a way to do IM or chatrooms without revealing one's IP (without Tor).