Network storage sharing encryption method and system

Abstract

The invention provides a network storage sharing encryption method and system. The method comprises the steps of user file uploading, user file sharing, user file downloading and user file deleting. According to the method, the server side can identify whether the files uploaded by different users are the same file or not while the files are encrypted, stored and transmitted, and when the files uploaded by the users are the same, the storage space consumption can be greatly reduced, and the uploading speed of the users can be improved. And secondly, when the files are encrypted, stored and transmitted, a server side can identify whether the files uploaded by different users are the same file or not, and when the files uploaded by the users are the same, the storage space consumption can be greatly reduced, and the uploading speed of the users can be improved. And finally, the method can be applied to various types of network storage, the application range is wider, the file, the file decryption information and the file ownership information are respectively arranged in different nodes for storage, and the safety of the file is further improved.

Description

Technical Field

[0001] The present application relates to the technical field of network storage sharing, and in particular to a network storage sharing encryption method and system. Background Art

[0002] Network storage sharing is a network-based data storage method that allows users to access and share storage resources through the network without the intervention of application servers. This storage method usually occupies a node in a local area network and centrally manages and processes all data on the network, thereby effectively reducing the total cost of ownership and protecting user investment. Network storage sharing can be implemented in direct-attached storage (DAS), network-attached storage (NAS) and storage area network (SAN).

[0003] Direct-attached storage (DAS) is a storage device that is directly connected to the host system, such as a hard drive inside a server, which is directly connected to the server via a cable (usually an SCI interface cable). I / O requests are sent directly to the storage device, which relies on the server and is a stack of hardware without any storage operating system. DAS is suitable for scenarios where servers are geographically dispersed and need to be directly connected to application servers or database applications.

[0004] Network Attached Storage (NAS) is a special dedicated data storage server that includes storage devices (such as disk arrays, CD / DVD drives, tape drives or removable storage media) and embedded system software, providing cross-platform file sharing capabilities. NAS is added to a group of computers through a standard network topology (such as Ethernet), allowing users to access data on the network.

[0005] A storage area network (SAN) is a high-performance network dedicated to storage that uses Fibre Channel technology to achieve large-capacity data transmission between servers and storage devices. SAN provides a network that separates storage devices from servers, allowing storage resources to be managed and used more flexibly.

[0006] The advantage of network storage sharing is that it can greatly improve performance, deeply optimize the database kernel, and use technologies such as physical replication, RDMA high-speed network, and distributed shared storage to meet the performance requirements of high-concurrency scenarios. In addition, based on the one-write-many-read cluster mode of shared storage, data only needs to be saved in the shared storage, which greatly reduces the storage space and management costs. However, when using network storage sharing, you also need to pay attention to data security and backup, and ensure that necessary backups have been made before deleting or modifying data in the shared storage to prevent data loss or affect the normal operation of the business.

[0007] The prior art includes various studies on network storage sharing technology to solve various technical problems faced by network storage sharing.

[0008] (1) Invention name: File security sharing method and system, invention number: CN103516516B

[0009] This patent text mainly discusses how to achieve secure sharing of data information while ensuring the security of user data information in information services such as cloud storage. At present, the industry has proposed a method for implementing secure sharing based on shared folders or based on the server side, but the setting of secure sharing and encryption and decryption processing need to be completed on the server side, requiring the participation of system administrators or service providers, which poses certain security risks. Therefore, how to solve these security issues and achieve secure sharing of data information has become a major technical problem currently facing information services such as cloud storage. The technical effect of the present invention is that by using the recipient's public key to encrypt the symmetric encryption key of the shared file, peer-to-peer secure sharing of the file level is achieved. Compared with traditional file sharing methods, the present invention does not require the server side and the service provider to obtain the decryption authority of the file, thereby improving security.

[0010] However, it focuses on peer-to-peer encrypted sharing, and the server side only acts as a temporary transfer station for files. It does not take into account that the same file will generate different ciphertexts after different encryptions, which will lead to a large amount of storage space on the server side.

[0011] (2) Invention title: Method, device and system for realizing secure sharing of encrypted files, invention number CN104917723B

[0012] It mainly solves the problem of user data security in services such as cloud storage. The current file sharing solutions on the market have the problems of low security strength and insufficient user autonomy, especially in multi-tenant application scenarios, there are great security risks. Therefore, it is necessary to implement a file sharing technology that is both safe and effective to meet users' higher requirements for services such as cloud storage. The present invention provides a method for sharing and decrypting encrypted files in a cloud storage server. By decrypting the shared key, a decrypted encryption key is obtained, and the encrypted file is decrypted using the decrypted key, thereby achieving effective control and association of the encrypted file. At the same time, by adding a shared user key pair parameter list to the metadata attributes, effective control and association of the user over the ciphertext sharing is achieved, reducing the trust issues caused by the sharing of user data on the cloud or server side.

[0013] However, it focuses on the encryption and decryption methods of files, without considering that the same file will generate different ciphertexts after different encryptions, which will lead to a large amount of storage space on the server side being occupied.

[0014] (3) Invention Title: A blockchain ciphertext cloud storage sharing method based on attribute proxy re-encryption, Invention No. CN109189727B

[0015] A ciphertext information storage sharing model based on blockchain technology is proposed. Through the attribute proxy re-encryption technology, information sharing has more flexible sharing control characteristics. At the same time, it supports keyword retrieval, improves the efficiency of information sharing, saves communication costs, and reduces the pressure of high-frequency access to cloud storage. This model realizes uninterrupted sharing of information. Even when the owner of the information is offline, the node can still complete the information interaction work according to the rules of the smart contract. It has more advantages in anti-collusion attacks, execution efficiency and algorithm complexity, and is more suitable for the development requirements of the current Internet of Things field. However, the above patent is based on blockchain technology, and its deployment and maintenance are relatively complex. Summary of the invention

[0016] The present application provides a network storage sharing encryption method and system to solve the problem that the existing network storage sharing technology does not take into account that the same file will generate different ciphertexts after different encryptions, which will lead to a large amount of storage space on the server side being occupied, and the deployment and maintenance are relatively complex.

[0017] The first aspect of the present application proposes a network storage sharing encryption method, including user file uploading, user file sharing and user file downloading, wherein:

[0018] (1) User file upload, enabling the server to store the file library, user ownership information library, and ciphertext fragments in different nodes, including:

[0019] The client software initiates a file upload request;

[0020] The client software splits the target file and generates a linked list;

[0021] The client software first uploads the original file link list data of the generated target file to the server software;

[0022] The server software compares the linked list data to the file library to determine whether the file already exists in the file library;

[0023] If the target file exists, a successful upload notification is returned to the client and a decryption list of the target file is issued. The client saves the file information and decryption list of the target file. If the target file does not exist, the file upload process continues.

[0024] (2) User file sharing, specifically:

[0025] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0026] The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back.

[0027] The client sends the obtained sharing code to the target client;

[0028] After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back.

[0029] (3) User file downloads, including:

[0030] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0031] The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error.

[0032] The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server still needs to verify the user's file ownership for the file download request. The download can continue only after the verification is successful. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address;

[0033] After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

[0034] Furthermore, the file upload process includes:

[0035] The client splits the target file and encrypts the split files, then updates the public key generated by encryption to the linked list of the target file to generate a decryption linked list;

[0036] The client uploads the decryption list and each split and encrypted file to the server;

[0037] The server processes and stores the uploaded files and decryption lists;

[0038] The server updates the file library based on the stored file information.

[0039] Furthermore, the client software splits the target file and generates a linked list, including:

[0040] Take the first digit a of the value corresponding to the file size and split the file into a+1 file segments;

[0041] The target file before segmentation is operated by using two different digest algorithms through file digest 1 and file digest 2;

[0042] Using file fragment digest 1 and file fragment digest 2 to operate on the same file fragment using two different digest algorithms;

[0043] The client software saves the above calculation results in the above table format as an original file linked list of the target file, and the original file linked list does not contain the values ​​corresponding to the private key or public key fields.

[0044] Furthermore, the server software compares the linked list data to the file library to determine whether the file already exists in the file library. The determination method is:

[0045] Extract the values ​​of the three fields, file summary 1, file summary 2, and file size, and query the file library to see if there is data with the same content in the corresponding fields. The three fields must be equal at the same time. If not, it returns that no identical files are found.

[0046] If the corresponding data is found, the values ​​of file fragment sequence number, file fragment summary 1, and file fragment summary 2 in each data record are extracted for comparison. Similarly, the three fields must be equal at the same time. If so, it is returned that the same file exists.

[0047] Furthermore, if the file already exists, a notification of successful upload is returned to the client software, and a decrypted file list of the target file stored on the server is sent; after the client software successfully receives the decrypted file list, the decrypted file list of the target file is saved;

[0048] If the file does not exist in the file library, the client software is notified to perform split upload operations on the target file.

[0049] Furthermore, the client software performs split uploading operations on the target file, specifically:

[0050] After receiving the above notification, the client software first splits the target file by taking the first digit a of the value corresponding to the file size and splitting the file into a+1 file segments;

[0051] The client software encrypts the files obtained after the above splitting respectively, generates its own independent key pair for each split file fragment, and then uses the private key to encrypt the file fragment to generate a ciphertext fragment file. After the encryption is completed, the corresponding private key is added to the original file chain list to generate an encrypted file chain list; the corresponding public key is added to the original file chain list to generate a decrypted file chain list;

[0052] The client software uploads the above generated ciphertext fragment files and decrypted file list to the server;

[0053] After the server successfully receives the data, it generates three copies of each ciphertext fragment file and saves them to different storage nodes;

[0054] The server saves the corresponding storage location information of the above-mentioned file copies, uploading user information, and decrypted file link list information in the file library.

[0055] Furthermore, it also includes user file deletion, specifically:

[0056] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0057] The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message.

[0058] After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

[0059] The second aspect of the present application proposes a system for implementing the above-mentioned network storage sharing encryption method, including a client and a server, wherein the client and the server implement file upload, sharing and download functions, specifically:

[0060] (1) File upload between client and server:

[0061] The client is used to initiate a file upload request and upload the generated original file linked list data of the target file to the server;

[0062] The client splits the target file and generates a linked list, and compares the linked list data to the file library to determine whether the file already exists in the file library;

[0063] If the file already exists, the client software will notify you of successful upload and send the decrypted file list of the target file saved on the server at the same time; after the client successfully receives the file, it will save the decrypted file list of the target file;

[0064] If the file does not exist in the file library, the client will split and upload the target file;

[0065] (2) File sharing between client and server:

[0066] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0067] The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back.

[0068] The client sends the obtained sharing code to the target client;

[0069] After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back.

[0070] (3) File download between client and server:

[0071] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0072] The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error.

[0073] The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server still needs to verify the user's file ownership for the file download request. The download can continue only after the verification is successful. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address;

[0074] After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

[0075] Furthermore, the client and the server implement a file deletion function, including:

[0076] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0077] The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message.

[0078] After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

[0079] Furthermore, the client and the server at least include a processor, a memory, a data communication module, and a power module, and the processor is electrically connected to the memory, the data communication module, and the power module.

[0080] At least one of the above technical solutions adopted in this application can achieve the following beneficial effects:

[0081] (1) The present invention focuses on allowing files to be encrypted, stored and transmitted while enabling the server side to identify whether files uploaded by different users are the same file. When the files uploaded by users are the same, the storage space usage can be greatly reduced and the user upload speed can be improved.

[0082] (2) The present invention focuses on allowing files to be encrypted, stored and transmitted while enabling the server side to identify whether files uploaded by different users are the same file. When the files uploaded by users are the same, the storage space usage can be greatly reduced and the user upload speed can be improved.

[0083] (3) The present invention can be applied to various types of network storage and has a wider range of applications. Storage is only a part of the system. The file, file decryption information, and file ownership information are stored in different nodes, which further improves the security of the file. BRIEF DESCRIPTION OF THE DRAWINGS

[0084] The drawings described herein are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation on the present application. In the drawings:

[0085] Figure 1 The present invention provides a flow chart of a network storage sharing encryption method.

[0086] Figure 2 This is a file upload flow chart of a network storage sharing encryption method for this application.

[0087] Figure 3 This is intended as a chain of files for this application. DETAILED DESCRIPTION

[0088] In order to make the purpose, technical solution and advantages of the present application clearer, the technical solution of the present application will be clearly and completely described below in combination with the specific embodiments of the present application and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present application.

[0089] The technical solutions provided by various embodiments of the present application are described in detail below in conjunction with the accompanying drawings.

[0090] Example 1

[0091] like Figure 1 As shown, this application proposes a network storage sharing encryption method, including user file uploading, user file sharing, user file downloading and user file deletion, as follows:

[0092] 1. User file upload scenario

[0093] The present invention mainly consists of two mandatory components: the server software and the client software of network storage. The client software includes conventional authority authentication functions such as user registration, login, and logout, and the server software provides corresponding user registration, login, and logout service functions. Figure 2 As shown, users need to register and log in successfully before they can use the file upload function. The steps are as follows:

[0094] 1. The user first initiates a file upload request through the client software.

[0095] 2. The client software splits the target file and generates a linked list. The specific steps are as follows:

[0096] 2.1. File splitting algorithm: Take the first digit a of the value corresponding to the file size and split the file into a+1 file segments. For example, if the size of a target file is 628718 bytes, the first digit a=6, and the file is split into 7 file segments. The first file segment is 0 to (100000-1) bytes, the second file segment is 100000 to (200000-1) bytes, and so on. The seventh file segment is 600000 to 628718 bytes.

[0097] 2.2, according to Figure 3 File digest 1 and file digest 2 use two different digest algorithms to operate on the target file before segmentation.

[0098] 2.3. File fragment summary 1 and file fragment summary 2 use two different summary algorithms to operate on the same file fragment.

[0099] 2.4. The client software saves the above calculation results in the above table format as the original file list of the target file. The original file list does not contain the value corresponding to the private key or public key field.

[0100] 3. After completing the above operations, the client software first uploads the original file link list data of the generated target file to the server software.

[0101] 4. The server software compares the above linked list data to the file library to determine whether the file already exists in the file library. The determination method is as follows:

[0102] A. Extract the values ​​of the three fields, namely, file summary 1, file summary 2 and file size, and query the file library to see if there is data with the same content in the corresponding fields (the three fields must be equal at the same time). If not, it returns that no identical file is found.

[0103] B. If the corresponding data is found, the values ​​of file fragment sequence number, file fragment summary 1, and file fragment summary 2 in each data record are extracted for comparison. The three fields must also be equal at the same time. If so, it is returned that the same file exists. (In particular, the values ​​of the three fields of file name, private key, and public key do not need to be considered when comparing)

[0104] 4.1. If the file already exists, a successful upload notification is returned to the client software, and the decrypted file list of the target file saved on the server is sent. After the client software successfully receives the decrypted file list, it saves the target file.

[0105] 4.2. If the file does not exist in the file library, the client software is notified to split and upload the target file. Step 4.2 is as follows:

[0106] 4.2.1. After receiving the above notification, the client software first splits the target file according to the above step 2.1.

[0107] 4.2.2. The client software encrypts the files obtained after the above splitting respectively. Here, it is recommended to use the national encryption algorithm sm2 as the encryption algorithm. The client software generates an independent key pair for each split file fragment, and then uses the private key to encrypt the file fragment to generate a ciphertext fragment file (the file naming method is "file summary 1. file summary 2. total number of file fragments. file fragment sequence number"). After the encryption is completed, the corresponding private key is added to the original file list to generate an encrypted file list; the corresponding public key is added to the original file list to generate a decrypted file list.

[0108] 4.2.3. The client software uploads the above-generated ciphertext fragment files and decrypted file list to the server.

[0109] 4.2.4. After the server successfully receives the ciphertext fragment file, it generates three copies of the files and saves them to different storage nodes.

[0110] 4.2.5. The server saves the corresponding storage location information, uploading user information, and decrypted file list information of the above-mentioned file copies in the file library. Since the information of each user who has uploaded a file will be recorded accordingly, the server's file library can save the user ownership information library of each file.

[0111] Through the above steps, the server will store the file library, user ownership information library, and ciphertext fragments in different nodes to further improve the security of file storage.

[0112] 2. User file sharing scenarios

[0113] If a user wants to share a file with others, two prerequisites must be met: 1. The shared file has been stored on the server; 2. The user owns the file.

[0114] There are two ways for users to obtain ownership of a file: uploading the file themselves or through sharing authentication by others. The steps for users to share files are as follows:

[0115] 1. The user logs in to the client software, clicks the "My Files" function, and requests a file list from the server. The server queries and returns a list of files owned by the user based on the user's registered account and user ownership information database.

[0116] 2. The user browses and finds the target file to be shared, clicks the "Share" function, and initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated (a certain validity period can be set, after which the sharing is invalid) and fed back to the user; otherwise, a sharing error is fed back.

[0117] 3. The user sends the shared code to the target user.

[0118] After the target user obtains the sharing code, he / she first registers and logs in to the client software, clicks the "Get Shared File" function, fills in the sharing code and clicks "OK" to initiate a request to the server to obtain the file. The server verifies based on the sharing code information.

[0119] 4. Check whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete. If the verification is successful, update the user ownership information library to add the ownership of the corresponding file to the target user, and feedback the target user to obtain a success notification; otherwise, feedback the corresponding error notification.

[0120] 3. User file download scenario

[0121] 1. The user logs in to the client software, clicks the "My Files" function, and requests a file list from the server. The server queries and returns a list of files owned by the user based on the user's registered account and user ownership information database.

[0122] 2. The user browses and finds the target file to be downloaded, clicks the "Download" function, and initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all the corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error.

[0123] 3. The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server still needs to verify the user's file ownership for the file download request. The download can only continue after the verification is successful. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address.

[0124] 4. After all ciphertext fragment files are downloaded and verified successfully, the public key of each ciphertext fragment file is obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

[0125] 4. User file deletion scenarios

[0126] This mainly refers to the scenario where a user deletes files stored on the server. The steps are as follows:

[0127] 1. The user logs in to the client software, clicks the "My Files" function, and requests a file list from the server. The server queries and returns a list of files owned by the user based on the user's registered account and user ownership information database.

[0128] 2. The user browses and finds the target file to be deleted, clicks the "Delete" function, and initiates a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification; otherwise, the server returns an error message.

[0129] 3. After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

[0130] Example 2

[0131] like Figure 1 As shown, the present application proposes a network storage sharing encryption method, including user file uploading, user file sharing and user file downloading, wherein:

[0132] (1) User file upload, enabling the server to store the file library, user ownership information library, and ciphertext fragments in different nodes, including:

[0133] The client software initiates a file upload request;

[0134] The client software splits the target file and generates a linked list;

[0135] The client software first uploads the original file link list data of the generated target file to the server software;

[0136] The server software compares the linked list data to the file library to determine whether the file already exists in the file library;

[0137] If the target file exists, a successful upload notification is returned to the client and a decryption list of the target file is issued. The client saves the file information and decryption list of the target file. If the target file does not exist, the file upload process continues.

[0138] (2) User file sharing, specifically:

[0139] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0140] The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back.

[0141] The client sends the obtained sharing code to the target client;

[0142] After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back.

[0143] (4) User file downloads, including:

[0144] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0145] The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error.

[0146] The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server still needs to verify the user's file ownership for the file download request. The download can continue only after the verification is successful. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address;

[0147] After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

[0148] In this embodiment, the file upload process includes:

[0149] The client splits the target file and encrypts the split files, then updates the public key generated by encryption to the linked list of the target file to generate a decryption linked list;

[0150] The client uploads the decryption list and each split and encrypted file to the server;

[0151] The server processes and stores the uploaded files and decryption lists;

[0152] The server updates the file library based on the stored file information.

[0153] In this embodiment, the client software splits the target file and generates a linked list, including:

[0154] Take the first digit a of the value corresponding to the file size and split the file into a+1 file segments;

[0155] The target file before segmentation is operated by using two different digest algorithms through file digest 1 and file digest 2;

[0156] Using file fragment digest 1 and file fragment digest 2 to operate on the same file fragment using two different digest algorithms;

[0157] The client software saves the above calculation results in the above table format as an original file linked list of the target file, and the original file linked list does not contain the values ​​corresponding to the private key or public key fields.

[0158] In this embodiment, the server software compares the linked list data to the file library to determine whether the file already exists in the file library. The determination method is:

[0159] Extract the values ​​of the three fields, file summary 1, file summary 2, and file size, and query the file library to see if there is data with the same content in the corresponding fields. The three fields must be equal at the same time. If not, it returns that no identical files are found.

[0160] If the corresponding data is found, the values ​​of file fragment sequence number, file fragment summary 1, and file fragment summary 2 in each data record are extracted for comparison. Similarly, the three fields must be equal at the same time. If so, it is returned that the same file exists.

[0161] 5. A network storage sharing encryption method according to claim 4, characterized in that:

[0162] If the file already exists, a notification of successful upload is returned to the client software, and a decrypted file list of the target file saved on the server is sent; after the client software successfully receives the decrypted file list, the decrypted file list of the target file is saved;

[0163] If the file does not exist in the file library, the client software is notified to perform split upload operations on the target file.

[0164] In this embodiment, the client software performs split upload operations on the target file, specifically:

[0165] After receiving the above notification, the client software first splits the target file by taking the first digit a of the value corresponding to the file size and splitting the file into a+1 file segments;

[0166] The client software encrypts the files obtained after the above splitting respectively, generates its own independent key pair for each split file fragment, and then uses the private key to encrypt the file fragment to generate a ciphertext fragment file. After the encryption is completed, the corresponding private key is added to the original file chain list to generate an encrypted file chain list; the corresponding public key is added to the original file chain list to generate a decrypted file chain list;

[0167] The client software uploads the above generated ciphertext fragment files and decrypted file list to the server;

[0168] After the server successfully receives the data, it generates three copies of each ciphertext fragment file and saves them to different storage nodes;

[0169] The server saves the corresponding storage location information of the above-mentioned file copies, uploading user information, and decrypted file link list information in the file library.

[0170] This embodiment also includes user file deletion, specifically:

[0171] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0172] The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message.

[0173] After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

[0174] Example 3

[0175] In addition, the present application also proposes a system for implementing the above-mentioned network storage sharing encryption method, including a client and a server, wherein the client and the server implement file upload, sharing and download functions, specifically:

[0176] (1) File upload between client and server:

[0177] The client is used to initiate a file upload request and upload the original file link list data of the generated target file to the server;

[0178] The client splits the target file and generates a linked list, and compares the linked list data to the file library to determine whether the file already exists in the file library;

[0179] If the file already exists, the client software will notify you of successful upload and send the decrypted file list of the target file saved on the server at the same time; after the client successfully receives the file, it will save the decrypted file list of the target file;

[0180] If the file does not exist in the file library, the client will split and upload the target file;

[0181] (4) File sharing between client and server:

[0182] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0183] The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back.

[0184] The client sends the obtained sharing code to the target client;

[0185] After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back.

[0186] (5) File download between client and server:

[0187] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0188] The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error.

[0189] The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server still needs to verify the user's file ownership for the file download request. The download can continue only after the verification is successful. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address;

[0190] After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

[0191] Among them, the client and server implement the file deletion function, including:

[0192] The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database;

[0193] The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message.

[0194] After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

[0195] The client and server mentioned above at least include a processor, a memory, a data communication module, and a power module, and the processor is electrically connected to the memory, the data communication module, and the power module.

[0196] This application focuses on allowing the server side to identify whether files uploaded by different users are the same file while the files are encrypted for storage and transmission. This can significantly reduce the amount of storage space used and increase the user upload speed when the files uploaded by users are the same. Secondly, while the files are encrypted for storage and transmission, the server side can identify whether files uploaded by different users are the same file. This can significantly reduce the amount of storage space used and increase the user upload speed when the files uploaded by users are the same. Finally, it can be oriented to various types of network storage, with a wider range of applications. It adopts the method of storing files, file decryption information, and file ownership information in different nodes, which further improves the security of files.

[0197] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A network storage sharing encryption method, characterized in that: Includes user file upload, user file sharing and user file download, including: (1) User file upload: The server saves the file library, user ownership information library, and ciphertext fragments to different nodes, including: The client software initiates a file upload request; The client software splits the target file and generates a linked list; The client software uploads the original file link list data of the generated target file to the server software; The server software compares the linked list data to the file library to determine whether the file already exists in the file library; If the target file exists, a successful upload notification is returned to the client and a decryption list of the target file is issued. The client saves the file information and decryption list of the target file. If the target file does not exist, the file upload process continues. (2) User file sharing, specifically: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back. The client sends the obtained sharing code to the target client; After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back. (3) User file downloads, including: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error. The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server verifies the user's file ownership when making a file download request. After the verification is successful, the download continues. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address. After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

2. A network storage sharing encryption method according to claim 1, characterized in that: The file upload process includes: The client splits the target file and encrypts the split files, then updates the public key generated by encryption to the linked list of the target file to generate a decryption linked list; The client uploads the decryption list and each split and encrypted file to the server; The server processes and stores the uploaded files and decryption lists; The server updates the file library based on the stored file information.

3. A network storage sharing encryption method according to claim 1, characterized in that: The client software splits the target file and generates a linked list, including: Take the first digit a of the value corresponding to the file size and split the file into a+1 file segments; The target file before segmentation is operated by using two different digest algorithms through file digest 1 and file digest 2; Using file fragment digest 1 and file fragment digest 2 to operate on the same file fragment using two different digest algorithms; The client software saves the above calculation results in the above table format as an original file linked list of the target file, and the original file linked list does not contain the values ​​corresponding to the private key or public key fields.

4. A network storage sharing encryption method according to claim 1, characterized in that: The server software compares the linked list data to the file library to determine whether the file already exists in the file library. The determination method is: Extract the values ​​of the three fields, file summary 1, file summary 2, and file size, and query the file library to see if there is data with the same content in the corresponding fields. The three fields must be equal at the same time. If not, it returns that no identical files are found. If the corresponding data is found, the values ​​of file fragment sequence number, file fragment summary 1, and file fragment summary 2 in each data record are extracted for comparison. Similarly, the three fields must be equal at the same time. If so, it is returned that the same file exists.

5. A network storage sharing encryption method according to claim 4, characterized in that: If the file already exists, a notification of successful upload is returned to the client software, and a decrypted file list of the target file saved on the server is sent; after the client software successfully receives the decrypted file list, the decrypted file list of the target file is saved; If the file does not exist in the file library, the client software is notified to perform split upload operations on the target file.

6. A network storage sharing encryption method according to claim 5, characterized in that: The client software performs split uploading operations on the target file, specifically: After receiving the above notification, the client software first splits the target file by taking the first digit a of the value corresponding to the file size and splitting the file into a+1 file segments; The client software encrypts the files obtained after the above splitting respectively, generates its own independent key pair for each split file fragment, and then uses the private key to encrypt the file fragment to generate a ciphertext fragment file. After the encryption is completed, the corresponding private key is added to the original file chain list to generate an encrypted file chain list; the corresponding public key is added to the original file chain list to generate a decrypted file chain list; The client software uploads the above generated ciphertext fragment files and decrypted file list to the server; After the server successfully receives the data, it generates three copies of each ciphertext fragment file and saves them to different storage nodes; The server saves the corresponding storage location information of the above-mentioned file copies, uploading user information, and decrypted file link list information in the file library.

7. A network storage sharing encryption method according to claim 1, characterized in that: It also includes user file deletion, specifically: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message. After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

8. A system for implementing the network storage sharing encryption method according to any one of claims 1 to 7, characterized in that: It includes a client and a server, which implement file upload, sharing and download functions, specifically: (1) File upload between client and server: The client is used to initiate a file upload request and upload the generated original file linked list data of the target file to the server; The client splits the target file and generates a linked list, and compares the linked list data to the file library to determine whether the file already exists in the file library; If the file already exists, the client software will notify you of successful upload and send a decrypted file list of the target file saved on the server; After the client successfully receives the target file, it saves the decrypted file list; If the file does not exist in the file library, the client will split and upload the target file; (2) File sharing between client and server: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client initiates a file sharing request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, a sharing code is generated and fed back to the client. Otherwise, a sharing error is fed back. The client sends the obtained sharing code to the target client; After the target client obtains the sharing code, it initiates a request to the server to obtain the file. The server verifies whether the corresponding sharing is within the validity period and whether the corresponding file exists and is complete based on the sharing code information. If the verification is successful, the user ownership information library is updated to add the ownership of the corresponding file to the target user, and a successful acquisition notification is fed back to the target client; otherwise, a corresponding error notification is fed back. (3) File download between client and server: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client initiates a file download request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server generates and feedbacks the temporary download address of all corresponding ciphertext fragment files of the file and the decrypted file list information of the file; otherwise, the server feedbacks a download error. The client requests to download the corresponding ciphertext fragment file according to the obtained temporary download address. The server verifies the user's file ownership when making a file download request. After the verification is successful, the download continues. After each ciphertext fragment file is downloaded and verified successfully, the server is notified to delete the temporary download address. After all the ciphertext fragment files are downloaded and verified successfully, the public keys of each ciphertext fragment file are obtained and decrypted according to the obtained decryption file link list information. After the decryption is successful, they are sequentially spliced ​​according to the decryption file link list information to successfully restore the original file content.

9. A network storage sharing encryption system according to claim 8, characterized in that: The client and server implement the file deletion function, including: The client requests a file list from the server, and the server queries and returns the file list owned by the user based on the user's registered account and user ownership information database; The client sends a file deletion request to the server. The server queries the user ownership information database based on the user registration account and file ID of the request and verifies whether the user owns the file. If the user owns the file, the server updates the user ownership information database to delete the user's ownership of the file and returns a successful deletion notification. Otherwise, the server returns an error message. After the server completes the above operations, it continues to determine whether the target file is still owned by other users. If no user owns the file, the server deletes the encryption / decryption file list information, file library information, and ciphertext fragment files corresponding to the file to achieve complete file deletion; otherwise, no operation is performed.

10. A network storage sharing encryption system according to claim 8 or 9, characterized in that: The client and the server at least include a processor, a memory, a data communication module, and a power module, and the processor is electrically connected to the memory, the data communication module, and the power module.

Images