Encryption
| Message Key 32 bytes |
Server Salt 8 bytes |
Message ID 8 bytes |
Reserved 3 bytes |
Message Type 1 bytes |
Payload |
| External Header | Internal Header | ||||
| Encrypted with AES GCM AES IV and AES Key |
|||||
Message Key
Message Key will be created as shown below:
MessageKey = SHA512 (DHKey[100:140], InternalHeader, Payload)[32:64]
AES IV: SHA512 (DHKey[180:220], MessageKey)[:12]
AES KEY: SHA512 (MessageKey, DHKey[170:210])[:32]
Message ID
Message ID is produced by passing further steps:
The client provides its time in Unix Epoch. Then, it will shift the 32 bits of it to the left and add an incremental 32 bits number to it. When the server receives a message from a client, first will call the top 32 bits of it and check with the server time. If the difference between them be more than 10 minutes, the server won't accept the message. Otherwise, the server will compare the bottom 32 bits with the latest received message. So that It must be more than the message. If not, the server won't accept it again.
These security checks are occurred to prevent attack protections including Replay Attack.
Pay Attention that the Message IDs which server sends them to the client have their own sequence. These accepting steps must also be checked by clients.
Pay heed that Command, ServerSalt, and MessageID are read and wrote in Little Endian and MessageKey in Big Endian.
Payload
The payload can have different status depending on Message Type.
| Message Type | Description | Stream | Directions |
|---|---|---|---|
| 0X01 | Query | Websocket | Client -> Server |
| 0X02 | Result | Websocket | Server -> Client |
| 0X03 | Push | Websocket | Server -> Client |
| 0X04 | Upload | Http | Client -> Server |
| 0X05 | Download | Http | Client -> Server |
Description
Query (Message Type = 0X01)
| Request ID 8 bytes |
Constructor 4 bytes |
Protocol Buffer |
These types of messages will be sent from the client to the server. Depending on the constructor value, the server selects the proper method. Although in the first phase of project execution, Command Arguments send as JSON. In the next phase, one type of encoding with a lower volume will be applied for performance improvement.
Result (Message Type = 0X02)
| Request ID 8 bytes |
Constructor 4 bytes |
Protocol Buffer |
These types of messages will be sent from the server to the client. Some of this methods might have had different results. Depending on the constructor, this client can call the JASON part. As mentioned before, In the next phase, an encoder/decoder with higher performance improvement will be used.
Push (Message Type = 0X03)
| Constructor 4 bytes |
Protocol Buffer |
These types of messages will be conveyed from the server to the client online. In comparison to 0X02 messages which will be produced in the response of 0X01 messages, it does not need to receive a message from the client.
Upload (Message Type = 0X04)
| File ID 8 bytes |
Chunks 2 bytes |
Current Index 2 bytes |
Bin Data |
These types of messages will be sent from the client to the server. The client creates a FileID randomly which must be unique by session. Then, the file will be divided by 512KB. This way, the total number of chunks will be attained. After, the client can send each one of the chunks to the server separately. To take the best advantage of bandwidth, the client can perform requests parallelly. This file is saved on the server temporarily until the client calls an API to save it permanently. If this file doesn't use immediately, the server will erase it by several hours. The Current Index starts from 1 and only the last chunk can be less than 512KB.
Download (Message Type = 0X05)
| Cluster ID 8 bytes |
File ID 8 bytes |
Access Token 8 bytes |
Chunks 2 bytes |
Current Index 2 bytes |
These types of messages will be sent from the client to the server. Actually, the messages are transmitted on HTTP protocol. As a result, the related chunk will be in response to this request. After receiving all chunks, the client should create the final file and save it in the proper place.