Topic: Idea: Wallet with Encrypted Messaging (Read 1165 times)

I am looking for a source but I think I read somewhere that the encryption system of Bitcoin does not interact with encrypted messages very well. It is good for confirming that a signature came from a particular key, not using the key to unlock a specific message.

This would also be problematic if you are not both "online" at the same time.

There are several layers involved (and also there are two ways to connect... websocket or zmq to the p2p cloud over python).

The protocol is not fully defined, some things are documented in the links i gave you (the more specific can be the Trollnet and DarkWallet/Identity docs), others in the code...

Right now, if you go the websocket way, then you use the chan_post and chan_subscribe ws commands as in https://github.com/darkwallet/gateway/blob/master/client/gateway.js.

How the name and encryption, peering etc is done is now coded under https://github.com/darkwallet/darkwallet/tree/develop/js/backend/channels (we dont use btcchan.js at the moment which is a version using bitcoin encryption...).

I will be reviewing the documentation soon so you (and us!) understand better everything. We now are more or less done with implementing functionality and will be refactoring, cleaning up and getting this into the beta stage. Also we can review and consider options about crypto primitives that we are using.

I see this could be useful actually. My purpose is not to chat with the owner of an other address, but to have a anonymous instant messaging client where I am only identified by a bitcoin address, not by a tracable userid on a centralised server.

If you had to explain me in like few sentences how to connect to your example trollbox.
I'm guessing it uses a websocket to connect to some gateway/obelisk (I don't know whats the difference between the two) - right?

And then, having the websocket connected - then what?
is there a doc of the actual protocol?
I cannot find it in the links you posted, though I may be just a bad seeker. Or rather a lazy one

We do think about dos protection and other attacks. For now we are doing a reference implementation that will be hardened for production, so we are trying to have something simple where parts can be replaced, for example the channel system could be replaced by something like bitmessage, irc or in some cases the bitcoin network itself (systems offering more guarantees). We will rather adopt systems with full teams dedicated to those problems than reinvent the wheel.

On the same line coinjoin protocols can become more ellaborate and offer greater protection, anyways we will try to keep the modularity and flexibility. For now we rather have things running and people using it than waiting for the perfect system in face of threats that may not materiallize or people can avert in other ways (now people can switch channels for example).

It's a really cool stuff that you are making guys.

I will definitely try to hook my s/w to it in a future.

Do you design it with a DoS prevention in mind?
That's definitely a must have, for a system like this - there will be a big money trying to break it.
Recently I was reading a bit about how darkcoin solved DoS problem for coin joining; they do it by taking a collateral from the coinjoin parties, so if any of them would back off he gets to pay for it. That's a smart DoS prevention idea, though I'm guessing people also came out with other solutions.
But going back to secured chats - they also need some DoS prevention, especially if the client code is in javascript.

This is pretty much what we have in DarkWallet (about the op comment and also specifics described by piotr_n).

http://coinjoint.info/dark-wallet-lobby-enables-secure-group-chat/
https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha3#New_lobby_features
https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha2#P2P_gateway_channels
https://wiki.unsystem.net/en/index.php/TrollNet
https://wiki.unsystem.net/en/index.php/DarkWallet/Identity

Also openbazaar/darkmarket and our gateway's p2p network communication is building on similar concepts (Trollnet document has more details).

For now we have implemented this using a different elliptic curve system (25519) than bitcoin, but everything can be done with bitcoin addresses in the same way, we just preferred the system to be considered without the implications of actually using a bitcoin address as your identity, anyways there are ways to link the different systems using signatures so web of trust, registrations or public key queries can work on different systems simultaneusly (this is what we aim, to tie our communication anon oriented wot, the btc and gpg ones too).

We have implemented some mechanics so peers can stablish links with each other in a similar way to what piotr proposes, calling them beacons and pairings (we also try to ensure identities never leak to untrusted parties). (The Alpha3#New_lobby_features document describes the beacons and pair in more detail as well as private messaging, while the Identity document has more implementation details)

The transport we assume is like an irc, although we don't need usernames since we don't ourselves identify users... that's all done client side. We also don't use irc atm since we needed to connect over websocket and irc is not specially suited for that, plus we had some operational/strategic benefits atm from using code openbazaar uses too and see where they go, and having the lobby together with other proxy services in our gateway (which is like kind of a bouncer too).

Our main goal at the moment is using the lobby/chat for coinjoin and multisig interactions, but also allows for irc-like conversations and private messaging.

It is actually an appealing idea, being able to anonymously communicate with an owner of a certain bitcoin address, without knowing any other info about him.

But I imagine it working in a slightly different way.

First of all, I would advise to use some chat rooms (e.g. IRC) instead of bitcoin's P2P, for the messages propagation.
That would allow you to avoid many issues with all kind of stubborn bitcoin developers/users.

Second you need some handshake protocol because bitcoin address is just a hash of a public key, not enough to encrypt anything with it.
Also as for the communication itself, symmetric encryption is usually much better, so the handshake should establish a symmetric key.

This is how I see an example secure chat session between two parties: (all the messages are sent to some public chat-room)

1. Alice broadcast bitcoin address that she wants to talk to, followed by her public key (that is all clear text, but the public key can be random, not referring to any actual address)

2. Bob, who owns this address and is tuned to the chat room, sees the message and broadcasts the X of the addresses public key, encrypted with the key given by Alice.

3. Alice decrypts Bob's X from the message and figures out whether Y is odd of even (just by trying which one matches the bitcoin address).
Now she generates a random 256-bit symmetric key, encrypts it with Bob's public key and sends this message to the chat-room.

4. Bob decrypts the 256-bit random key and ever since now both the parties have an established symmetric session key (likely AES), so they can just chat using it as long as they need.


Note that if it would be using a kind of chat that hides IP (like TorChat), the only thing that goes public is the bitcon address (from point 1).
And if there was enough traffic on the channel, third parties would not even be able to figure out who was talking to who.
Moreover, almost all the data is encrypted, so you can easily create a random noise making things even harder to snoop on.

At the other hand, making such a system DoS resistant may be a bit of a challenge, but still possible.
We all know how PoW works, so we could use such kind of technologies for DoS prevention.

The Chrome browser wallet extension "KryptoKit" has a Send Message feature that uses PGP.  You can import existing PGP private keys or create new ones.

Purpose: Either transaction related messaging (e.g. send a desription together with the transaction) or just messaging in general.
Addy: What is that?
Need another: Advantage of this approach is that it will be easy to add a new user name (ie address) and as long as you can secretly share the address you'll be confident that no one intercepts the message (and even if they do, they don't know who's chatting)

what would be the purpose ?
like you can just ask someone for their addy ?
sooo many chat/msgr apps these days, do we really need another ?

good idea though I guess, just i am not sure of its usefulness. Please you would need a cenntral server to host it, then if it got hacked someone could change all your 'friends' btc addresses when you send to them.

Is there any bitcoin wallet with built-in chat / messaging?

What I envision is a wallet like Multibit or Electrum which also offers chat. You can send a message to any Bitcoin address to anyone who uses this wallet.

Say the wallet is called Chat Wallet. When it generates receive-addresses it ensures they all begin with 1CW. This way you can be confident that when you see a bitcoin address in this format you can also send a message to the owner of this address.

For merchants it would be useful. For regular people too, of course. If the messaging is encrypted it adds a whole new benefit vs email.