I am Aleshin Sergei Vladimirovich, software developer and entrepreneur. You can contact me via LinkedIn.
Subscribe
2020-04-17
The P2P network is being always tested, since 2020-02. So far no failed test messages between simulated users. Also no memory leak, no crashes in the code.
There are minor errors though, I will have to fix them. Recently I have been working on this website.
Submited the messenger app to various catalogs, this can bring some traffic and backinks.
I am targeting SEO keywords "decentralized messenger", "peer to peer messenger", "open source messenger", "raspberry pi messenger", "ubuntu messenger".
Now there are 2-5 website visitors per day, and I am not sure how many users of the messenger. Waiting for some feedback.
2020-03-07
Talked to some friend via "Messenger T", so getting first users to use the messenger.
2020-03
I released the very first version of "Messenger T" for Linux, Raspberry Pi and Windows, please have a try. Now preparing docs and minimal tutorials.
2019-12-25
I designed a SQLite database, and created 2 prototype projects for the decentralized messenger:
1) "MessengerT" = "Messenger for technical people" - it is a .NET core executable, cross-platform
(Windows, Linux (Ubuntu, Debian, Raspberry Pi, Nano Pi), MacOS) with a web UI. The "web UI" is accessible via browser only from localhost.
2) "MessengerA" = "Messenger for regular people, alpha version" - Xamarin Forms cross-plaform application (Android, iOS)
There will be more "types" of the messenger, using same core. I will implement some features of facebook, instagram, youtube
and create a decentralized social network where people will share content without ads and without possibility of spying.
One more thing I discovered: there are cheap nano pi NEO AIR IoT devices with wifi, bluetooth, ARM CPU and Linux.
My further goal will be to develop a version for "nano pi" and support voice over bluetooth. This "crypto device" will be cheaper than regular Android phone.
2019-11-30
I develop the Dcomms project in a "test-driven-development (TDD)" way: I have "Proof of Concept" project, and it contains "DRP Tester 1...5" sub-projects.
DRP = Decentralized Routing Protocol, my new crypto peer-to-peer protocol that runs over UDP.
The projects simulate real-world environment, starting from easiest DRP Tester #1 (with 4 peers only and 1 message between them) to DRP Tester #5 (it is close to real mobile app, a messenger).
The DRP Tester #5 sends messages to another DRP Tester #5, and waits to receive same echo message back. It measures percent of successfully delivered messages, and delay.
I run DRP Tester #3 at 4 servers now (each server simulates 3..10 "entry peers", 10..20 users, 10..20 temporary peers). So it is a "sandbox" p2p network with about 120 peers at 4 servers, one Windows PC and one Android phone.
What I discovered:
Russian mobile operator "Beeline" drops P2P UDP packets, it is a known issue. I think it is done against torrents, they dont want to overload their network.
But "Tele2" operator works very well. Home wifi router with "Rostelecom" ISP also work well.
Android OS drops my app at night during test, maybe due to battery optimization
3-second ping interval is OK to keep UDP peer-to-peer channel alive, to use UDP hole punching technique
With DRP Tester #3 I got success with 270K messages, with P2P network simulated at single server. Now I run a test using 4 servers. During one of single-server tests my server crashed, I had to restart Windows.
I think it happened because of high RAM consumption by logs
Few things about my development style:
I see that most important thing in development is "developer's vision". It is a subsystem in my code, simiular to "log files", but with selective attention. It emits "detail", "light pain", "strong pain" signals
to the developer (me) with details about the errors. For example it visualizes state (snaphot) of P2P network at a moment when message delivery failed.
I look at the visualization and understand what is wrong and what has to be fixed.
Another important thing is not to put deadlines to the development, and focus on quality of the product, not on meeting deadlines.
It is more important to simulate a virtual real-world environment (like "bad internet connection") and get errors myself, before I get error reports from real users. And number of errors is unknown.
I fix about 1 new unknown error every day.It is highly unpredictable development, and I can change the DRP protocol to fix the errors.
I work with few consultants to make sure that I do not create security holes, to understand possible attack vectors
I don't care now about "look of the website", "promotion", "monetization" (I have enough of money already), "PR campaigns",
I think the project is strong and it will promote itself with no super-marketing-efforts from my side. The "external face" of the app and website is not important while the app is being developed.
Next things to do:
Simulate bad internet connection in my virtual test environment, to make sure that the messenger is robust
Use SQL lite .NET on android, raspberry pi, Windows, define database schema (users, keys, messages history); use previously discussed technique to encrypt selected fields (like private key) using hardware security module (HSM) via API
Define structure of UI: views (pages). I am going to refer to existing messengers: WhatsApp, Telegram, Signal. I see that the UI is very simple, less than 10 views.
Full TODO list contains about 500 items.
2019-10-1x
Sucessfully simulated peer-to-peer routing within registrationID 8D space, got a reasonable number of hops (below 10) with 100M peers, each peer having 13 neighbors.
See DrpTester4 (distance) sandbox.
I had to use concept of simplex in 8D space, and sector, to avoid "torn areas" in the P2P networks.
An existing approach f connecting to absolutely random peers, like in bittorrent/OpenDHT is not good.
This simulation is very important, because I want to have a P2P network with a very well organized structure and static neighbors, to gain mutual trust between neighbors.
The network is scalable as O(sqrt8(N));
2019-09-23
Sucessfully sent first test message via direct channel, within DrpTester1 sandbox.
2019-09-12
Discussion with Ilya about UserID, certificates, HSMs, root keys:
2019-09-06
Every good developer should write good comments to his code. The comments help others to understand and verify the written code.
In my project (the dcomms.org) I find that text comments are not enough and they don'e explein the system very well. So I use graphical comments, it is a set of diagrams on "draw.io".
The main diagram is here, if you want to see what happens inside the "dcomms.org". We use this diagram when discussing the system with team in order to find insecure operations. .
I recorded discussion with Yurii:
2019-08-23
I am working on a big diagram of the DRP protocol.
Main parts of the protocol is implemented: registration requester side and responder side.
I am following "test-driven-development" strategy, and today will run first real DRP registration procedure within "CryptographyTest" project.
2019-08-19
General overview of the system with Yurii
2019-08-01
Recorded one more discussion with team: AES initial vector, need of signatures in REGISTER packets
2019-07-30
Recorded one more discussion with team:
2019-07-22
The DRP protocol is mostly defined. I recorded one of discussions with team:
2-step anti-DoS protection when a new peer connects to rendezvous node
Ed25519 signature/verification will be used once, when a peer connects to neighbor
Strict limits will be put on every P2P connection, about 3 requests per second, against DoS attacks
HMACs will be used to validate ping packets between peers, and also proxied requests
Packets will be called REGISTER and INVITE, similar to SIP
Peers A and B will create direct UDP channel using UDP hole punching technique, without servers, set up a secure channel using preshared keys, and exchange text/voice/video/file data
XOR-based distance metric will be used to lookup peers (similar to OpenDHT)
The messenger will be used by people who first meet in person, exchange public keys (to avoid MITM attack) and contact each other later via the network.
2019-07-07
After having a discussion with team and some market research, I decided to concentrate on "Distributed Routing Protocol", to create a messenger with full privacy protection. No surveillance.
Main competitors are: matrix.org (vector.im), bitmessage, tox messenger, status.im. The market looks like growing and in trend.
I work on a protocol whitepaper now, discuss potential attacks and solutions with (hired) cryptographer and IT security engineer, all from Russia.
I find it is not easy to create a P2P network which is stable against DoS attacks, but.. we have come up to some solutions. Here is a brief summary.
In my opinion the best thing to invest right now - security audits.
2019-06-28
Recently I finished implementation of "anti-DDoS / proof of work" subsystem in my "Centralized Communications Protocol".
And started to implement subsystem "Shared Key Derivation". I talked to some freelancer Ilya about the design, and got few valuable ideas on how to make the CCP more secure.
I will continue hiring freelancers for security audit, it is very important to get unbiased look of the CCP at this development stage.
So I started to think about shared key derivation, using ephemeral (temporary) private keys, Elliptic Curve Cryptography Diffie-Hellman (ECCDH) key exchange procedure.
I downloaded Visual Studio 2019 Community preview 6 to compile new code under .NET standard 2.1 in order to use Microsoft's implementation of ECCDH. And.. performance is awful: 1.3K operations per second.
SHA256 procedure is implemented well by Microsoft, I have 400K operations per second on a single CPU core.
I'd like to design a server capable to handle about 1M client-server handshakes per second on an average server, and I have to use a faster implementation of ECCDH.
2019-06-18
Today I was thinking about "surveillance" feature in my future messenger. It conflicts with requirement that it is "open", in this exact way:
I want to have users communicating without server, for reasons of higher performance and redundancy against DoS attacks.
It means that server (center) is only used to sign user's certificate (to avoid complete anarchy in the P2P network).
The server does not have any access to the messages. Furthermore, contact book and messages history both are locked incide user's device. Server will not have access to "social graph" in my system.
Only way to view the messages and "social graph" / "contact book" for the "center" is explicit report by user of user's messages and contact book.
If I have this messenger running as an open source project, everyone will be able to modify the "reporter" module in the messenger, to turn it off, or report fake contacts and fake messages to the "center".
Considering the above items, I think that surveillance will not be possible, and I will be able to provide surveillance for "center" only if users use a version of messenger with "reporter",
if users don't compile the open source messenger with "reporter" turned off.
This correspond to the fact in real world: every two humans have ability to escape and talk privately, and no one will be able to hear them. So my messenger just reflects principles of real world.
2019-06-19 UPDATE: I think I found a way to make everyone happy: the messenger will work in two modes (over 2 protocols):
both decentralized (with no surveillance) and centralized (with surveillance, controlled by governments). So corporations will use "decentralized" mode,
having the communications really secure within organization, for business purposes.
At the same time regular people will use messenger in "centralized" mode, controlled by governments, with surveillance, legal protection and control.
And there will be "gateways" between the "messenger networks", it is similar to the way how PSTN works now.
2019-06-13
I have mostly finished design prototype for a secure protocol between client and server. I think it will be called "Centralized Communication Protocol".
It will run over UDP for the first time. This protocol is a competitor to SIP, HTTP, HTTPS, TLS, SSH. How do I make it better?
Anti-DoS features: I hope it will make brute force attacks practically impossible
I introduce two proof of work procedures, based on SHA256. From real experience of Bitcoin I know that the concept of "Proof of work" works very well
The first PoW procedure, "stateless PoW" will be included into an initial "hello" packet sent from client (in TCP it means adding proof-of-work field into SYN)
Requirement to perform "proof of work" before sending an initial hello should dramatically increase complexity of DoS attacks. With TCP SYN or SIP INVITE it is very easy to run a DDoS
There will be second stage - stateful proof of work: server will generate a unique task and send it back to client, and wait for a valid response. When a client is suspicious, it can be a CAPTCHA request, involving human
Perfect forward secrecy: gives assurances that session keys will not be compromised even if the private key of the server is compromised.
Protects past sessions against future compromises of secret keys
Also, I also got an idea of using users who use my future messenger for bitcoin mining, as proof of work.
But I don't think that I will do it, because that will (probably) load user's device too much. But.. who knows.. anyway, I need to get some money from the open source messenger.
Today I got 6 spam calls to my mobile phone. These were SPAM calls from call centers. This number increases, and I have turned on anti-spam filter to silently ignore all caller ID's that are not in my contact list.
Businesses are trying to penetrate my attention, and telcos allow them to do it. The telemarketing brings chaos into communications.
Same thing with emails, about 6 spam emails per day. Will these numbers increase? Why not? And who will build a new communication system that will automatically block spam?
2019-04
The world is complex, and the complexity is infinite: the picture of Madelbrot fractal is taken from sciencedemos.org.uk
There are too many types of attacks on the protocols, and this list shows only top of iceberg:
Denial of Service attacks
TCP SYN flood
UDP flood
Reflected UDP flood (e.g. memcached)
Fuzzing attacks (sending malformed packets)
Stateful fuzzing
Source spoofing attacks. E.g. see FCC's issues with caller ID spoofing. I don't like this lawlessness
Phishing attacks
Eavesdropping, MITM
Brute force attacks
Offline dictionary attacks, birthday attacks
SPAM attacks
Sybil attacks
Replay attacks, delay attacks
Protocol downgrade attacks
I am developing the new protocol(s) now, trying to make the messaging really secure.
2019-03 I research current situation of telecommunication industry. Instead or merely copying currently developed protocols, I am going to research the protocols, technologies and products to build my own understanding:
IP, TCP, UDP, SIP, RTP, DNS, DHCP
ZRTP, SRTP
Briar messenger
Signal protocol, Double Ratchet Algorithm
MTProto
X.509
Blockchain, bitcoin
Tor
I2P, garlic routing
BitTorrent, DHT (magnet links)
BitMessage
WhatsApp
Skype
Email ecosystem
TLS
WEP, WPA, WPA2
Matrix.org
Tox messenger
2019-02 I got an idea of creating a secure messenger. The messages will be routed via a mesh network - decentralized and redundant routing, without servers
.
