Bitmessage v0.2.0 - Now using Elliptic Curve Cryptography!

[Atheros]

This is a major upgrade and includes these exciting features:

• Elliptic curve secp256k1 is used for Bitmessage's signing and asymmetric encryption.
• Keys are stored in Wallet Import Format in the keys.dat file which can be opened with any text editor
• Deterministic addresses
• Addresses are shorter (without sacrificing strength). They are now the same length as Bitcoin addresses (except for the BM- prefix)

Bitmessage now uses an OpenSSL wrapper for its cryptographic functions.

https://Bitmessage.org

Short Introduction: Bitmessage is a P2P communications protocol which is used to send encrypted messages to another person or to many subscribers. It is decentralized and trustless, meaning that you need-not inherently trust any entities, like root certificate authorities. It also aims to hide "non-content" data, like the sender and receiver of messages, from eavesdroppers.

Here is the whitepaper!

You'll notice that Bitmessage prompts you to delete your old version 1 addresses if you have any. This is because old RSA addresses will no longer be supported. Deleting your addresses is optional and you can still send messages between v1 addresses but not between v1 and v2 addresses. During the upgrade I decided that it would be worth it to make large backwards-incompatible changes to the protocol in order to make it more logical and consistent. This will help others develop their own clients in the future but has the side effect that v1 address cannot be used to send messages to or from future address versions without more programming (and complexity).

Keys are interchangeable between Bitmessage and Bitcoin. Bitmessage even prints the other party's Bitcoin address in the console which it generates from their public key (along with a warning to be careful). I have tested this with real bitcoins: Alice sends a message to Bob. Bob sees Alice's Bitcoin address when he receives the message (in the console output) and sends a bitcoin. Alice opens her keys.dat file and copies the private signing key, which is stored in wallet import format, and imports it into Bitcoin (I used blockchain.info's wallet because they make it easy to import a private key). This feature is meant as a proof-of-concept; please don't play with significant amounts of money.

Security warning: An active attacker who sends many messages to a particular address in a particular way may be able to determine whether or not the address is owned by a user at that particular Internet connection. Further research is needed. I believe, however, that users are safe from passive attackers, like government intelligence agencies in most cases. Users are also perfectly safe subscribing to broadcast messages from others.

To report issues please use the Github issue tracker if you have a Github account, otherwise you can reply here or send me a private message.
I look forward to wider audiences for Bitmessage and Bitcoin in the future!

-Jonathan

[1715153130]

1715153130

[1715153130]

1715153130

[1715153130]

1715153130

[1715153130]

1715153130

[1715153130]

1715153130

[1715153130]

1715153130

[HostFat]

Good, I'll give a try on next days

[marcus_of_augustus]

Gonna test this out.

[stevegee58]

Hey Atheros, I noticed that when I send a message the CPU maxes to 100% for about 2.5 minutes.  I assume this is the lengthy ECC crypto algorithm running.
Surely this could be offloaded to a GPU using OpenCL (Hint hint)

Also I noticed that it's rather hit-or-miss if I fully connect to the network.  I've correctly forwarded port 8444 but sometimes I never get the green light (stays at yellow).  If I restart I get the green light right away.

[Atheros]

Hey Atheros, I noticed that when I send a message the CPU maxes to 100% for about 2.5 minutes.  I assume this is the lengthy ECC crypto algorithm running.
Surely this could be offloaded to a GPU using OpenCL (Hint hint)

Also I noticed that it's rather hit-or-miss if I fully connect to the network.  I've correctly forwarded port 8444 but sometimes I never get the green light (stays at yellow).  If I restart I get the green light right away.

The cryptography is done almost instantly; what is taking time is the proof of work. This could be offloaded to GPUs but if I or someone else worked on (and accomplished) this, I would just need to raise the difficulty of the work right back up again to make it take just as long. Or I would choose to switch to a GPU-hard algorithm (if one even exists. (I am aware of scrypt)).

It's very strange that you sometimes never get the green light (an incoming connection) and sometimes you get one instantly.

[imanikin]

It worked <0.2.4, but now doesn't show the UI, unless started as admin on my Win7 32. I see 2 exe instances open in processes, but no UI as a non-admin user.

Also, need a digital sig or at least some hash sums or a gpg sig for the executable somewhere, so that we know it's legit. No encryption/security app can be taken seriously these days, if the developer doesn't sign it, no matter what kind of code audit it undergoes...

Look forward to this promising project mainstreaming! Thank you for your great work!

[casascius]

Nice work.  My comments:

1.  I think BitMessage is a great idea.  I think two different things should be proposed independently:  1 - how to construct a BitMessage-encrypted message, and 2 - transport and delivery.  A single proposal that dictates that a message should be composed "this way" and then delivered "that way" is less scalable.

2.  I am not sure you should propose a new way to deliver mail through peer to peer nodes.  The most popular way to deliver mail, being SMTP, isn't broken, works just fine, and what you're proposing doesn't solve any problem that SMTP is widely recognized to have.  Thus you're proposing something that adds complexity with little benefit.

3.  One place I would suggest you could really get a breakthrough would be the idea of integrating a bitcoin client with a "bitmessage" client.  While to some, this will seem as ridiculous as a refrigerator-with-built-in-toaster-oven, from a user perspective, it is actually a very worthy marriage.  There is a palpable benefit from being able to know you're paying the same person you're talking to, and there's a palpable benefit to having a one-stop-shop for all of your crypto needs, with a certain bonus synergy: if you try one of the functions (payment or messaging) and get comfortable with it, you're likely to transfer that developed trust directly to the other function you haven't yet tried.  In other words, as people hear in the media that "bitcoin works and government can't break it", people will implicitly get the idea that bitmessage works as well, and will be more inclined to trust the strong cryptography it's based upon.  People will rightly infer that "well, nobody can steal my money, so they probably can't read my messages either."

[marcus_of_augustus]

The most popular way to deliver mail, being SMTP, isn't broken, works just fine, and what you're proposing doesn't solve any problem that SMTP is widely recognized to have.

SMTP's default is plain text .... many would argue that is a broken model for a messaging layer on an untrusted network.

Edit: it is like someone invented a postal delivery system without envelopes .... and said, "yah, this works fine" .. let's go with fail.

[imanikin]

1.  I think BitMessage is a great idea.  I think two different things should be proposed independently:  1 - how to construct a BitMessage-encrypted message, and 2 - transport and delivery.  A single proposal that dictates that a message should be composed "this way" and then delivered "that way" is less scalable.

2.  I am not sure you should propose a new way to deliver mail through peer to peer nodes.  The most popular way to deliver mail, being SMTP, isn't broken, works just fine, and what you're proposing doesn't solve any problem that SMTP is widely recognized to have.  Thus you're proposing something that adds complexity with little benefit.

3.  One place I would suggest you could really get a breakthrough would be the idea of integrating a bitcoin client with a "bitmessage" client. 
...

No. 1 i don't understand, and No. 3 goes without saying to me, once BitMessage is more developed.

With No. 2, i don't agree. Most people don't run their own SMTP servers, and use SMTP, POP or webmail on some third parties' servers. So, if the government wants to put those public accounts known to be someone's under surveillance, track one's contacts, etcetera, or shut them down, the workarounds are technical and expensive. Even so-called privacy email services like hushmail have in the TOS that they will allow those with proper papers to spy on your account...

GPG continues to be too much of a pain for the average user, precisely because it's an add-on on top of the SMTP system, which was not designed for privacy or personal control. That's one reason why 20 years or whatever since Zimmerman came out with it, pgp is still not commonly used or even known outside the geekoid community...

After those, one is stuck with darknet mail, such as I2P, which require more technical know-how, and are best suited for anonymous comm anyway...

So, i think BitMessage exactly addresses the same privacy and personal control problems of email via SMTP that Bitcoin addresses for existing "most popular" payment systems.

[Atheros]

1I think two different things should be proposed independently:  1 - how to construct a BitMessage-encrypted message, and 2 - transport and delivery.  A single proposal that dictates that a message should be composed "this way" and then delivered "that way" is less scalable.

They are implicitly related. For example, a bitmessage doesn't show the recipient's address in cleartext; it is encrypted. This means that it couldn't be efficiently used in any email-like delivery system where the need for the recipient's address is obvious.

2.  I am not sure you should propose a new way to deliver mail through peer to peer nodes.  The most popular way to deliver mail, being SMTP, isn't broken, works just fine, and what you're proposing doesn't solve any problem that SMTP is widely recognized to have.  Thus you're proposing something that adds complexity with little benefit.

Bitmessage may be able to hide the sender and receiver of messages from passive eavesdroppers. Also unlike SMTP, Bitmessage doesn't rely on federated servers which can be corrupted either willfully or by court order. With email, there also clearly isn't an easy way to enable encryption and authentication. Even people who know how to use PGP rarely use it. It could be more smartly integrated into email clients, but people still will be vulnerable to man-in-the-middle attacks which switch out the public key hash with the attacker's. People don't understand what a public key hash is. With Bitmessage on the other hand, people will implicitly understand the need to be careful to avoid having their address switched out by an attacker because the implications will be obvious: their mail will go to the attacker. The big advantage of Bitmessage is that it is secure even when used by a lazy public.

integrating a bitcoin client with a "bitmessage" client.  ...  People will rightly infer that "well, nobody can steal my money, so they probably can't read my messages either."

Indeed. Someday!

[casascius]

1.  I think BitMessage is a great idea.  I think two different things should be proposed independently:  1 - how to construct a BitMessage-encrypted message, and 2 - transport and delivery.  A single proposal that dictates that a message should be composed "this way" and then delivered "that way" is less scalable.

No. 1 i don't understand, and No. 3 goes without saying to me, once BitMessage is more developed.

By #1 I'm pointing out that you're proposing two different unrelated things in the same proposal.  One is how to encrypt the message.  The other is how to get the message from its sender to its recipient.  These are two different problems with two different solutions.  This will have the same problem as a fish dish recipe that also specifies a certain way to catch the fish, namely, the idea can't scale past being useful but to someone who both catches and cooks the fish.

With No. 2, i don't agree. Most people don't run their own SMTP servers, and use SMTP, POP or webmail on some third parties' servers. So, if the government wants to put those public accounts known to be someone's under surveillance, track one's contacts, etcetera, or shut them down, the workarounds are technical and expensive. Even so-called privacy email services like hushmail have in the TOS that they will allow those with proper papers to spy on your account...

GPG continues to be too much of a pain for the average user, precisely because it's an add-on on top of the SMTP system, which was not designed for privacy or personal control. That's one reason why 20 years or whatever since Zimmerman came out with it, pgp is still not commonly used or even known outside the geekoid community...

So running something that downloads and uploads every message anyone sends to anyone on the entire network is going to be easier than using GPG or an SMTP server?  All because the government is going to be monitoring the only SMTP server in the whole world (joke of course)?  Which is only reachable via plaintext and not SSL (joke of course)?  You're proposing boundless exponential resource consumption for illusory convenience.

With all due respect, you haven't thought this one through.  It's a screen door submarine with wood trim.

The only thing standing between easy access to encryption and the public is for someone to make it simple to understand and use.  This idea is the opposite of that.  If Android phones and jailbroken iPhones added a simple way for people to bump their phones and exchange keys IRL and use them regularly for SMS and e-mail, people would be using it every day.

My suggestion would be that you focus on defining in detail how a BitMessage address is constructed and how the encryption works, and not mess with inventing a new kind of e-mail transport.

[Atheros]

My suggestion would be that you focus on defining in detail how a BitMessage address is constructed and how the encryption works, and not mess with inventing a new kind of e-mail transport.

Then let us suppose then that messages are encrypted and authenticated the way they are now in Bitmessage, or something very similar. What should be the transport?

[imanikin]

...
If Android phones and jailbroken iPhones added a simple way for people to bump their phones and exchange keys IRL and use them regularly for SMS and e-mail, people would be using it every day.
...

IF my grandma had balls, she would be my grandpa! 

We've heard some version of this from the techies for more than 20 years now; it's an illusory outcome for the PKI/PGP submarine after 2 decades, no matter what kind of wooden trim and screen doors are put on it. Most iPhones and Androids are not jailbroken, not to mention that their users don't know what that means or how to do that...

Neither do they know how or bother to set up TSL/SSL on POP clients, because it's a geeky hassle, and not always supported by the provider. Most either don't know or think it's unavoidable that their email can be read by the email provider employees, SMTP operators and government agents. All of their contacts are easily identifiable through the SMTP addressing scheme. Snail mail has more privacy, because one can at least sometimes tell when someone tempered with the envelope...

With Bitmessage scaling problems, who knows. Perhaps, the solution will be the same as Electrum is for Bitcoin... 

What's clear is that Phil Zimmerman's vision of universal email privacy is still waiting for "someone to make it simple to understand and use" 22 YEARS later!   

It's long overdue to try new approaches, including new email transport that is based on end-to-end encryption and decentralization by default!

[casascius]

My suggestion would be that you focus on defining in detail how a BitMessage address is constructed and how the encryption works, and not mess with inventing a new kind of e-mail transport.

Then let us suppose then that messages are encrypted and authenticated the way they are now in Bitmessage, or something very similar. What should be the transport?

SMTP... or whatever better future transport works better than SMTP.

Given that SMTP is well established, if one wants to take upon themselves to create a better transport, it's going to take a lot more than just a 5-page paper that suggests in vague terms devoid of technical details that everybody's e-mail (plus attachments) must be sent to everybody so that nobody will know where any given message is destined.  This is unsustainable in a rather obvious fashion to anyone doing some pencil arithmetic.

We've heard some version of this from the techies for more than 20 years now; it's an illusory outcome for the PKI/PGP submarine after 2 decades, no matter what kind of wooden trim and screen doors are put on it. Most iPhones and Androids are not jailbroken, not to mention that their users don't know what that means or how to do that...

This isn't because it can't be done, it's because it isn't being done.  If any major mobile phone maker made it so SMS messages used strong encryption with minimal effort (e.g. if public key is found in contacts, encrypt with it by default), drug dealers and criminals all over the world would be flocking to it.

[stevegee58]

Hi Atheros,  I've left my client running for almost 24 hours now and I noticed that sometimes it uses 100% CPU without my doing anything.  I had seen this when I send a message which makes sense but why would it do heavy CPU while idling?

[imanikin]

We've heard some version of this from the techies for more than 20 years now; it's an illusory outcome for the PKI/PGP submarine after 2 decades, no matter what kind of wooden trim and screen doors are put on it. Most iPhones and Androids are not jailbroken, not to mention that their users don't know what that means or how to do that...

This isn't because it can't be done, it's because it isn't being done.  If any major mobile phone maker made it so SMS messages used strong encryption with minimal effort (e.g. if public key is found in contacts, encrypt with it by default), drug dealers and criminals all over the world would be flocking to it.

We don't even need pencil arithmetic to see that this "IF" is a technogeek pie-in-the-sky, which is decades stale, which they continue to dangle at non-techie users from their ivory tower.
SMTP is indeed adequate! ...for a surveillance state! 

Is there even a way to keep one's contacts private, given the SMTP addressing scheme and server-client nature of POP and webmail? If not, then what Atheros is trying to address with Bitmessage actually "can't be done" with SMTP as the underlying protocol.

What is true is that we already have p2p end-to-end encryption in I2P-Bote secure email, which is in alpha, in the I2P net. And there is a Russian developer working on an I2P-bitcoin client.

Perhaps, the best transport protocol for Bitmessage would be I2P. Maybe, to avoid the traditional Open-Source development effort duplication, Atheros, giv, and the I2P developers can all work together to integrate I2P, Bitcoin, and Bitmessage. 

I do applaud Atheros for trying to tackle the lack of email privacy and personal control, which the IT world has yet to make easy for the non-techie users, and hope that he continues to experiment with Bitmessage. One can still hear some call Bitcoin the equivalent of "a screen door submarine with wood trim", which will not scale unless it's integrated with the existing banking and payment systems or fundamentally changed... As always, time will tell. 

[Qwedcxza1]

This is a major upgrade and includes these exciting features:

• Elliptic curve secp256k1 is used for Bitmessage's signing and asymmetric encryption.

What method do you use for asymmetric encryption?
ECIES?
Can you give more details.[/list]