I am Aleshin Sergei Vladimirovich, software developer and entrepreneur. You can contact me via LinkedIn.
Subscribe
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
.
