## 3 MuReQua Decentralized Storage and Security Engine (MuReQua DeSSE)
### Other Details About the Uploading Section  
Here in the following, we have the following description of the first five steps and other accessory details, while we will dedicate a specific sub-section to step number six. Registration is carried out by entering an email, first name, last name, and a password consisting of at least eight characters, including at least one number, one lowercase letter, one uppercase letter, and one special character. During registration, the system captures the following data from the client device:  
* IP address;
* Operating system;
* Browser language;
* Keyboard configuration (e.g., QWERTY);
* Geolocation. The system employs a second factor of authentication. At each access, the system sends a one-time password (OTP) via email. During registration, it is possible to enable a third factor of authentication based on biometric data, such as fingerprint or facial recognition, depending on the user's preferences and the type of client device. Upon registration, the user is assigned a unique ID consisting of a 64-character alphanumeric sequence. With respect to point 1, a random and dynamic number of fragments is generated according to the following Table 2.  
The system takes two contiguous fragments, concatenates them, and then divides them again into two fragments with a random percentage of content, ensuring that the percentage of each fragment is not less than 25% and not more than 75%. With reference to point 2, each client-side fragment is encrypted with AES-256. With reference to point 3, the fragments received from server1 and sent by the client, after being decrypted, are converted from base 10 to a base between 11 and 94 randomly for each individual fragment. The number 94 represents the total number of printable characters in the standard ASCII alphabet, which includes the 10 digits, the letters of the English alphabet in both lowercase and uppercase, and special characters. After the conversion, each fragment is encrypted with AES-256. The fragments contain a set of metadata useful for identifying the original file and its owner. With reference to point 4, the fragments are sent from server 1 to server 2. Server 2 progressively decrypts them as it receives them and starts to create an allocation tree of n \(\times\) m positions after reading the available nodes for storing the fragments. Each node (i.e., server/storage) can contain multiple memory locations, with a tree-branch-leaf nesting logic, having a depth of 10 and a width of 10, for a total approximate number of positions given by #(positions) = 1.1 \(\times\) 1011, or \(\sum_{i=1}^{10}10^{i}\), calculated with Equation (1):  
\[S=a\frac{r^{n}-1}{r-1} \tag{1}\]  
where \(a\) = 10 and \(r\) = 10. Each allocation is characterized by two parameters: the first is the IP address of the server/storage, and the second is the allocation within the server/storage, defined by the nested directory structure and the file name assigned at the time of its allocation. The file name is a 200-character alphanumeric string. For each of the n fragments \(Fr\), a secondary fragmentation into m sub-fragments occurs, where the size of each sub-fragment \(Size(Fr_{m})\) is calculated as follows in Equation (2):  
\[Size(Fr_{m})=\frac{Size(Fr_{n})}{m} \tag{2}\]  
According to the size allocation and depending on the original file size as per the previously provided table, each of the n \(\times\) m fragments is first encoded with AES-256 and then with a proprietary two-key encoding, as described below:  
* A character position is randomly chosen. * The chosen character is replaced with a character obtained through a random shift in the alphabet. The resulting fragment is not yet final, as it only refers to the actual initial content. Subsequently, on this server, the fragment is enriched with meta-information regarding the concatenation between the considered fragment and another pair of fragments. This