خرید و دانلود نسخه کامل کتاب Blockchain Technology and Emerging Technologies – Original PDF

6 I. Grishkov et al. Fig. 1. Self-encryption process, adopted from [11] 3 Background Original implementation of the self-encryption schema by David Irvine [11] was modified and used for this research. The use of rayon library (which adds paral- lelization to the code) was removed from the algorithm, due to the fact that the compilation target (WebAssembly) only supports single-threaded code. Addi- tionally the code base was modified to include an interface for communication with the external code. Changes were also done to the Cargo.toml to make the code compatible with the target. Modified self-encryption algorithm was com- piled to WebAssembly and run in a virtual machine (VM) and invoked from the code of the developed local application (which allows the interaction with the Hyperledger Fabric Smart Contract). A more detailed description of the pro- cess will be given in the Sect. 4. The benchmarks of this implementation will be provided in Sect. 5. Hyperledger Fabric test network v2.4.3 was used. Test network was deployed to Docker based on the tutorials provided by Hyperledger Fabric2. Smart contract was then deployed (detailed in Sect. 4). Encrypted file storage is handled by the IPFS, which is a distributed Torrent database, which uses hashes of files to address its content. IPFS node was also deployed to Docker. For IPFS deployment two directories (staging and data) were 2 Usage of the command requires navigating to the root directory of the test-network, provided by the Hyperledger Fabric [8]. ID-Based Self-encryption via Hyperledger Fabric Based Smart Contract 7 mounted on the host file system to persist the stored data, when the container is stopped. Hyperledger Fabric provides official software development kit (SDK) for 3 languages: Go, Java, Javascript. Go was chosen for implementation of the project, due to ease of integration with both Hyperledger Fabric and the IPFS. Encryption library is written in Rust and is compiled to WebAssembly, hence a way to call WebAssembly was needed. Go also provides support for Wasmer library that allows to call WebAssembly function directly from Go code. 4 ID-Based Self-encryption 4.1 Integrating Identity into the Encryption This paper offers an extension to the algorithm proposed by Irvine [9]. Encryp- tion step in the original algorithm is modified to include identity of a person who is running the algorithm into the encryption process. Instead of using part of the chunk hash as a key for AES 128, the result of XoR of the hashed iden- tity and the chunk hash is used as a key. The identity can be any string of any length. If the length of this string is shorter than the length of the key, then the cycle function is applied to the string, which repeats the iterator of a string. The hashing function SipHash 1-3 is used to hash the identity of a user, before passing it to the XoR function. Figure 2 demonstrates the process of encrypting a file using the modified version of self-encryption with identity integrated into the encryption process. Fig. 2. ID-based self-encryption process 8 I. Grishkov et al. Decryption of the file, that was encrypted using ID-based self-encryption, is similar to that of a regular self-encryption, with the key for AES 128 being the only different part. The decryption calculates the key the same way the encryption does it by applying XoR function to the hash of identity and the chunk hash from the data map. The implementation of the encryption scheme can be found on GitHub3. 4.2 Connecting the Encryption Algorithm and the Local Application The implementation of the identity-based self-encryption is written purely in Rust, while the client application is written in Go. This creates a demand for a way to integrate Rust library into Go code. Among the solutions to tackle the problem are: 1. Use Go tools to assemble the Go code and compile Rust code into a static library. Then link compiled code using additional assembly “glue-code” [17]. 2. Compile Rust to a static library and call it from the Go code using Go build-in pseudo-library C for interacting with native interfaces. 3. Compile Rust to WebAssembly (WASM) code and call it from Go using Wasmer library4. All of the methods have been successfully tried. The first two methods do not allow cross compilation, because both of them require compiling Rust to a static library, which is platform-specific. Additionally, the first methods requires the use of assembly language, which is different on different processor architectures and operating systems. The second method also uses C pseudo-library, which does not allow cross-compilation of the Go code. Overall, both methods are very platform-specific, which makes them less preferable choice. The third method was chosen for connecting Rust library to Go code. Com- piling Rust to WASM to use as a standalone application or a library, can be done using the following command: $ c a r g o b u i l d −−t a r g e t =[ c h o s e n t a r g e t ] where chosen target is a WebAssembly target that can be either wasm32- unknown-unknown or wasm32-wasi. The latter was used, because it compile using WASI API5, which is a system API that provides access to multiple oper- ating system functionalities, such as access to the file system. The resulting WASM file is then placed in a hidden folder in the home direc- tory of a user, so it can later be loaded by the Go code. As the WASM code is used within a virtual machine (VM), it’s independent from the operating system it will run on, so requires compiling only for one target. 3 https://github.com/ilyagrishkov/ib-self-encryption-rust. 4 https://wasmer.io/. 5 https://wasi.dev/. ID-Based Self-encryption via Hyperledger Fabric Based Smart Contract 13 is in Go), the execution time can differ when Rust functions are called from Go compared to pure Rust execution time. Files of sizes 100-, 250-, 500-, 750 kilobytes, 1 megabyte, 10-, 25-, 50-, 75-, and 100 megabytes were created for benchmarking both the pure Rust implementa- tion as well as the WASM + Go implementations. Moreover, for this benchmark both the Rust code and the WASM library were optimized using maximum level of optimization provided by the Rust compiler. Fig. 5. Dependence of the execution time of id-based self-encryption algorithm in pure Rust from the file size The initial benchmark was performed on the encryption function only and was measuring execution time of the pure Rust implementation. Figure 4 shows the results of the benchmarking. The chart show near-linear dependence between the size of the file and the time it takes to encrypt it. This dependence can be explained by the fact that the most demanding computational is the AES 128 encryption process and with the increase of the file size, then number of chunks it is split to increases. Each chunk of the original file needs to be individually encrypted, hence the computation time grows linearly with the size of the file. As the encryption function execution time grows linearly due to the com- putational demand of the AES 128 and the hashing algorithms, the decryption process will be identical, because it uses the same algorithms for decryption. In order to achieve more objective benchmark results, file of each size has been encrypted 100 times and the average calculated. In order to visualize execution time a chart in Python using MatPlotLib8 was created. The chart contains a 25- bin histogram, each representing density of a particular measurement. Follow