Topic: Peer 2 Peer Open Source Encrypted Text, Voice & Video Communications (Read 15310 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
July 11, 2013, 03:25:17 PM
Great Project.
Any plan to get the chat / voice system work on Windows ?
Any plan to get the chat / voice system work on Windows ?
short answer yes
July 11, 2013, 10:50:20 AM
Any plan to get the chat / voice system work on Windows ?
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).
July 11, 2013, 10:45:53 AM
Great Project.
Any plan to get the chat / voice system work on Windows ?
Any plan to get the chat / voice system work on Windows ?
May 13, 2013, 03:54:37 PM
Is there a way to encrypt a regular text messages on a cell phones using today's network?
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 
May 13, 2013, 03:50:03 AM
Is there a way to encrypt a regular text messages on a cell phones using today's network?
May 12, 2013, 03:22:31 PM
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!
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!
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.
May 11, 2013, 09:04:51 AM
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!
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!
April 23, 2013, 07:53:39 PM
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/
http://www-cs-students.stanford.edu/~tjw/jsbn/
March 27, 2013, 05:32:12 PM
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....
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....
March 26, 2013, 10:44:48 PM
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
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
March 24, 2013, 01:13:31 AM
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
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
March 20, 2013, 02:05:19 PM
We have migrated to QT/C++, and have started over the version numbers the last version updated was v0.0.2.
February 28, 2013, 07:17:58 AM
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
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
February 28, 2013, 12:26:35 AM
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............
Looks like i need to get moving on this............
February 26, 2013, 06:53:38 AM
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.
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.
February 25, 2013, 11:13:13 PM
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.
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.
February 25, 2013, 12:24:48 PM
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.
But you can however test the server locally.
Have fun.
February 25, 2013, 03:21:04 AM
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
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
February 23, 2013, 07:04:17 PM
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!
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!
Jump to: