Topic: Peer 2 Peer Open Source Encrypted Text, Voice & Video Communications (Read 15415 times)

I posted on another thread I was going to release my compiled prototypes into one professional put together client & server apps, I will be doing that today and posting on this thread(Didn't get to finish it last night). So if you are interesting in this project, gather testers

short answer yes

I believe that Xenland is going to use Qt for the UI so a Windows version shouldn't be a big problem.

BTW - the project is listed on CIYAM Open (http://ciyam.org/open/?cmd=view&data=20121222131254938000&ident=M100V137&chksum=24be696c) so if anyone wants to contribute then 14NqZ1w7x9gFFzt65Mxy38EPFrbrnR11is is the relevant address (that address is under Xenland's control - please confirm that with him if at all concerned).

Great Project.

Any plan to get the chat / voice system work on Windows ?

not unless you want to pay ALOT of text message fees.. as i think one message of 1024 characters divided by the (240 or 140?) limit multiply that times txt fees

Is there a way to encrypt a regular text messages on a cell phones using today's network?

Thanks for the loads of resources, The only thing i can respond to at the moment is the NAT traversal in my notes the solution is to have "pings" to out going connections of peers that are labled as always on. to keep the ports open. I don't know if that is related though or not.

Interesting project.. but I'm wondering why aren't you building it on top of existing open solutions focused specially on P2P audio/video communications.. i.e: OpenPeer... https://github.com/openpeer/

I think the most difficult part will be the implementation of the audio/video engine and the always-present "NAT traversal" issue. So a WebRTC stack is defo the way you want to go, cos all that problems are already solved. Also, DTLS-SRTP point-to-point Encryption is built-in and mandatory for WebRTC.

http://www.ietf.org/proceedings/82/slides/rtcweb-13.pdf

Maybe you should take a deep look at P2P/WebRTC oriented technologies (OpenPeer, Peer.js, etc) and extract how they have solved the common issues for this kind of deployments (NAT traversal, DHT Nodes configuration, identity managament, etc), and then explore the way to extend it to the level of security you want.

I don't know if this helps, but either way... Good luck!

For the p2pcrypt web version we'll be using this, just leaving this here for notes for later
http://www-cs-students.stanford.edu/~tjw/jsbn/

The goal has been posted up here: https://github.com/Xenland/P2PCrypt-Client/blob/master/README.md
and reposted below for convenience

Abstract Goal of P2P Crypt Client & Servers
Provide global use of communications ran by the world instead of a single (or multiple) centralized controllable entity. To provide free and paid incentives in a way that each server operator will strive to run a P2P Server Node themselves 24 hours a day in either hopes of profit or communication freedom. Also at the same time allowing "mixed" incentives for the server operator to set-up their node how they wish to be compensated for their clients to use their services so that there will be a good balance of "Free" and "Paid" services.


More at the link above....

UPDATED (EDITED)
Link was updated to proper link, it was really late for me when i posted this....

https://github.com/Xenland/P2PCrypt-Client/commit/113d5269077a9ff33b830e4d0b73247f9db2dedf

Available now:
*Saved identity to database
*Displayed Sha512 -> md5 (Handle) after generating an identity

Next Version:
*Ask to connect to network with new identity
*Ask to "attach a password to identity
*Ask to go back to the main boot menu

The new client written in C/C++/QT is about half way done for the total GTK -> QT conversion process. You can find the updates here: https://github.com/Xenland/P2PCrypt-Client

Available thus far in the QT version:
*Shows Generate/Load Identity buttons
*Ability to generate an RSA 2048+ bit identity

Next version:
*Saves identity to database
*Display information from the currently generated identity, and asks to connect to the network or generate a new identity

We have migrated to QT/C++, and  have started over the version numbers the last version updated was v0.0.2.

Pre-alpha testing "take 2" will be happening this weekend.
Stay tuned for the Change list on Saturday.



EDIT/UPDATE POST:


After much discussion this project will be guided like the following/
*Get the protocol & a white paper of the protocol+system standardized with the current "C" only language.
*Convert to C++ code after everything is finalized.

The goal is to start a C++ client in 5 months and be completed with the re-write in another 5 months after that point.


EDIT/UPDATE POST:
The table definitions for the "messages" database.
https://github.com/Xenland/P2PCrypt-Client/wiki/Database-Table-Definitions-%22Messages%22

http://www.techdirt.com/blog/wireless/articles/20130111/03432221640/nokia-running-man-middle-attack-to-decrypt-all-your-encrypted-traffic-promises-not-to-peek.shtml

Looks like i need to get moving on this............

I have uploaded the client code and it is already set to the VPS server and should "Just connect" to the P2P Server node.
You can now test the client/server. I'll be uploading a video in a day or two to display how to use the test app for right now.

I just purchased a VPS 256mb of ram 64bit just to get testing to go by quicker. It shouldn't be long now until a test server is up.

UPDATES: Just trying to get the first connection going before I announce the IP address for testing.

UPDATES: Send/Receive has happened, bugs are already found, editing client code now.

I have publish the p2p crypt client code v0.0.11 that can send and receive messages. (You must add a contact name, and click on the contacts name to "Trigger" a receive message). I can't seem to get my code to compile for a 32 bit system so I can't upload any test server anywhere. perhaps someone could help out with that?

But you can however test the server locally.

Have fun.

The http://p2pcrypt.com website has undergone a few minor updates.

If you are a fan of this project and would like to show how much momentum you want this project to output you can send all contributions to the P2P Crypt Software Donation Fund Address: 14NqZ1w7x9gFFzt65Mxy38EPFrbrnR11is

Great vernon! We need more testers.

I was hoping to have more updates last weekend or even this weekend but my "paying" jobs have been allocating all my time so it looks like "next" weekend (or even this following week it self) will begin the testing pre-alpha phase. Thanks for your patience everyone!

Im in for alpha testing

Exactly! That is why I almost have carpal tunnel(half-joking), and my friends think I'm waiting for the apocalypse I've been in my cave for so long(haha) and this is the 4th time I have re-written the client software from scratch(with each time modifying+revising the setup/basecode). This time the client software (for testing purposes) does not even include openssl libraries or any encryption algorithms all that is going on in this test is "set your user name", type in your "Friends username" and start talking in plain text and basically see "what happens" really and continue with the plan while being aware of the issues that arose from testing phase.


Anywho, I've successfully received a "messgehistory" response from the server to the newly written client software now I'm just parsing the json and outputting it to the screen(the easy part). I say 10 PM (PST) is my target time as of now if I don't make it by 12am (PST) 17th  then it may be till next weekend till some more updates happen at that point.

I think the most important thing is to get everything right. Things like this takes time, and sometimes you hit upon problems and things takes even longer time. As long as you work hard, I'm sure things will turn out pretty well though.

Yep source code is always available and I would love to have a tester that knows their way around compiling code to help with "debug".


Also I'm almost positive I'll be running late for the 12PM (PST) testing time, I think at the rate I'm going, testing will start around 6PM (PST) -- I hope sooner though.

---

UPDATES:

The last bit of code is going into the pre-alpha testing destined to start at 10PM maybe 12AM PST.

MORE UPDATES:
Client is ready for testing (not published to github yet), I"m updating the server code to reflect the client changes.

Allright, I hope to get to download the source code and try to compile your code over the weekend, and do the tests you outlined.

I am almost done splitting up the "prototype" application into separate parts and we can begin testing, don't hold  your breath yet, It should be ready Saturday around 12PM PST

Just about have the "Message History"/"Contacts List" page finished I'm almost positive pre-alpha testing will be ready for tomorrow night.


Some notes: After the 3rd re-write from scratch of the "client" software it shall be noted that pre-alpha testing will consisnt of two applications... the first being for "generate identity" and a different code for "send/recieving messages" to help testing reports go more smoothly

Excellent yes, I'm pretty sure we are all busy and my attempt at being mindful and aware it is my plan to try to have my "test releases" straight forward and stable as possible. Example, For the pre-alpha testing you just have to click a few buttons and do a test "send/receive" message.

Mostly the following
*Generate identity (takes 30 seconds~)
*Load identity(Almost instantly)
*Send/Receive message (Almost instantly)


Windows users have "ported" executables so I can't really say much for those testers all though it should work exactly the same way in theory as the Linux builds.

Noticing skype is a bit controversial these days as to who can listening in, this is the right time to have alternatives made. Sure I could give a helping hand with some testing, what do you need to have done ? Mind I have my own projects but a few time slices could always be donated.

Thank you very much for your wishes!


My intentions are purely to allow the world to feel "okay" to talk to each other and do business again with out closed sourced,   "government ran", or just complicated/annoying comm software. I always feel like in my business conversations there is the person on the other line always "worried" or "panicky" because of "Big Brother" which makes business progress a very very stressful situation in my opinion, I'm sure others will have a variety of wildly different reasoning’s behind it but I'm sure it all stems from a "big brother" paranoia.

To everyone: I can use some testers this weekend and the world could use your help as well, please stand by until Saturday, Cheers everyone!

It's quite a extensive project you're taking on her Xenland, but I think it's great. Best wishes for this project!

I want to kick off pre alpha testing this weekend starting at Pacific standard time. I want to have a windows executable made with Cygwin, but I can't be sure how well that will work so I might just end up having Linux testers (which will drastically reduce my testers availability).

Nice, yeah someone else suggested the same thing as well just recently.
As for updates that happened last night, "identity handles" will be computed like the following md5(sha256(publickey)) and then the md5 will be divided into 8 groups of 4 letters and each group will be assigned a word. By my calculations that means I need a dictionary word list of the size of 58,000 to assign to each possible combination group. This will cut down the total output of words down to 8 words instead of 15+. I'd also like to get different language word lists as well to make it a Multi-lingual but that will be set into the far future for now.

Since the identity handles are only for saving visual screen space and for copy and pasting into the contacts list to "auto-retrieve" the recipients public key from the network if any md5 collisions were to happen it the only negative results would be the client saves "both" public keys of each parties colliding, and that’s about it. --In case someone wanted to point out that md5 is insecure anyways.

http://en.wikipedia.org/wiki/PGP_word_list

I'm trying to think of a way to turn a sha256 output into a consistent string compression scheme but based on what I know about compression I think 50% is the string limit and that’s if the table look up is non-characters. I thought it would be cool to some how turn a sha256 output into something like B3 H1 U8 Z8 I0 T1 Q5 W2 but string compression as I know it can only get down to 64 characters. If anyone know better than me about string compressions that could facilitate something like this that would be awesome. Instead of copying and pasting a sha256(64 characters) string we could copy and paste a 14 character string instead.

I've converged all the old code in to a rewritten client to better accommodate the future commits/features to come, and here are the screen shots of the new pre-alpha test release most of it is similar the last two are different menu screens I believe.


GENERATION SCREENS



LOAD SCREENS

I've been waiting for my client to break at the "SQLite3" areas dealing with "multi-threading, and now it has and this problem so I'm converging the code to support multi-threading in SQL queries. This should make the pre-alpha testing alot less pain for for debugging, sit tight pre-alpha testing is on its way.

v0.0.7_pre10 of the client has been uploaded.
Receiving of messages is possible but displaying and saving them is the current task at hand.

After receiving works, sending them will be much easier to implement.

Before somehow another mishap begins I shall post what is produced so far for the logo as temporary until the P2P Crypt organization can afford a $300-$500 quality logo as my expectations were too high for the budget.





here is the "abstract symbol"

Thanks for the heads up. I'm sorry I don't like your logo and that message wasn't intended for just you, it was intended for every artist that sent in the same logo(practically) and when I back out they all think I'm stealing their idea and threaten me, we can't have a community that advocates "vicious circles". I don't want that in my bitcoin reality where they feel "obligated" to pay because they are being intimidated by others. You can be rest assured your intimidation isn't helping your case.  As a believer in a voluntary society(me), I would never steal anyone work so its hard for me to take anyone accusing me of "stealing" seriously.

 I encourage you to "report me" if that is how you feel, but I don't see the benefit of anything your doing except wasting both our time. So I shall ignore you from here on out unless you have a reputable lawyer you would like me to get in touch with. Good day to you sir.

GUI Client Screenshots (Client is still under construction and has ALOT more work to be did hehe)
NOTES: Generate identity isn't displayed as it generates so quickly it almost looks like nothing happens so I have not built anything for the generation page although generation of a RSA keypair does happen successfully.

Boot up screen


"Load Identity" screen


"Connected to network screen" (This will show the contacts/messages, settings, etc tabs)

Whoa noce that helps alot actually.

http://www.gnutls.org/

Here's a library you might find useful.

For those that want more "visuals" like I need'em to think about security, here is some more flowcharts

The P2P Client version 0.0.4 has been published to the github these updates consists of removing all the warnings I previously ignored to increase development testing time. Also I've updated the networking functions. Now that everything is set into place I can more quickly develop the networking integration for sending/receiving text messages and then eventually audio/video communications.

UPDATES:
I accidentally uploaded the client to the "server" code that has been fixed. I doubt this effected anyone that it happened so quickly.

The client code can ping a list of peers to notify each peer that the client wants to be marked as "reachable" through the network which updates a timestamp of the peer last seen.

Ive also had successful send and recieve messages i just need to make the GUI client facliltate an interface for text communication.

The semi final stage of development pre alpha will be implementing gstreamer for audio/video encrypted communications and implementing safe guards against man in the middle attacks.

Also for those that are curious id like to get a profesional software audit team that has a good track record to improve the security of the code once everything is finalized. That step is a few years down the road but those whom are curious that's the plan.

Client version 0.0.3 has been published (well the "pre" version still doing testing) right now one can "Generate Identity" and "Load Identity" through RSA 2048 minimum keybit strength.
https://github.com/Xenland/P2PCrypt-Client

First version published online of the P2PCrypt Client v0.0.2
Does just about nothing lol. Enjoy!

On a serious note the minimal functionality should be there by Sunday this week.

https://github.com/Xenland/P2PCrypt-Client

Minor Update
Receive Message | receivemsgq
users can now request their messages

Minor Update
Relay Message | relaymsg
Command is now fully functional to the minimum requirements. The message and receipts sha256 is saved to the local servers database until it is picked up by the client (or in the future if the message expires it is deleted to save space it is a clients duty to save already received messages)

Major Updates
The command identupdate is fully functional for minimal functionality requirements. it will save the incoming clients publickey/identity if its a unknown identity, if it is a non-new identity it will return with an "success" response code.


Next step is to allow communication between users.

I'm posting up 1 BTC to the winner of this bid for the "Dummy GUI client" please contact me for full documentation and to claim the winner of the bid, basically the dummy client must work on Linux and I must have some way to test it out on Ubuntu so it shouldn't be hard to adapt if its just plain C code.
http://ciyam.org/open/?cmd=view&data=20130124093030696000&ident=M100V131&chksum=f6584b1d

More Updates
I've posted up more libev example scripts (I know the community could use some of those)
Also the official website should be fully functioning very shortly so I'll start to post almost all things there, whileist only posting the "major" updates here on the forums when necessary.

Yes - (sorry I didn't mention that before) when you are logged in your URLs are unique to your session (and are useless to even keep as bookmarks for yourself which is why the system has a "Quick Link" feature that lets you create your own "sidebar" menu items for being able to quickly run a "custom search" or to immediately jump to a "specific record").

Libevent is being integrated at the choice for the networking handlers.
Before the server was using Gnome networking functions and so now the task at hand is rewriting the networking code.

For others that are in search of Libevent or Libev examples that display some "dynamics" to it, check out the /tool_tests/ folder for some interactive examples. Just use telnet to connect and communicate to the server.

https://github.com/Xenland/P2PCrypt-Server/tree/master/tools_tests/libevent

Thanks for posting the proper link seems to work on my end as well, I guess CYIAM links are unique while logged in; which is inline with how many security measures that CYIAM software has implemented.

I can not access to the info. I have not any account in ciyam and the link sends to a log in page with "Error: Invalid URL" message.
Thanks

EDIT: Hanging around the page a bit I have found the info at: http://ciyam.org/open/?cmd=view&data=20130124093030696000&ident=M100V131&chksum=f6584b1d

The task for the "Dummy GUI client" has been posted up, I'd like to get someone on board that can help contribute C code in the future, this might be a great place to start for that particular C coder. The task information can be found at CIYAM's convenient task manager: http://ciyam.org/open/?cmd=view&data=20130124093030696000&ident=M100V131&chksum=f6584b1dchksum=3c8dc716


(EDITED)

UPDATES:

The GUI is finished
The only thing left for the GUI is to integrate signals, and events for the purpose of integrating the server (networking) it self to be linked into the button events

The server can accept UDP connections for "small commands"
However the the networking is all "dummy" functions with fake responses at this point, so no command does "anything" quite yet

The server in the future will open up TCP connections for file transfers, and other things that need to guaranteed to make it there

Some Updates: I've published the updates of what I have so far as being stable into the github repository. That being the server can now receive connections, generate and save an identity locally into the sqllite3 DB, the GUI is just about finished: I just need to add two buttons and a "console,log panel text output" and the GUI is finished.

The next step is to finish the GUI and get the server to accept JSON RPC commands.

... this quote makes me think that you have got the crux of the idea.

Namecoin is already doing the job you require, i.e. keeping key integrity ... and since it is secured with merged mining by much of bitcoin network hashpower, it is possibly the most secure human-readable nameID linked key integrity system in the world waiting there to be taken advantage of ...

http://dot-bit.org/Main_Page

whoa, that does sound revolutionary indeed, And yes I get exactly what you are saying now.
I'll have to ponder on that idea, and do some research on name-coins source code (or perhaps even hire someone to do the name-coin integration), I like it though its basically everything i described but in this case instead of cost in hash power for clients, it costs in namecoins and the namecoin verification nodes(miners) are paid to keep "key integrity"

I agree, I don't think you are understanding the use correctly ... it's a little involved and I'm not sure if I want to go through all the details here. You seem to be a clever guy so I'll just out line the scheme and you can probably fill in the details.

- Users secure their 'name' in the namecoin blockchain, (i.e. only they hold the namecoin private key associated with that name)
- Also users associate with that name an EC public key using one of the appropriate namespace facilities of namecoin
- When initiating a connection the Sender creates a shared secret using their EC priv. key and EC public key of Recipient by looking up namecoin blockchain (autonomously if need be)
- Receiver can verify who the Sender is securely (and autonomously if need be) by looking-up Sender's EC public key up on namecoin blockchain and creating the required shared secret to communicate initiate ack response
- Sender-Receiver use shared secret encrypted channel to exchange AES keys for encrypting primary dialogue
- ... and etc, do the ECDH as usual from here on ...

... could also do a pay-per-secure-connection model using the namecoins/bitcoins per data-byte ... e.g. sender sends namecoins to receiver address to initiate connection, receiver (streaming server) only allows paying senders to open secure connections ... and stuff like that, hope this helps.

perhaps namecoin does something that I'm not aware of as far as man in the middle attacks but im pretty sure that if i gave you my name coin address, an attacker(lets say a moderator in this example) could replace my namecoin address/id on the post, I don't understand how namecoin is solving this MITM issue (or perhaps I'm looking at the namecoin solution different then what is being presented)

Web-of-trust is only weak protection against MITM (as is CA) versus using a namecoin ID authenticated public key for the key-sharing initiation of a connection.

http://en.wikipedia.org/wiki/Perfect_forward_secrecy

"OpenSSL supports perfect forward secrecy using elliptic curve Diffie-Hellman since version 1.0"

http://en.wikipedia.org/wiki/Key-agreement_protocol

"Protocols that are useful in practice also do not reveal to any eavesdropping party what key has been agreed upon."

Very good input,
Yes we are having the app default to AES/DES/Blowfish for streaming capabilities. the MITM attack can happen regardless of the identity generation method used. so to solve the MITM attack we use the web of trust to evade that issue; however I see your point now that I've thought it through Public key ids should be reduced down like Bitcoin/Namecoin strings for easy copy and pasting and for easy to remember as well.

You might consider using namecoin identities, alias namespace, to provide human-readable authenticated public key exchange and diffie-hellman shared-secret (ECDH) to initiate and establish the AES encrypted channel from there ... it gets around MITM and using CA's for something close to perfect forward security.

Thanks for the heads up; in that case, I'll stay the course and learn from other projects and integrate the best functions into this project.
I think I'll incorporate hashcash for all p2p crypt messages to reduce spam, and if you want to spam the network it'll cost you hashing power + electricity

i recommend u to stay away from retroshare, its a buggy code base and  the devs dont really bother to fix this, its like M$ actually.
altough u could look at theirs DHT code, but you would have to fix it since its bugged as hell -> you constantly broadcast (telling the DHT nodes that u exist) without limit, ur flooding UDP packets as shit, no way to limit it, just horible

Oh one difference between retroshare and this project is that retro share doesn’t have a "streaming" option, I'd imagine that p2p crypt nodes are only used for "key server and relaying data".

 so on a side node:
if a receiving user isn't online all nodes will be advised to save data for a optimal amount of time(nodes can refuse to relay data, but the more a node is "known" that it refuses to relay most  data received then other nodes will be label that this node is a "leech" in their local DB rating systems. Meaning it is still advisable that this node could be trusted for relaying and communicating with, they just might be asshats about their bandwidth and shouldn't rely on them as well as other nodes limit the bandwidth for the leech as well.

correct

Your question fails to provide what kind of relation ship I have with josh in the example, so I’m not sure what kind of trust we are talking about. The website-trust is for "login/sessions" and even in the future for social networks to "request data" that can been auto-filled after unlocking the requested information with a password, anything beyond that i don't understand your question.

let me clear up that you used Account and identity interchangeably but separately, if you create a new account/identity you can still load up your list of "Trusted nodes" and "untrusted nodes" but to the network you are an untrusted node/client because you are new all nodes should be advised "NOT" to trust you until you build some trust.  You can build trust by relaying data and other nodes will verify your data against other nodes thus its impossible to know (Just like Bitcoin) who trusts who. UPdate/Edit: Also makes it expensive to get anything on the network when there is super complex webs of trust/attacks going on why if half the network was being attacked that would make it difficult for more attackers to join in because its unknowable how far your "failed" data will traverse through the p2p nodes considering that nobody will ever know the "true" levels of trust everyone has applied to every other client/node.

I'd imagine in my system that you would have to take 3 months to a year to get the whole system to FULL trust a new online identity and your trust could be broken back down to 0 (or even in the negatives) in a day if you start to relaying bad data. (In the future someone could build an add-on or module or even into the protocol that alerts other "Trusted" nodes that this X node is relaying alternative data and could be bad, but i just wont know if this is possible with so many false positives that could be attributed.)

This is with out the "bitcoin" type system integrated... In the future not only will it be (CPU) costly to create the message I'd imagine the user could have to generate hashcash/bitcoin target digest output before the message is accepted by the p2p nodes for relaying (CPU Costly to send message, Easy/quick to verify and Relay messages)



Thanks for the retroshare link(and the other resources as well cheers!), that GUI looks exactly how I envisioned, Perhaps I could build on top of it and contribute to the project (didn't get a chance to see the license). Looks like a great application to fool with and thank  you for your great questions, I hope I provided some interesting answers as well.

More side nodes:
I realise this idea isn't new by any means but I think it will be the first to make it into run-time.

OK, I understand your system as planned will include all of these pieces but it is a lot to take on. I am going to describe it in the context of some existing projects that have taken on chunks of the problem, for more research areas you may want to look into...

So there would be a component that would operate like a PGP/GPG keyserver, but with additional validation over other channels like what the the CACert Web of Trust CA is doing.

Very true, you just have to make sure the validation process has air-tight security - for example, if someone posted a public key for Josh on this site (with some cleanup to make it look legitimate of course) is that enough trust? Obviously not. Systems like CACert require a face-to-face meeting with trusted community assurers and checks of government ID to finish the signing process for the Web of Trust cert. It depends on what level of trust you want to place in the system.

This would be difficult to protect against, what's to stop me from feeding a node bad data continuously with a coordinated attack from multiple new accounts, slowly increasing the percentage of bad data it relays to take it offline? How does the node itself verify the trust of the original party when it is deciding whether to pass the data along? Also, how do you know you are talking the real person's identity, and not someone that has created an account claiming to be that person?

Yes, once the trust system is in place, it could be used for many awesome things.

This I have to object to, SSL works well, is extensively tested, and highly trusted. HTTP can be stateful without any encryption at all. User authentication/captchas is a separate issue, and in that area it is true that the web of trust would provide an additional authentication option (possibly taking the place of SSL client side certificates.)

Also, how does your system compare to something like Retroshare?

I know the end goal you want to get to for the trust side, since having a working system of decentralized trust is a 'holy grail' for online systems, and a lot of research has been done in this area as it contains a lot of hard CS problems. The wiki article on Web of trust is a good resource, and there are many papers (search for 'trust management problem' or 'decentralized identity'.)

Even just a face-to-face-public-key-sharing (or via Bitcoin public keys...) crypto app would be very useful in its own right, however. In any case, I am looking forward to seeing where you take the project!

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

No problem-o.

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.

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?

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.

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".

how about CA?

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.

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.

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,

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.

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.

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.

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 like this idea, watching

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.

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.

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.

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?

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

UPDATES: Clients can exchange PEM/RSA keys

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