Data storage on personal computers is inherently insecure as authentication and file access control ... encryption software that can encrypt individual files and.
DESIGN AND DEVELOPMENT OF A USER BASED SECURE FILE SYSTEM FOR LINUX USING FUSE Venkatanatha Sarma Yerragudi1, N.D.Gangadhar2, Dipayan Mazumdar3 1-M.Sc. [Engg.] Student, 2-Professor, 3-Assitant Professor Department of CE, M. S. Ramaiah School of Advanced Studies, Bangalore 560 058
Abstract Data storage on personal computers is inherently insecure as authentication and file access control are handled by the host operating system. These security provisions can be bypassed if another operating system is used on the same personal computer. To address this problem, file encryptors, disk encryptors and file system encryptors were developed, each with its drawbacks. By combining the strengths of file encryptors and file system encryptors, these drawbacks can be overcome. To achieve this, a user space file system library must be used. The file system must also have its own authentication and authorization routines to provide uniform access across multiple operating systems. This paper describes the design and development of such a file system for Linux using the FUSE library and the OpenSSL library. The design for this file system was mathematically modelled and formally verified using Alloy analyser. The file system requires the user to provide user name and password for authentication. Each file is encrypted using a separate key to provide security against cryptanalysis. This key is encrypted using the owner’s private key to allow for change of ownership. The password is used to decrypt the user’s private key. The developed file system was tested for authentication and access control successfully. The optimal performance of the file system was perceived at file sizes between 1 kilobyte and 256 megabytes. The performance degradation due to encryption was also measured and found to be within usable limits. This stackable file system can be used on all Unix clones that have FUSE and OpenSSL libraries. Keywords: File System, Security, User Authenticating File System, FUSE, openSSL digital certificates and other such confidential information on their personal computers. However, such data stored on the personal computer is not secured against eavesdroppers by default. Operating systems provide authentication and access control to the personal computer which can be bypassed easily. By booting in to a live boot disk, provided by distributions such as Ubuntu, it is very easy to mount the local hard disk and access the information.
Nomenclature s seconds B bytes Abbreviations AES Advanced Encryption Standard API Application Programming Interface b64 Base 64 BBFS Big Brother File System CFD Control Flow Diagram DFD Data Flow Diagram EFS Encrypting File System ext Extended file system FAT File Allocation Table FS File System FUSE Filesystem in USEr space iNode index Node I/O Input/Output MD5 Message Digest 5 NT New Technology NTFS New Technology File System OS Operating System PGP Pretty Good Privacy RSA Rivest Shamir Adleman SFS Secure File System SSL Secure Socket Layer ZFS Zettabyte File System
To remedy this problem, there are many available solutions: One of the approaches is the use of encryption software that can encrypt individual files and provide confidentiality. However, it is not easy to manage multiple passwords. Using same password to encrypt many files can be a security risk in itself. Also, if applications on the personal computer have to use such a feature, they must be rewritten to integrate with the encryption software. Examples of such applications are AES Crypt and PGP file encryption software. These applications may be classified as file encryptors. Another approach to solve the problem of data security in personal computers is the encryption of the entire disk file system itself. Some kernel level applications encrypt the entire disk contents using a single encryption key. Such a solution to resolve the issue of data security in disk file systems can be classified as volume encryption approach. Though the information is secured against external eavesdroppers, this form of security does no protect against eavesdropping by the other users of the personal computer. Also, only a single user can access the information if the key is not shared.
1. INTRODUCTION All applications of computer systems depend on data and hence, depend on data storage. Users of these applications may store information such as bank statements, website passwords, government issued
TECH Journal
SAS
8
Volume 10, Issue 1, May 2011
They conclude that it is practical to provide encryption in the file systems. Vishal Kher, et.al, [5] present the requirements of a secure distributed file system. They provide a clear description of security services provided by a secure file system. They classify different file systems based on security and compare some available file systems with respect to security. Hughes James P., et.al, [6] provide an account of security mechanisms in existing local and networked file systems. These details are helpful in understanding the existing security provisions in file systems. David Mazi`eres et.al, [7] provide a file system model that allows for key management in a separate authentication server and user authentication at client agents. They discuss a file system that ensures that the user is accessing the correct file contents by the use of self-certifying path names. Matt Blaze [8] provides an escrow smart card based authentication and key distribution mechanism that allows for easy key management in large distributed system. Though this concept cannot be directly applied on the file system that is developed in this paper, the tiered model of data access with security mechanisms is adopted. Timo [9] provides a clear performance comparison of cipher algorithms based on different hardware platforms, operating systems and across multiple libraries. The performance comparison of Rijndael AES cipher implementation across different open source libraries is of particular importance. This is due to the fact that it forms the basis for selecting OpenSSL library for the implementation of the file system discussed in this paper. Aditya Rajgarhia, et.al, [10] test the FUSE library with kernel file system modules for performance differences. Their study shows that the overhead due to context switching is more visible when the requested file sizes are very small and hence FUSE library can be used on personal computers without noticeable performance degradation. This conclusion forms the basis of selecting FUSE library for this study.
Alternately, operating systems such as Windows have implemented security features in their file systems that allow multiple users to have secure information on the same file system. This form of security can be categorized as file system encryptors. The advantage of such a solution is that it is transparent to the end user. However, these file systems limit the access to the secured information due to dependency on the operating system. Thus, even when there are multiple solutions to solve the issue of data security, each solution adds new limitations while solving the problem of data security. Hence, there is growing need to develop a better solution that is personal computer specific, operating system independent and supports multiple users. A possible approach is the transfer of user management and file access control from the operating system to the file system and its driver. This allows a file system developer to combine advantages of file system encryptors and file encryptors. Such a solution can be provided using file system in user space library. Filesystem in USErspace (FUSE) is a loadable kernel module for UNIX and Unix clone operating systems that provides programmers an Application Programming Interface (API) to create their own file systems without editing the kernel code. Using such a library allows the users to mount, manage and un-mount file systems without super user privileges. It can also be used to implement virtual file systems that reside on disk file systems as a file. This library also allows the file system logic to control access to files. A number of researchers have worked on extending security features of file systems, comparing security algorithms and studying user space file systems. Erez Zadok, et.al, [1] discuss the design and implementation of WrapFS, a stackable file system. If a file system is stacked on another file system, new features can be added to existing file systems. This allows the stackable file system to be used on multiple file systems. The SnoopFS file system provided as an example by the authors of this paper allows the virtual file system to provide security enhancements to existing file system. This method of extending the features of existing file systems is adopted in this Paper. Ted H. K., et.al, [2] describe another approach to extending file system features by applying object orientation to file systems. Their paper describes the Frigate file system. By combining file access routines as part of the document class, they allow object oriented principles like inheritance to be used. The authors demonstrate this by allowing compression and encryption to be applied to derived classes of the document class. This approach is quite different and provides easier, transparent extensibility. However, due to overhead involved in associating classes with data on disk, this approach has not been widely adopted. Erez Zadok, et.al, [3] discuss the CryptFS file system, an implementation of a stackable file system that provides security enhancements for existing file systems. They provide an insight in to how a wrapper file system can be developed to extend security provisions in file systems. These details are helpful while developing the file system in this paper. Charles P. Wright, et.al, [4] evaluate the performance of encrypted file systems with the use of different cipher algorithms and key sizes.
TECH Journal
SAS
This paper provides a better solution to the problem of file access and security in personal computers by developing an operating system independent user management, authentication and authorization logic and integrating it with an existing pseudo file system that has been implemented using FUSE library.
2. PROBLEM DEFINITION The file system described in this paper has to integrate with FUSE library by providing the implementation of FUSE interface structure functions. This file system also has to support user authentication, authorization and encryption to provide security to the user data stored within the file system. Other requirements such as limited performance degradation and ease of integration with file systems and operating systems should also be achieved.
3. SYSTEM REQUIREMENTS Based on the stated problem definition, the requirements of the file system can be formally stated as: FNR1: Every user must be authenticated by the file system. [Dependency: FNR3]
9
Volume 10, Issue 1, May 2011
R4: Use of encryption and hashing may degrade performance of the file system. [Risk on: FNR4] [Dependency: R7]
FNR2: Every user must be authorized by the file system for access of files. [Dependency: FNR3] FNR3: The file system logic must integrate with the FUSE file system module and provide implementation of getattr, access, readdir, mkdir, mknod, unlink, rmdir, truncate, utimens, open, read, write, statfs, release and flush functions of FUSE operations structure. [Dependency: None]
To resolve this risk, the cryptographic library that is selected for implementation must be selected on the basis of performance. R5: Access to decrypted information stored in the memory or temporary area on hard disk must be restricted. [Risk on: FNR4] [Dependency: None]
FNR4: The file system must provide support for cryptographic technique to ensure privacy. [Dependency: None]
NFR1: The file system interface must be easy to use. [Dependency: FNR3]
While encrypting and decrypting data, unencrypted data may be available in the memory or at a temporary location on the hard disk. Memory access cannot be restricted by a file system. It is the responsibility of the operating system and hence out of scope of this study. Hard disk temporary area may be protected by use of operating system access control.
NFR2: The access latency must not be perceptible by the user. [Dependency: FNR4]
R6: Encryption key must be shared among multiple users. [Risk on: FNR5] [Dependency: R2]
For the stated requirements the following risks were identified:
To allow scalability to groups, it is needed that the private key used to share information must be shared between multiple users at a later stage. To resolve this, multiple keys each per user and per file are needed.
FNR5: The file system must provide scalability to add group permissions. [Dependency: FNR1, FNR2]
R1: Integration with operating system authentication and authorization [Risk on: FNR1, FNR2] [Dependency: None]
R7: Provision of security must not lose priority [Risk on: FNR4, NFR2] [Dependency: R4]
As the file system itself has to provide authentication and authorization control, there may be a conflict with operating system authorization and authentication interfaces. To resolve this risk, FUSE interface can be used to mimic operating system authentication and authorization after the user is authenticated and authorized by the file system. Alternatively, a separate utility program may be provided to enforce user authentication within the file system. FUSE interface can be used to mimic operating system authentication after the user is authenticated.
In trying to improve performance of the file system, the security provided by the file system must not be compromised. This risk must be kept in mind during optimization. R7: Use of a single encryption key can lead to a cryptanalysis attack. [Risk on: FNR4] [Dependency: R4, R5, R6] If all files are encrypted with a single key, the data may be sufficient for a cryptanalysis attack. Hence, each file must be encrypted with a separate key.
R2: Change of ownership cannot be integrated within the FUSE interface [Risk on: FNR1, FNR2] [Dependency: R2]
4. METHODOLOGY To achieve the stated requirements, the following methodology was used:
As the file system and the operating system maintain separate groups of users, there will be a conflict when a request to change ownership is raised. This can be resolved by use of a separate utility to change ownership of the file.
4.1 Identification of Existing Technologies From the literature survey conducted, feasible file systems were selected as the basis for the secure file system being developed. For the selected file systems, data structures were identified to store data and metainformation. From the literature survey, cryptography algorithms and libraries were identified to provide security features for the selected file systems.
Also, to change ownership of a file it is needed that the decryption key must be encrypted with the new user’s key. The only way to achieve this is with the help of public key encryption. Hence, every user must have three keys: His password and his private key, public key pair.
4.2 Design of Data structures and Cryptographic Techniques
R3: Use of existing file system may hinder integration. [Risk on: FNR3] [Dependency: None]
From the identified data structures and cryptographic techniques, multiple designs were developed for the secure file system. After multiple approaches were identified, alternatives and constraints of the study were determined and documented and a single design was selected.
As per the objectives stated for the study, it is necessary to add the security features to an existing file system implementation. The inherent risk that accompanies such a selection is that the file system implementation may conflict with security features bring added. To resolve this risk, alternate file system implementations must also be selected for the addition of security features as a failsafe measure.
TECH Journal
SAS
4.3 Development and Testing of Initial Prototype A first level scaled-down prototype of the new file system was constructed from the preliminary design. This implementation was tested for any weaknesses by
10
Volume 10, Issue 1, May 2011
developing and using a test plan. Additional unimplemented requirements were identified from the original requirements set and weaknesses identified. 4.4 Development and Testing of Second Prototype A new draft design was created by evolving the initial design to fit the unimplemented requirements. A second level prototype of the new file system was constructed from this design. The developed second level prototype was tested extensively to obtain an operational prototype.
Each user has his own password which is a key used in encryption [FNR1, FNR2]
Each user also has a public key, private key pair. [R2 resolution]
Keeping these points in mind, the conceptual design can be written as a set of high level algorithms. There are two data structures needed for this design. A userDetails structure is assumed to be capable of holding username, public key and encrypted hash of password and encrypted private key. A fileDetails structure is assumed to hold encrypted per file key and other file meta-information.
4.5 Design, Development and Testing of File System A complete design was developed based on the prototype design. The complete design was implemented and tested based on the test plan developed to check the operational prototype.
Algorithm mount (String userName, password, String source, String destination)
String
1.
start
4.6 Documentation and User Manual development
2.
store userName and password
User documentation for installation and use of the new file system library was created.
3.
decrypt userDetails in file system meta-information using password
5. SOLUTION PROCEDURE
4.
if ((userDetails.authenticationHash) is not equal to (hash(password)))
As per the methodology discussed in the previous section, the file system was developed based on the knowledge derived from the literature review of the earlier file systems and cryptographic techniques. OpenSSL library was selected for providing security while BBFS was the file system selected as the reference implementation. A customized spiral process model as shown in Figure 1 was used to design and develop the secure file system.
a.
Return authentication failure
5.
userPrivateKey = userDetails.privateKey
6.
mount source at destination
7.
stop
Algorithm mount provides design details of how the file system is to be mounted and what details are stored during the mounting of the file system. The user provides userName, password, source location and destination location. The password is used to decrypt the encrypted contents of the userDetails structure. The hash of password is then compared with the authentication hash to authenticate the user. If the user is a valid user, the password and username are stored and the source location is mounted at the destination location. The user privateKey is also retained. Algorithm read (String userName, password, String source, String destination)
Figure 1 The Customized Spiral Process Model There were four iterations in the design and development cycle that resulted in development of the conceptual model, the verified mathematical model, a limited feature software prototype and the complete file system respectively.
From the requirements analysis done in the section 3, it is clear that: There are multiple users [FNR1, FNR2]
Each user may have many files [IMPLICIT]
Each file is encrypted with a separate key [R7 resolution]
TECH Journal
SAS
1.
start
2.
decrypt fileDetails in file meta-information of source using userPrivateKey
3.
perfileKey = fileDetails.perfileKey
4.
decrypt fileContent from source using perfileKey
5.
return fileContent to destination
6.
stop
Algorithm read illustrates how the user reads the file content. The fileDetails structure contains the perfileKey that is used to encrypt the file. This key is used to decrypt the file contents to the destination.
5.1 Conceptual Design of the Secure File System
String
Algorithm write (String userName, password, String source, String destination)
11
1.
start
2.
generate a random randomKey
3.
perfileKey = randomKey
String
Volume 10, Issue 1, May 2011
4.
fileDetails.perfileKey = perfileKey
5.
encrypt fileDetails in file meta-information of destination using userPrivateKey
6.
encrypt source to fileContent using perfileKey
7.
return encrypted content to destination
8.
stop
the file system needs to know the owner of the file. getData and getEncData are helper functions to facilitate comparison in assertions and return the Data and EncData objects that are related to the File object. writeData is a predicate as it modifies existing mapping of data within a file object. It asserts that the user is owner of a file before it modifies the data. The user authentication in readData function is supported with the third fact defined in Figure 5.
Algorithm write shows how the user data is written to the file system. A random perfileKey is generated. This key is used to encrypt the contents of the file. The fileDetails structure that contains the perfileKey is encrypted and stored as meta-information within the destination file. 5.2 Mathematical Modeling and Verification of Conceptual Design
Figure 3 Implementation of Authentication in Alloy Analyser
Alloy analyser is a tool to mathematically verify a design. To accomplish this, a mathematical model of the design is created. Alloy analyser models are defined as a set of data structure signatures, functions, and predicates. The defined model is then tested with assertions. Figure 2 illustrates the signatures defined to model the conceptual design discussed in the previous chapter. ANSString is a primitive string data structure. Data represents unencrypted data content of a file. EncData represents encrypted data content of a file. LoginDetails is a structure that contains the userName, password, passowordHash and a function that maps the passwords to the respective hashes. The User signature contains user meta-information stored on the disk. These details include the username, the passwordHash and the privateKey. The File signature contains the details of user to which the file belongs and mappings to EncData and Data objects that belong to the file. The cipher mapping relates the Data and corresponding EncData objects that belong to the file.
Figure 5 shows all the facts that are defined in the model’s universe. The first two facts ensure that EncData and Data objects are always part of some file. The third fact ensures that only the owner can read the contents of a file. The fourth fact ensures that there is only one valid LoginDetails object per user.
Figure 4 Defining Read and Write Operations Figure 6 shows the assertions used to verify the model. The first assertion states that if a user is not the owner of a File, there is no Data returned by the read function. The second assertion states that if a user is not the owner of a File, even if he tries to write Data to a File object, the File object will remain unmodified.
Figure 2 Signature Definitions in Alloy Analyser Figure 3 illustrates predicate that defines authentication and a fact that ensures that not all users are authentic. A user is defined as authentic if the hash of password in login details and the hash of password in the user details match. This match is only possible after comparing the two usernames.
Figure 5 Facts Defined for Model
Figure 4 shows the modelling of read and write operations in the alloy analyser. To read or write a file,
Figure 7 shows the Alloy analyser output when the assertion check is requested. The show predicate
TECH Journal
SAS
12
Volume 10, Issue 1, May 2011
generates models that satisfy the defined model. Figure 8 shows Alloy analyser’s solution model that satisfies the defined universe.
prototype asserted that the conceptual design can be implemented as software. 5.4 High Level Design of Secure File System The primitive prototype discussed in the previous section asserted that the conceptual model can be practically developed. It also provided insight in to what libraries are to be used and how the software can be designed, developed and tested. This section discusses the high level design of the secure file system. File Data, Status Information
FUSE library
write/rename User
Errors
Errors
getattr/access/readdir/mkdir/ mknod/unlink/rmdir/truncate /utimens/open/read/statfs/rel ease/ flush
Figure 6 Assertions to Verify the Model
File Data, Meta Information
0.User Based Secure File System
File Storage Area
open/read
write User name, Password, Source, Mount point
Figure 9 Context Diagram of Secure File System The high level design of this study was done using data flow diagrams with control flow. Dataflow diagrams with control flow show the software as a set of modules that transform data. Any signal such as error conditions and control signals are shown as control messages as these messages do not carry the data on which the transformations are performed.
Figure 7 Results of Assertion Checks From the output of Alloy analyser’s assertion check shown in Figure 7, it can be concluded that both assertions are valid and that the model is correct. From the output of Alloy analyser’s satisfaction check shown in Figure 8, it can be concluded that the conceptual design has a solution and can be implemented.
Figure 9 illustrates the environment in which the file system being developed will operate. The FUSE library provides a function pointer structure that acts as an interface between the file system logic and itself. The functions that are to be implemented by the file system logic must handle get attribute, check access, read directory, make directory, make node, unlink, truncate, update time, open, read, get file system statistics, release, flush, write and rename calls. Of these messages, only write and rename messages carry data that will be transformed. Hence, all other messages are control messages. The user provides username, password, the directory to be mounted and the location of the mount point. The file system logic must validate the user and request the FUSE library to mount the source directory at the destination directory. The file storage area is on the source folder that is mounted. This area contains the file system meta-information, file meta information and the encrypted files. Hence the file system logic must access file information, read files and write files to the data store. All error messages are propagated to the user through the FUSE interface.
Figure 8 A Valid Model Example 5.3 Software Prototyping of the Conceptual Design Prototype Development Requirements: The primitive software prototype must demonstrate:
This design was then subjected to multiple refinements resulting in nine different modules. The purpose of these modules was:
User authentication User authorization File read File Write User meta information management and Change of ownership of the file Discussion of Results
A software prototype satisfying these requirements was developed in C programming language on Linux operating system with OpenSSL library and tested. This
TECH Journal
SAS
13
Interfacing with FUSE library Implementing file system authenticate/read/write logic Implementing hashing Implementing base64 encoding Implementing private key encryption Implementing public key encryption Implementing error reporting Volume 10, Issue 1, May 2011
be noted the read speed degradation is noticeable when file sizes exceed 256 megabytes. This may reduce the usability of the secure file system. As a result, this file system is not recommended for use with file sizes larger than 256 megabytes.
Implementing key generation and initialization vector generation Implementing actual interface with the underlying file system
5.5 Low Level Design of Secure File System The low level design of Secure File System was done using algorithms for methods identified in each of the modules as designed in the previous section. 5.6 Operation of Secure File System The algorithmic design was implemented in C resulting in two applications: A utility tool, SFSUtil, was developed to initialize the secure file system. It also provides user management functionality and file ownership transfer functionality demonstrated by the operational prototype.
Figure 12 Read Performance Comparison Plot
The file system executable SFS is used to mount the file system and fusermount command is used to unmount the file system.
Figure 13 Write Performance Comparison Plot Figure 10 Read Performance Degradation Plot
6.2 Outcomes of Performance Analysis
5.7 Testing of Developed Secure File System
Figure 12 shows the comparison of read speeds with changes in file sizes for buffer sizes of 256 bytes, 512 bytes and 1024 bytes. It can be noted that the 512 byte buffer size performs better than 256 byte buffer size up to 256 megabyte file size. Figure 13 shows the write speed changes observed during the same test. Again, the 512 byte buffer size showed the best performance. This may be due to implementation of openSSL library buffers. Hence, a buffer size of 512 bytes has been selected for the file system implementation.
The developed secure file system was tested for errors with test cases that were designed in parallel with the software design. These unit tests, integration tests and system tests ensured correctness of the developed software. Stress tests and Performance tests were conducted to ensure the stability and usability of the developed secure file system.
In all graphs it can be noted that there is high initial latency. This is due to number of context switches as user space file system is used. A sudden rise in latency as the file size crosses 256 megabytes can also be observed in all graphs. This is because the operating system cannot use the primary memory for temporary storage during operations on large file sizes.
7. SUMMARY In this paper, a user based secure file system was designed and developed. This file system provides operating system independent user authorization and access control while integrating seamlessly in to the operating system security restrictions.
Figure 11 Write Performance Degradation Plot 6. RESULTS AND DISCUSSIONS 6.1 Implications of Performance Testing
This system was conceptually designed using algorithmic design. This design was then validated as a mathematical model using alloy analyser. A prototype was developed to assert practicality of implementation. The file system was then designed using data flow
The performance testing described in section 5.7 determined the usable limits of the secure file system. Figure 10 and Figure 11 show the degradation in read and write speeds due to encryption of files. It can
TECH Journal
SAS
14
Volume 10, Issue 1, May 2011
diagrams and algorithms. This secure file system was then developed based on an existing file system called Big Brother File System and uses cryptographic library openSSL and the FUSE file system module. The secure file system was then tested and refined by selection of the best encryption buffer size. The file system usability limitations were determined and recommendations for maximum file size generated.
8. REFERENCES [1] Erez Zadok, Ion Badulescu, and Alex Shender, Extending File Systems Using Stackable Templates, Proceedings of the USENIX Annual Technical Conference, California, The United States of America, pp. 57-70, June 6-11, 1999 [2] Erez Zadok, Ion Badulescu, and Alex Shender, Cryptfs: A Stackable Vnode Level Encryption File System, Technical Report CUCS-021-98, University of California, Los Angeles, 1998 [3] Ted H. Kim and Gerald J. Popeky, Frigate: An Object-Oriented File System for Ordinary Users, Proceedings of the Third USENIX Conference on Object-Oriented Technologies and Systems, Portland, Oregon, pp. 1-15, June 16 - 20, 1997 [4] Charles P. Wright, Jay Dave, and Erez Zadok, Cryptographic File Systems Performance: What You Don’t Know Can Hurt You, Proceedings of second IEEE Internatinal Security In Storage Workshop, Washington D.C., The United States of America, pp. 47-61, 31, October, 2003 [5] Vishal Kher and Yongdae Kim, Securing Distributed Storage: Challenges, Techniques, and Systems, Proceedings of the 2005 ACM workshop on Storage security and survivability, Fairfax, The United States of America, pp. 9-25, November 11th, 2005 [6] Hughes James P. and Chirstopher F. J., Architecture of the Secure File System, Proceedings of the Eighteenth IEEE Symposium on Storage Systems, San Diego, The United States of America, pp. 277-290, April 16-20, 2001 [7] David Mazi`eres, Michael Kaminsky, M. Frans Kaashoek, and Emmett Witchel, Separating key management from file system security, ACM SIGOPS Operating System Review, Volume 33, Issue 5, pp. 124-139, December 1999 [8] Matt Blaze, Key Management in an Encrypting File System, Proceedings of Summer’94 USENIX Tech. Conference, Boston, The United States of America, pp. 27-35, June 6-10, 1994 [9] Timo, Speedtest and Comparsion of Open-Source Cryptography Libraries and Compiler Flags, https://idlebox.net/2008/0714-cryptographyspeedtest-comparison/, Last Accessed on 18/12/2010 [10] Aditya Rajgarhia and Ashish Gehani, Performance and extension of user space file systems, Proceedings of the 2010 ACM Symposium on Applied Computing, Sierre, Switzerland, pp. 206213, March 22 - 26, 2010
TECH Journal
SAS
15
Volume 10, Issue 1, May 2011
