rchitecture
The overall design refers to p2p protocol and icq and other distributed protocols, but does not set a central server, the design to the ultimate anti-surveillance and privacy protection as the goal, the front-end does not consider user friendliness and UI design, can be made into a command line
- Public key signature and public key MD5
Use this password to encrypt the RSA private key (symmetric encryption) and attach the plaintext MD5
Converts the encrypted private key to base-32, generating a string of letters and numbers, and gives the user a request to print or copy by hand or store it in a safe place
Use this password to encrypt the RSA private key (symmetric encryption) and attach the plaintext MD5
Makes the encrypted private key into three two-dimensional codes, each of which contains the sequence information and part of the key
Replace the password entered by the user with the dongle key or both. The remaining steps are the same
also asks for a password, then stores the file directly locally, and asks users to keep the file safe
Adds time stamps, random check codes (to prevent duplicate messages in some cases), RSA public key encryption, and MD5 operations
Checks the verification codes and time stamps to eliminate duplicate messages and sort the messages in order based on the time stamps
- Determine the online status and obtain the online status table
- Create a routing table
- fan-out=10 (Normal number of online users) fan-out=50 (small number of people online)
- All but the last level must be online members
- Except for the first level, each level receives at least three transmissions from the upper level
- If there are inactive members at the next level, the inactive member id and the timestamp of the corresponding message are stored in the "To be sent Information table".
- The last level can contain non-online members, broadcast the whole group when online, and then retrieve the "to send message table" and send the unsent message
- Add timestamp (ms level exact value), send route table, random check code, sender ID, next-level member RSA public key encryption and add plaintext MD5
- Sends the MD5 of ciphertext and plaintext to the next level
- The next level receives the message
- RSA private key decryption and MD5 authentication
- MD5 correct
- As if nothing happened
- MD5 is incorrect
- Resend the public key and request resend
- Sort and display messages by timestamp, and display avatars and nicknames by ID
- Read the routing table
- Determine whether to send again
- No
- Yes
- Determine whether all members of the next level are online
- Yes
- No
- Online Members
- Not an online member
- Put the other party ID and message timestamp Stored in the message to be sent table
- Received the call online
Randomly select the number of users that is the quadratic root of the total number of users, let's call them zero-level members
- Determine online status
- Some not online
- Exclude the ones that are not online and re-randomly pick them until they are all online. If more than 10 rounds are still not all online, the online status of the whole group is directly obtained, the online people are directly selected, and if the number is not reached, the next step is directly forced
- All online
- Continue
- Divide the remaining users
- Number of tables = number of level zero members
- Each user is included in at least 3 tables
- Create a routing table in each table
- fan-out=10 (Normal number of online users) fan-out=50 (small number of people online) (non-final level only)
- All but the last level must be online members
- Except for the first level, each level receives at least three transmissions from the upper level
- If there are inactive members at the next level, the inactive member id and the timestamp of the corresponding message are stored in the "To be sent Information table".
- The last level can contain non-online members, broadcast the whole group when online, and then retrieve the "to send message table" and send the unsent message
Adds a timestamp (ms level exact), a routing table for each level zero member, a random check code, sender ID, RSA public key encryption for the level zero member, and MD5 in plain text
- Add timestamp (ms level exact value), send route table, random check code, sender ID, next-level member RSA public key encryption and add plaintext MD5
- Sends the MD5 of ciphertext and plaintext to the next level
- The next level receives the message
- RSA private key decryption and MD5 authentication
- MD5 correct
- As if nothing happened
- MD5 is incorrect
- Resend the public key and request resend
- Arrange and display messages by timestamp
- Read the routing table
- Determine whether to send again
- No
- Yes
- Determine whether all members of the next level are online
- Yes
- No
- Online Members
- Not an online member
- Put the other party ID and message timestamp Stored in the message to be sent table
- Received the call online
Public key of the signature and MD5 of the public key
- This item can be updated manually
- Send your own information and public key
Receives user information from the server and encrypted contact details and signature verification questions in plain text
- Decision online
- Connect tracker updates the connection mode and online status
- Connection mode updated, online
- Reexecutes the status check
- Connection mode updated, offline
- Reexecutes the status check
- Pass
- Online
- Not passed
- Offline
- Connection mode is not updated, offline
- Offline
- Connection mode is not updated, online
- "Status unknown"
System port receives network status changes, detects the network when the status changes, sends a new connection to the tracker, and refreshes it when the PPP connection is unavailable
update when Gossip spread (the content of the spread is "ID: xx profile picture update", not directly spread the profile picture)
- Regardless
- PPP transfer update
This section of the requirement can not be easily removed or modified by some metaphysical way to make the entire core function of the application can not run without this thing
refer to v2ray to disguise the traffic in http form and simulate the behavior of the http server as much as possible
Design objectives: Can be simple and fast deployment (x-ui deployment difficulty) without storing private information or information that may cause serious privacy leakage (chat logs, etc.), store as few files as possible, and use cpu and bandwidth as low as possible (requiring that the information stored locally does not exceed 20GB and the bandwidth does not exceed 3mbps when serving 1000w users). With a simple firewall (or a recommended firewall software once deployed), it can withstand a certain level of attack, and the information cannot be directly viewed by the server owner.
The user ID to connect to here Online status and communication methods And the verification problem
bitlocker information with a key that is encoded when the software is written. The key is not stored in an open source library. It is encrypted with bytecode in the software
####, and then the user will connect to the tracker and send the connection information