Peer 2 Peer Open Source Encrypted Text, Voice & Video Communications

[Xenland]

Basically viruses, spyware, and trojans are a threat to computer users (PC, MAC OSX, etc). We all know this... but what we don't think about is how they can affect what once was encrypted communications on your computer.. Now you can't be too sure. You download so many files just browsing the internet even if you don’t ever click "Save" or "download" you had to download some files to get "there" to see those links. Files just basically freely come and go through your computer its unsure what viruses, spyware, etc are doing but what we DO know is that its unsafe to run encrypted communications AND work,browse, or what ever else it is you do this is because before your voice is encrypted, spyware can listen in to the microphone line "before" it is encrypted which effectively evades any encryption process. In effort to provide privacy I created an embedded encrypted device that uses multiple channels for Public key transfer to ensure no MITM attacks happen.

 When i was about to post my product on kick-starter I thought to my self "I have no screen, I have no interface on my embedded device, why would any-one invest in my device if they can't prove I know what im doing for all they know i just added sound in post-production of the demonstration video. So I thought.... and thought and thought. And my solution is to provide a P2P Encrypted solution for desktops just to demonstration that I have encryption knowledge and can build things up to PKCStandards.

So I present to you my desktop app (Known to only work with GCC/LINUX) right now; I'm in the process of building it, basically everyone logins with a Public Key, and clients to connect to other clients. Both clients identify them selves with public keys and exchange keys.

To prevent Man-In-The-Middle Attacks, clients will ask other clients around the world what they know about "everyone online" which is basically an IP address list with public key associated with them. Each client will save the list and extract the public keys they want to verify (as opposed to just specifically asking for a public key/IP pair which could lead to man-in-the-middle attacks as asking for specific public key and ip pairs). Essentially Bitcoin-Network but with out bitcoins its messaging.

Once a client feels they have enough verifications from each node they can start communicating with the client -- this is all transparent. (untrusted nodes will only slightly increase confidence, trusted nodes will drastically increase confidence).

Any ways once i feel that I have a user base I can release my embedded device on kick-starter when i feel it is time until then i will produce "confidence and trust" with the encryption communication community.

Programming Language: C
Source Code: https://github.com/Xenland/P2PCrypt-Server
Client Source Code: https://github.com/Xenland/P2PCrypt-Client
Website: (UNDER CONSTRUCTION) http://p2pcrypt.com

[Xenland]

UPDATES: Clients can exchange PEM/RSA keys

[Xenland]

Updates: SQLite3 integrated.
Generated identities are saved into the database.

[rgzen]

Hi!
I can see a very interesting project. In fact, I found here what I were thinking to develope.
I will analise the code as soon as posible and I will be following the project.
Is it functional now?

[Xenland]

Hi!
I can see a very interesting project. In fact, I found here what I were thinking to develope.
I will analise the code as soon as posible and I will be following the project.
Is it functional now?

Its not complete by any means, how ever I try to post only stable builds so it should as of right now display a GUI showing two buttons Button 1 says "Generate Identity", Button 2 says "Load identity". Only the "generate identity" partially is complete it will generate a key. I haven't secured anything at this point like pen-test or make sure the keys generated have high entropy and I don't plan on "securing it" until all the implementations are their --Just to make progress/development/ideas go by quicker. In other words the plan is to get the thin working and then secure the app.  The app just requires OpenSSL and GTK (and possibly GDK)


Side-note:I'm working on an embedded solution right now but I feel a fan/user-base is needed as well as p2p network established to make the embedded solution more appealing. I will not discuss any details about the embedded solution at this time for the sake of preventing competitors however just know that its near completion and the source-code is planned to be MIT/X11 licensing, however practically I fore-see that it will be GPL at first to get a ROI so an organization could be established with some funds to back it and provide updates, and other planned "secure devices"(that will also be FOSS) and then once the org is established release MIT/X11 licensing. The desktop app it self will be X11/MIT when it is complete for now its just AGPL.

[Xenland]

Instead of providing a gui right off the bat, I'm going to start over and get a command line solution working and then once completed a GUI could be built on top.
This is because updates for littlest things take forever to change, and sync up with loads of GUI code so this command line route will make development progress quicker.

[Xenland]

So starting over with v0.0.0.1

We have the server that opens the sqllite3 database and generates then saves the public key pair into the database.

[K1773R]

i like this idea, watching

[thezerg]

maybe grab a pre-existing P2P library and layer your app on top?  If there isn't one ready-made somewhere, you could isolate the one in bitcoin from the blockchain.  That would probably be valuable for many apps...

[Xenland]

maybe grab a pre-existing P2P library and layer your app on top?  If there isn't one ready-made somewhere, you could isolate the one in bitcoin from the blockchain.  That would probably be valuable for many apps...

I have checked-out a few other pre-made C frameworks, I'm not a fan of any of them so far. The main reason being is I feel there is less flexibility with what this project is aimed to accomplish with restricting libraries. I am open to suggestions though to splicing code snippets from however

splicing code out of Bitcoin isn't a bad idea but it most certainly isn't the most efficient one.

And I find C is pretty progressive, I might have a p2p node server running by the end of the week and a client done by next week. GUIs can be made to interface with the command line and then later on redeveloped for a independent GUI version later on down the road.

[Xenland]

Also I could also use some help, I need someone to help with the client for sure, and then I can do the server. I might even hook it up with a Bitcoin or two if someone provides a gui that I can plug into, Just message me if you want to collaborate.

[paybitcoin]

Xenland,

Can you post a block diagram of which encryption algorithms and authentication algorithms are used for each of the client and server?

Also, you should look into using libevent (or libev...) if you are writing network stuff in C. It makes writing network-facing C code much easier, it's more portable, and has better performance to boot.

[Xenland]

Xenland,

Can you post a block diagram of which encryption algorithms and authentication algorithms are used for each of the client and server?

Also, you should look into using libevent (or libev...) if you are writing network stuff in C. It makes writing network-facing C code much easier, it's more portable, and has better performance to boot.

Whoa sweet, I was writing my own networking code and it doesn’t look pretty, I'll definitely check out libevent for sure.

I'll get back to you with how I imagine the network would process like, very soon.

[Xenland]

The issue at hand is that until decentralized internet is established the masses relies on one "Internet" tunnel to reach their devices, there is rare cases where someone has purchased multiple Ethernet lines to connect to that are provided by separate companies, so even in the city with high amount of wifi nodes around they general area will be considered by the same company. If there are multiple wifi nodes from multiple companies its super rare to be equipped with a WIFI chip that will connect to multiple nodes at once so until all this is fixed(hopefully in the near future the internet will become decentralized) the P2P Crypt is forced to work like the following diagrams

BLUE: Connections not safe for trading public keys, but is safe for relaying data (Unless data is being received or sent to a trusted node)
SOLID GREEN: These are "actions" that happen, and they increase the security of the network
DASHED GREEN: These are the results of the solid green actions, dashed green lines show which nodes can safely relay data to each other regardless if there is an untrusted connection/ISP
DASHED Yellow: These are the results of the green "actions", They are used for transferring encrypted and plaintext data as well as public keys. Information must be verified by requesting the checksum from other nodes and once enough yellow nodes have sent in trusted information (and atleast 1 green solid connection) have been verified then the data is marked trusted

The following shows an untrusted internet-work connections before anyone trades keys and/or builds trust.


The following shows how to solve the Man-In-The-Middle issues by trading public keys in person (or provably secure connection)



Obviously trading public keys face to face is 99% impossible to do in a practical sense for the internet, so the P2P Crypt server nodes are established to be running 24/7 all around the world. P2P Nodes would in theory trade public keys in person only once to establish trust. Now clients can connect to multiple p2p nodes and verify information from multiple sources (the diagram shows only two p2p servers nodes but a the actual client would require 20 nodes to verify information before anything is trusted).


I'd imagine that just like Bitcoin there would be an 100+ established trusted nodes included with the application, so just assume that when viewing the steps below. The steps below depicts how a new p2pnode (or client) coming online could begin to establish trust with other nodes or clients with out meeting face to face and exchanging public keys.

[Xenland]

I plan to use RSA Keypairs for the identities. Communication could be transparently chosen/negotiated in the back end or a config file. If a communication method can't be agreed upon the application should use a default that every app could "default" too in that event. Most likely AES or blowfish perhaps.

[K1773R]

I plan to use RSA Keypairs for the identities. Communication could be transparently chosen/negotiated in the back end or a config file. If a communication method can't be agreed upon the application should use a default that every app could "default" too in that event. Most likely AES or blowfish perhaps.

how about CA?

[Xenland]

Essentialy its the same setup as a CA but this is different in that there is no stigma in "authority" just "secure communication" associated with the project. The other differences is that its more real time than "pay, generate, distribute".

[paybitcoin]

Thanks for doing this, it is much easier to reason about the system this way than when starting with code. The diagrams are very nice.

Some questions:

Why do the Nodes need to be trusted, if the data channel is between users, and data is encrypted? Or is this for a supernode-like system?

P2P trust and reputation systems are extremely difficult, what happens if hundreds of rogue nodes come online that all trust each other 100%? Can they kick Bob off the network by spamming "Bob is not trusted" to other users?

Have you reviewed other protocols like OTR to see some of their guarantees for privacy and deniability?

The issue at hand is that until decentralized internet is established the masses relies on one "Internet" tunnel to reach their devices, there is rare cases where someone has purchased multiple Ethernet lines to connect to that are provided by separate companies, so even in the city with high amount of wifi nodes around they general area will be considered by the same company. If there are multiple wifi nodes from multiple companies its super rare to be equipped with a WIFI chip that will connect to multiple nodes at once so until all this is fixed(hopefully in the near future the internet will become decentralized)

City-wide decentralized wireless internet will not happen (at least not in the next 10 years, maybe on a small scale with smarter antennas.) Wireless spectrum is too scarce, and latency between hops is too high, to support even a small city full of users. I believe that internet service over city-owned fiber will be the status quo for the next 50-100+ years, run as a utility, like trash service, water, sewage, or power, and the solution for 99% of users. So possibly even more centralized than what is here now. However, after the first hop, there will be an incentive to run better paths between cities and neighborhoods, so there will be more decentralization at a higher level.

[Xenland]

Thanks for doing this, it is much easier to reason about the system this way than when starting with code. The diagrams are very nice.

No problem-o.

Why do the Nodes need to be trusted, if the data channel is between users, and data is encrypted? Or is this for a supernode-like system?

Good question; I'd imagine the p2p nodes are basically super nodes and clients only relay small bits of data .
If the client trusts the source of the private key, it doesn’t matter how the data is sent or received as. (Example, if I trade keys face-to-face it won't matter how the data gets there or received). The issue is that people from china can't all practically swap keys face-to-face, and not everyone is a "Crypto-wizard" to know how to evade "Man in the middle attacks during key exchange over an electronic interface". This is when the "P2P node trust" system comes in to play, basically two people exchange keys on the non p2p network (perhaps a facebook message or IRC). Once to people have their public keys they now can ask the p2p nodes to validate the key by asking for and validating various information transparently for the user.

Why do i think this is awsome?
As of right now for a "layman" to accomplish this they have to be educated that they need more than one channel of communication to prove that there was not a man in the middle attack during the trading of public keys, so this solution makes the whole experience transparent becuase unless you meet face to face for publickey exchange your most likely going to exchange public keys through gmail, hotmail, IRC or facebook and unless a "layman" is educated to "resend the same key on a different email address or chat channel and "match the public key letter by letter", then they are vulnerable to man in the middle attacks".


Other notes....
New clients can build trust by helping relay small chunks of data;
the actual trust is gained by other nodes if your data seems to match up with nodes that those recieving nodes trust, the more your information matches the more your trusted over time, however if your client is relaying 100% or even 20% false data all nodes are advised to deny data from that client or node (A better solution would be to lower the priority of processing from your node as an attack could be happening and "triggered block occurred")

This p2p crypt app could also provides other opportunities
*Like perhaps even be the leader of SSL certificate authority systems in the far off future: I ponder that if everyone online has everyone else’s key who is currently online along with a rating of "trust" that node is then perhaps we won't need to have CA's at all because there is no more risk of man in the middle attacks (which is why there is CAs certificate list is in browsers).

*SSL and non SSL enabled websites could rely on the p2p crypt trusted web to initiate a secure login session, cookies and other methods to turn HTTP into a "State full" protocol literally is 2+ decade old technology and computers getting faster while captcha methods failing; The sessions are under constant attack and its time to move on.
HTTP could be used to serve webpages while P2P crypt could allow websites to initiate a "secure session" regardless of an SSL connection. this could allow safe login sessions that are harder to attack on.


Just some ideas to "mull over" guys Obviously we going to see how the system works up over time but this is the ultimate picture i think.

[Xenland]

Also I'm going to declare the p2pnode server as X11/MIT license in the next commit on github. The client however will have free and pricing options

I'm looking for someone to help me develop the GUI in C and GTK2.0 I nessecary I can pay some Bitcoins if its worth it. Code should be easily flexible so I can hook actions into the pages and buttons. Contact me for more details.


https://docs.google.com/drawings/d/1NsXZZYmtuigO4SfOZAbMY2BE9Czupf06VOn1El15d7M/edit