Rules of a parent, without true understanding of his child, when the child grows enough to live by his own rules, can turn into abuse of power, manipulation and violence.
Furthermore, the parent's rules can be obsolete, insecure, or violent by themselves.
• storing your data (photos, messages, contacts, passwords) on servers that you don't own
• requirement to link account with your email or phone number
• increasing number of advertisements on youtube and TV
• possibility of receiving calls/messages from anyone, which means spam
• facebook's limit on number of characters in instagram post
• scandal with "Crypto AG" company
What is Dcomms?
Dcomms.org is a non-profit organization, funded by an independent software developer Aleshin Sergei Vladimirovich
, solo enterpreneur.
We expect to see profit from users' donations, not from showing advertisements or spying.
We develop an open source framework
to build decentralized peer-to-peer (P2P) cryptographic communication systems with full privacy.
The framework is designed to build various customized messengers and applications; it also includes its own decentralized messenger and continuous internet speed test tool
The diagrams explain the problem:
- Users communicate without servers. No server is able to sniff contact book, by tracking sender and receiver IDs
- Peers run directly at mobile devices (Android, iPhone), on Windows or Linux machines. The project is cross-platform (.NET standard, C#)
- Peer-to-peer (P2P) network does not put limit on transmitted data size. Users can exchange huge data files directly, without servers, using "UDP hole punching" technique
- There is no link between user ID and phone number / email
- Users are able to compile the messenger from source code, audit the source code themselves, and run the messenger on Linux/Windows/Android/iOS
- The protocol and implementation is done by a single developer, with help of team, with no rush and with high quality.
The developer has 100% control and responsibility for the system
- The project is developed with help of team: various cryptographers, penetration testers and security engineers. We discuss vulnerabilities and countermeasures since the very beginning
- The project is open source, under MIT license. Everyone is able to create his own messenger, with own brand and customizations, and the messengers will be interoperable
- Implementation is done in C# programming language, it avoids memory corruption vulnerabilities that are common to C++ implementations
- User's personal data (private keys and contact book) is stored only at his own device. User can backup the personal data himself, store in safe place, restore to another device
- Users or organizations can run same messenger via private IP networks and rendezvous peers, physically separate from public P2P network
- The protocol includes automatic QoS tests, when the software checks quality of network and peers to select best path for messages across P2P network
- The protocol automatically bypasses NAT and firewall
- Users initiate connection via peer-to-peer network, via multiple paths. Downtime of a single element does not interrupt operation of entire network
- End-to-end encryption is always turned on in the messenger. Unencrypted mode is not possible
In traditional telecom and web 2.0 industry you control only part of the game. You don't know what happens on server side.
With the Dcomms you are able to fully control the game.
Within Dcomms peer-to-peer (decentralized)
network you control how you talk to peers and contact users, and you can ignore unknown or suspicious ones.
You see IP address of peers/users and exact time when packets/messages are delivered.
Having private keys of your friend users in your contact book,
you authenticate the friend by checking his identity using a digital signature.
There are no central certificate authorities that you have to trust, as with HTTPS when you access a website when you send an email.
Let us explain how the Dcomms system works in a metaphoric language
Imagine the Dcomms peer-to-peer network as a crowded square with people ("peers") who speak same language ("Decentralized Routing Protocol, DRP").
When you run the messenger with your own peer, you select how to enter into this square (select "entry peer"), and coordinates at the square where to stand ("registration ID").
Then you discover neighbor peers near you and talk to them.
You build some reputation by the talking, as they ask you to proxy some encrypted phrases (DRP packets).
Then you send your own encrypted phrase: ask the neighbors to deliver your "invitation to talk" to your known friend (both you and friend know coordinates of each other at the square).
People (peers) deliver your encrypted invitation and your friend has a choice to accept it or not.
He verifies your coordinates (you digitally sign the invitation with coordinates).
If he is OK to talk to you at this time, he sends back encrypted answer to your invitation and the crowd delivers the answer back to you via same path (same route back to sender).
So you and your friend exchanged invitation and answer packets (this is not actual message yet),
and the packets contain encrypted coordinates of "direct channel".
The direct channel is a fast, direct UDP 2-way stream, it does not go via neighbor peers.
Imagine direct channel is something above the square, like laser beams between your and your friend's lasers which are precisely positioned directly to each other.
The bidirectional laser beam is used as a transport for your messages. The laser is fast and doesn't depend on people (peers) in crowd (P2P network).
Via the direct channel, you and your friend set up encryption keys for every new session.
Then you send end-to-end encrypted (AES256-CBC)
and signed (HMAC) messages via the direct channel, without any servers.
The square (P2P network) has huge capacity, for all people in the world. It has 8D space, and the "people on square" do not have "physical size", so new people dont crash the system.
This is how it works in general, and there are thousands technical details, you can read our whitepaper about the DRP protocol,
or look into source code.
In traditional telecom industry "server" is a black box which is under control of some "center". You can not control the server and people who manage the servers.
You have to trust some third party, authority (google, facebook, verisign, or your own IT team) when you send a message.
You don't know true intensions of "centers": why they develop messengers and social networks, giving it to you for free, while they have to pay huge salaries to software developers.
How do they get this money back?
Even if it is end-to-end encryption, the "center" can track source and destination ID's (phone numbers) and see who you talk to and when.
In this way they can track your contact book (your contacts are not really private), build your profile and show targeted advertisements.
If you are a company and have your own servers, do you 100% trust your IT team, inclusing ex-employees?
With the Dcomms you don't have to worry about your privacy, you dont have to follow some hidden rules and intensions of the "center".
Everything is decentralized.
You are protected with cryptography (DRP protocol, AES-CBC, ECDHE, Ed25519
) and few simple rules that you can follow:
- Physically protect your device(s)
- Install and run software only on trusted devices, and better open source OS like Linux, Raspberry Pi, without backdoors, malware and viruses
- Don't add to contact book unknown people who can be potentially dangerous. Better talk only to true friends that you know personally.
For unknown temporary contacts better have a separate account and separate device
- Delete suspicious contacts from your contact book
- Use 2 physically independent channels to send "contact invitation" (e.g. email and SMS), and better add friends to contacts when you meet them in person
successfully passed first test 1000 messages between Android and Windows devices, within
after few real tests with Russian mobile internet providers (Megafon, Tattelecom, Beeline) I discovered that they block peer-to-peer UDP traffic with (most probably) symmetric NAT.
Tele2 operator was OK, home wifi internet is OK. I am going to spend some time trying to bypass symmetric NAT using some advanced UDP hole punching techniques, and if I fail, wil lcontinue targeting on home Linux-based PCs and home wired connections, because I know torrents with DHT work well.
I did not succeed running DRP peer via mobile internet + VPN, so continuing with 2 devices in design: one "backup" device at home, conencted via wifi and home internet (which allows p2p traffic) and a mobile device which is connected to private home device. The "home device" will work as a "private home server", and it can be windows, linux, iphone or android device
delivered first text message between instances of "Messenger T". Browser-based HTML UI framework is ready for raspberry pi / linux, windows, mac os
I am not sure how many users use the messenger now. Waiting for feedback
Developers, analysts, cryptographers, cybersecurity experts (short-time advisors):