## 4 Proposed Solution
The key \(K\) used for the encryption and decryption process can be derived as follows:_  
\[K=KDF(P,s,c,dkLen) \tag{2}\]  
_where \(s\) is the salt, \(c\) is the number of iterations, and \(dKLen\) is the desired key length._  
Figure 1: The architecture of the proposed solution. One of the novelties of the proposed solution resides in the fact that it does not store the encryption secret or keys. Instead, it encrypts a known string \(S\) with the secret and stores this encrypted string on IPFS. Algorithm 2 illustrates the process of verifying a secret without storing the secret or keys anywhere. Given the secret \(P^{\prime}\) provided by the user, the corresponding key \(K^{\prime}\) is derived using the _KDF_ function. Then, the encrypted string \(E(S)\) retrieved from IPFS is decrypted by using \(K^{\prime}\). If the obtained decrypted string \(S^{\prime}\) corresponds to the original string \(S\), then the provided secret is correct, and the verification is successful; otherwise, the verification fails. ```
1:procedureVerifySecret(\(P^{\prime}\))
2: Retrieve the encrypted string \(E(S)\) from IPFS. 3:\(K^{\prime}=KDF(P^{\prime},s,c,dkLen)\)
4:\(S^{\prime}\gets D(E(S),K^{\prime})\)
5:ifS' = S then
6: the secret is correct
7:else
8: the secret is incorrect
9:endif
10:endprocedure
```  
**Algorithm 2** Verification of a secret \(S\) without revealing it  
If the secret verification is successful, the data are encrypted using the derived key \(K^{\prime}\), as reported in line 6 of Algorithm 1. The encrypted data are then combined with the hashed data inside a JSON object (see line 7 of Algorithm 1). **Definition 3** (Encryption). : _Let \(E\) represent the encryption function, \(K\) the key derived from the secret, and \(D\) the data. The encrypted data \(ED\) can be obtained as follows:_  
\[ED=E(K,D) \tag{3}\]  
Once the _combinedData_ are generated, it is stored on IPFS. IPFS generates a unique CID, representing a reference for the encrypted and hashed data on IPFS. The blockchain is the final step of the proposed architecture. After storing the encrypted data and the hashed data on IPFS and obtaining the corresponding CID, this CID is stored on the blockchain through a smart contract. Such a smart contract will maintain a list of CIDs related to the data stored on IPFS. The immutability of blockchain ensures that the CID is recorded and cannot be changed or removed, which provides an auditable track of the data integrity and traceability. The primary purpose of this smart contract is not only to store CIDs permanently but also to retrieve and verify the persisted data. Algorithm 3 illustrates the function DataVerification, which performs an integrity check about the current content of the centralized database and what has already been stored in the IPFS. After retrieving both contents, \(D_{api}\) and \(D_{b}\), respectively, the function analyzes if each row in the database is already contained in the blockchain and, in this case, if the hashes are the same. The newly identified records are then stored in IPFS, as illustrated in Algorithm 1, and a transaction gets performed to store the corresponding new CID. Conversely, the records whose hashes do not coincide become classified as corrupted or inconsistent. This consistency verification does not need to decrypt the stored data but is based only on comparing the hashes. However, based on the specific policies of the system, in case of corrupted or inconsistent data, their original version could be eventually retrieved through a decryption of the encrypted data contained at the corresponding CID. The proposed solution allows for continuous monitoring of data updates in an efficient and secure way. We improved the system's privacy and security by not decrypting the sensitive data but only comparing hashes. Furthermore, by employing blockchain as an immutable storage for comparisons, we ensure that the verification process is tamperproof and auditable.