[idea] Web service for anonymous & secure private messaging.

[greBit]

[TL;DR] In-browser, Cryptocat for email-style communications, using bitcoin compatible address to identify endpoints.

• When PGP is too much hassle and you just want to click on a link to access your messages from anywhere and with peace of mind.
  
• When you might also want to perform bitcoin transactions as well as chat!
  

[Scenario 1] Getting a private message 'channel' for advertising campaigns

• Bob often wishes to publish adverts for the services he provides, when he needs to find someone to fill a job position, or if he wants to find a new flatmate, sell his car, etc. He does this using twitter, public forums or perhaps on printed flyers
• He obviously needs interested people to be able to contact him back
• He wants to keep all related communications together - he used to setup dedicated email addresses for this very purpose and put a different one in each advert.
• But now he is becoming privacy aware and is sick of having his personal emails in plain text on some server

[Scenario 2] Secure communications for email-style messaging

• Alice and Bob become friends on twitter and start sending each other messages from time to time.
• At some point Alice becomes wary as the conversation could 'cause offence' to their government.
• She suggests that they continue over private messages.
• She goes to the online service/plugin and generates an identity, giving Bob her public key.

[Silly Scenario 3] Hiding the existence of your PM address in a public communication!

• Some websites try to lock you in to their platform and will not let you exchange contact details with other members. Email addresses will be filtered out of posts you make etc
• Provide different 'encodings' for your public key, so it could be written in multiple ways and easily hidden in a message.
• Simple steganography could be used to hide your public key in some ordinary looking text!

So this could be realised as an open source client + server project.

Any one could decide to host their own PM service. The app would be sooo easy to deploy, you could have it running on your Openshift/heroku instance in seconds.

Also chrome plugins / mobile apps could also be created, which could be more easily trusted through code signing.

[1715476566]

1715476566

[1715476566]

1715476566

[Xenland]

Perhaps once my P2PCrypt servers are online, anyone could make a web browser client as it uses JSON communication so someone could very well make the entire communiation you speak of with just javascript presuming that someone knew how to implement RSA and sha256 into javascript.

Source-code to server: https://github.com/Xenland/P2PCrypt-Server
(No client exists yet)

Forum Discussion: https://bitcointalk.org/index.php?topic=131905.0

[greBit]

Yeah this looks like a really interesting solution. 

My goal is to keep the components that need to be trusted, close to the user and under his control.

I was thinking more along the lines of having really dumb but interconnected cloud servers to provide a reliable message store and having 'heavy clients'. Effectively boiling down to a distributed hash table, that guarantees performance, availability and easy access to messages through a RESTful API.

Then the webapp/mobile clients would handle key management and encryption of messages before transacting with the PM Api

It is already very possible to do encryption in the browser with javascript. Look at Cryptocat or Mega.co.nz for example!

[CIYAM]

It is already very possible to do encryption in the browser with javascript. Look at Cryptocat or Mega.co.nz for example!

It can be done *better* than that (http://ciyam.org/open) - if you are interested to "sign up" and test then just PM me.

(Xenland already has a Project there)

[Xenland]

Yep that sounds all very possible with my system.

 The client will be under the AGPL license so anyone can promote decentralized freedom as long as they don't make profit, if I can get contributors/funding I would love to release the client as MIT license.
The great thing is the p2p server is MIT license so you can profit from its operation,edit,sell,and distribute it how anyone wishes.


Some examples that I can confirm that relate to what you stated in the first post was that you said...

Simple steganography could be used to hide your public key in some ordinary looking text!

All messages relayed through p2pnodes/servers send with the recipient publickeys' sha256. which means only those who know the recipient publickey will know who the recipient is in a sense. There is no such thing as total anonymity in a decentralized world but we can progressive build it up to the best it can be.

When PGP is too much hassle and you just want to click on a link to access your messages from anywhere and with peace of mind.

as long as you carry your public key around with you with you can access your messages, I've developed a portable device that can facilitate this but I need to get the server infrastructure to be online before it makes sense to release the device.

[greBit]

Thanks for your replies.

Im just wondering though, if my requirements would make integration with your solution impossible..? i.e.:

* I don't want users to have to install software (mobile app/chrome extension are optional)
* I don't want to have to trust the servers

This means the crypto has to be done client side and effectively in the Browser.

So I think this would sadly discount your solution for my case? I see that its a 'proper software' solution in C!

I think this would also discount BitMessage as well, and i'm not keen for my users being obliged to wait 4 mins to send a message these days.

[CIYAM]

This means the crypto has to be done client side and effectively in the Browser.

So I think this would sadly discount your solution for my case? I see that its a 'proper software' solution in C!

That's *exactly* what I do - so how does that "discount it for your case" (it is open source and is already on github so you don't need anything from me to order to use it - just clone it)?

[Xenland]

Thanks for your replies.

Im just wondering though, if my requirements would make integration with your solution impossible..? i.e.:

* I don't want users to have to install software (mobile app/chrome extension are optional)
* I don't want to have to trust the servers

This means the crypto has to be done client side and effectively in the Browser.

So I think this would sadly discount your solution for my case? I see that its a 'proper software' solution in C!

I think this would also discount BitMessage as well, and i'm not keen for my users being obliged to wait 4 mins to send a message these days.

I don't know which one of us you are replying back to in particular so my response will be under the assumption that its refers to both CIYAM and me in an open-ended fashion (as your response could be referring to both from what I know about CIYAMs' project)

The P2P server software is written in "C" as it intended to run on server architectures and the server communicates with other servers and clients through JSON. Making it the perfect solution for anyone to write a client that can parse,read and write in JSON.

* I don't want users to have to install software (mobile app/chrome extension are optional)

The client will be released opensource on Windows and Linux as esktop applications but no plans for a web browser client at the moment, perhaps I could collaborate with someone willing to take that part on.
The p2pserver would like to release mobile and browser apps the plan is to get the servers running and then release the browser apps for many convinces(targeted for the end of this year of 2013).
Once the infrastructure is in place the "mobile apps" will be built and deployed (targeted to be published next year).
Anyone is allowed to make a client and anyone can make their own server with their own rules, for instance someone could make a p2pnode server that you need to "pay" for audio video storage but you can have unlimited text messages and that would be perfectly compliant with the p2p server web its pretty open actually.

* I don't want to have to trust the servers

The p2pnode servers do not need to be trusted in fact its recommended to "validate" the exchanged keys through another medium (something namecoin will solve in later stages of production but that’s another story).

*The servers are to help make connections by opening up router ports through firewalls and to have some consistent storage of public-keys.
With out the servers you would have to some how contact your receipent and tell them "exactly" what time you would like to connect to them so that both firewalls would open up at the same time(within 60 seconds). Also the servers are for "key" exchanges and key integrity, you can "verify" the key was not "altered" by contacting your receipent and match your receipts public key sha256 digest or you can exchange the key through.

I think this would also discount BitMessage as well, and i'm not keen for my users being obliged to wait 4 mins to send a message these days.

I'm sorry to hear other solutions are not to your liking and I haven't used Bitmessage my self nor do I know the setup it is using in particular but I do know that I just did a "message" relay test about an hour ago with the P2PCrypt server and a dummy client I made and it was pretty fast (near instant) but it is just "one" message taking up server resources so not a great comparison at the moment I suppose.

Cheers mates!

[greBit]

This means the crypto has to be done client side and effectively in the Browser.

So I think this would sadly discount your solution for my case? I see that its a 'proper software' solution in C!

That's *exactly* what I do - so how does that "discount it for your case" (it is open source and is already on github so you don't need anything from me to order to use it - just clone it)?

Sorry! Was replying to Xenland - I completely missed your msg. I will have a look at it. Very much appreciated!

[greBit]

Thanks for your replies.

Im just wondering though, if my requirements would make integration with your solution impossible..? i.e.:

* I don't want users to have to install software (mobile app/chrome extension are optional)
* I don't want to have to trust the servers

This means the crypto has to be done client side and effectively in the Browser.

So I think this would sadly discount your solution for my case? I see that its a 'proper software' solution in C!

I think this would also discount BitMessage as well, and i'm not keen for my users being obliged to wait 4 mins to send a message these days.

I don't know which one of us you are replying back to in particular so my response will be under the assumption that its refers to both CIYAM and me in an open-ended fashion (as your response could be referring to both from what I know about CIYAMs' project)

The P2P server software is written in "C" as it intended to run on server architectures and the server communicates with other servers and clients through JSON. Making it the perfect solution for anyone to write a client that can parse,read and write in JSON.

* I don't want users to have to install software (mobile app/chrome extension are optional)

The client will be released opensource on Windows and Linux as esktop applications but no plans for a web browser client at the moment, perhaps I could collaborate with someone willing to take that part on.
The p2pserver would like to release mobile and browser apps the plan is to get the servers running and then release the browser apps for many convinces(targeted for the end of this year of 2013).
Once the infrastructure is in place the "mobile apps" will be built and deployed (targeted to be published next year).
Anyone is allowed to make a client and anyone can make their own server with their own rules, for instance someone could make a p2pnode server that you need to "pay" for audio video storage but you can have unlimited text messages and that would be perfectly compliant with the p2p server web its pretty open actually.

* I don't want to have to trust the servers

The p2pnode servers do not need to be trusted in fact its recommended to "validate" the exchanged keys through another medium (something namecoin will solve in later stages of production but that’s another story).

*The servers are to help make connections by opening up router ports through firewalls and to have some consistent storage of public-keys.
With out the servers you would have to some how contact your receipent and tell them "exactly" what time you would like to connect to them so that both firewalls would open up at the same time(within 60 seconds). Also the servers are for "key" exchanges and key integrity, you can "verify" the key was not "altered" by contacting your receipent and match your receipts public key sha256 digest or you can exchange the key through.

I think this would also discount BitMessage as well, and i'm not keen for my users being obliged to wait 4 mins to send a message these days.

I'm sorry to hear other solutions are not to your liking and I haven't used Bitmessage my self nor do I know the setup it is using in particular but I do know that I just did a "message" relay test about an hour ago with the P2PCrypt server and a dummy client I made and it was pretty fast (near instant) but it is just "one" message taking up server resources so not a great comparison at the moment I suppose.

Cheers mates!

Awesome thats made it much clearer in my head.  So the crypto is always performed at the client side, and the servers are just there to support direct communication between nodes and perhaps message storage? perfect.

Could we perhaps say that servers in your scenario act as a distributed key/value store? or do they add extra services?

i.e. their sole function is to

A) provide info about how to communicate with a node and
B) store messages sent to a particular node

[Xenland]

Could we perhaps say that servers in your scenario act as a distributed key/value store? or do they add extra services?

i.e. their sole function is to

A) provide info about how to communicate with a node and
B) store messages sent to a particular node

Yes... but also no.
Let me break it down

The p2p crypt servers at minimum will provide distributed key/value storage and text messaging storage(limits are not decided yet so don't ask about storage limits at this moment).

but if the admin/operator of the p2pnode would like they could set up all sorts of built in features(I say built-in because I don't like the idea of plug ins it's just asking for security trouble), the features they don't use are not loaded into memory.

*I have ideas for all sorts of features like "Paid and Semi-Paid" server nodes.
Anyone could set up a p2p node server that only allows "paying subscribers" they can choose, what and how much to pay, etc for what features.
For instance some people can't afford to set up a p2p node that can proxy text, audio & video but some people can afford to pay for text relay/proxy/storage and make users page for video/audio proxy storage or even realtime-streaming proxy to hide eachothers ip address.

Also don't confuse your self either the clients are freely available to use the p2pnodes just only to exchange ip addresses and secret keys to help make the firewall/direct connection process go more smoothly for audio/video/text exchanges.

Update/edit:
Also the p2p node servers them selves will have their own webs of trust along with the clients having their own web of trust so there is some "integrity" of data going on as far as public-key exchanging goes. Person A could exchange their public key to Person B through the email by Person A sending the public-key to Person B, Person B will then import that public-key into the database and the client will auto-generate a sha256. Person B then asks his trusted p2p nodes (and clients) the corresponding public key to the sha256 digest of Person As publickey.  The client will then compute if the sha256 digests that was imported match the ones with the most agreed upon in your web of trust network, if this is true, you can "safely" communicate with Person B.

[Vernon715]

Wouldn't TOR do the job?

[Xenland]

Wouldn't TOR do the job?

Tor is aimmed at relaying from a single host in realtime anonymously and securely.
My solution is for anon, security, relay, and storage+relay of messages or documents even perhaps answering machines that can save video/audio packets for paid subscribers from multiple hosts/servers.

(not to mention a global public key server by multiple means of p2p propagation, namecoin, RSA, namecoin keypairs,etc)

[Vernon715]

Wouldn't TOR do the job?

Tor is aimmed at relaying from a single host in realtime anonymously and securely.
My solution is for anon, security, relay, and storage+relay of messages or documents even perhaps answering machines that can save video/audio packets for paid subscribers from multiple hosts/servers.

(not to mention a global public key server by multiple means of p2p propagation, namecoin, RSA, namecoin keypairs,etc)

So basically you want an anonymous form of Google apps (email/drive/voice)?

[Xenland]

Wouldn't TOR do the job?

Tor is aimmed at relaying from a single host in realtime anonymously and securely.
My solution is for anon, security, relay, and storage+relay of messages or documents even perhaps answering machines that can save video/audio packets for paid subscribers from multiple hosts/servers.

(not to mention a global public key server by multiple means of p2p propagation, namecoin, RSA, namecoin keypairs,etc)

So basically you want an anonymous form of Google apps (email/drive/voice)?

If you want to call it that sure.

[Vernon715]

Wouldn't TOR do the job?

Tor is aimmed at relaying from a single host in realtime anonymously and securely.
My solution is for anon, security, relay, and storage+relay of messages or documents even perhaps answering machines that can save video/audio packets for paid subscribers from multiple hosts/servers.

(not to mention a global public key server by multiple means of p2p propagation, namecoin, RSA, namecoin keypairs,etc)

So basically you want an anonymous form of Google apps (email/drive/voice)?

If you want to call it that sure.

The only reason that I am calling it that is because it is something that most people on the forum can relate to.

[Xenland]

Deffinatly a good analogy in one word to describe the system. However im obligated to promote the official name of the P2PCrypt but its open source so it can really evolve into any name the people of the republic enjoy.

Also as a heads up im doing my first p2pcrypt  client message send/recieve test today, wish me luck!

[Vernon715]

Deffinatly a good analogy in one word to describe the system. However im obligated to promote the official name of the P2PCrypt but its open source so it can really evolve into any name the people of the republic enjoy.

Also as a heads up im doing my first p2pcrypt  client message send/recieve test today, wish me luck!

Good luck!

Will there be some sort of public beta?

[Xenland]

Deffinatly a good analogy in one word to describe the system. However im obligated to promote the official name of the P2PCrypt but its open source so it can really evolve into any name the people of the republic enjoy.

Also as a heads up im doing my first p2pcrypt  client message send/recieve test today, wish me luck!

Good luck!

Will there be some sort of public beta?

Thanks!

Also
The code is already out there so anyone can compile the server and/or client code and test it out as builds happen to upload.

public testing phases are planned and will go something like the following...

The first pre-alpha will take place within 7 days from now.
The pre-alpha phase will look for the following:
*Stableness (Does the application crash often or at all)
*Enhancements (for example: is this public key already added to the contacts list, if yes don't add and alert the user; Right now the client will add public keys regardless.)

The alpha phase will  take place within 30 days from now:
The alpha phase will look for the following
*Stableness
*Enhancements
*Integrate already planned functionality (Audio and/or video calling, file transfers, user authentication)
--At this point in time we'll be stuck in alpha just revising code like crazy make sure everything is tip top for beta....

The pre beta phase will take place within 120 days from now
The pre beta phase will be focused at integrating inter-node communications.
Alot of analysing will be required to see what will be the most efficient, safe, and semi-anonymous ways of propagating messages, data or audio/video packets to be saved on servers as well as deciding the rules of rejecting a file, relaying data, etc Its unknown how long this part could take to get it just right so from here on out no planned times are set with development testing.

The beta phase will consist of making the server and client easy to use, easy to install, easy to understand and pick up and be secure with out reading a crypto manual and making sure that the apps are stable on all/most Operating Systems.

Once that is all said and done, Version 1.0 is released to the public and watch the fireworks!

[Xenland]

Some screenshots, Mind you the graphical interface will be heavily revised but this is the general footwork of it
Generally I picked out easy to describe icons