KR100423191B1 - Improving secure server performance with pre-processed data ready for secure protocol transfer - Google Patents

Abstract

The present invention provides a method, system and computer program product for improving the efficiency of a method of performing symmetric encryption of bulk data to be transmitted using a security protocol such as Secure Socket Layer (SSL) or Transaction Layer Security (TLS). It is about. The provided file inserts an empty space in the file where a hash value is required according to the protocol specification. When the file is requested by the client, the actual hash value is calculated to replace the reserved free space. The technique allows for the transmission of large blocks of data to the encryption engine and exploits the resulting processing efficiency regardless of the smaller size constraints on message segments imposed by security protocol specifications.

Description

FIELD OF THE INVENTION IMPROVING SECURE SERVER PERFORMANCE WITH PRE-PROCESSED DATA READY FOR SECURE PROTOCOL TRANSFER}

The present invention relates to a computer system, in particular, by pre-processing data to be transmitted using a security protocol (secure socket layer or "SSL", or a security protocol such as transaction layer security or "TLS"), A method, system, and computer program product for improving the performance of a networking environment.

Secure Sockets Layer, or "SSL," is a networking protocol developed by Netscape and RSA Data Security. It is intended to secure network communications in a non-secure environment. More specifically, SSL is designed to be used in the Internet environment, and operates as a protocol layer on top of the Transmission Control Protocol / Internet Protocol (TCP / IP) layer. The application code is then placed on SSL in the networking protocol stack. When an application (such as a browser) generates data to be sent to a peer in the network, the data is sent to the SSL layer where various security procedures are performed, and then the data converted by SSL is sent to the TCP layer. do. On the receiving side of the connection, the TCP layer transmits the incoming data to the SSL layer after receiving the incoming data, in which the procedure of restoring the data to its original form and transmitting the restored data to the receiving application is performed. do. The latest version of SSL is described in detail in "The SSL Protocol, Version 3.0", updated November 18, 1996, and is available at http://home.netscape.com/eng/ssl3/draft302.txt (hereafter " Available from the World Wide Web ("Web").

The protocols under the Internet (eg TCP / IP) are not designed to provide secure data transmission. The Internet was originally designed with universities and academic organizations in mind, and it was estimated that users of the network would use the network in a collaborative, non-hostile manner. Although the Internet began to expand into the public network, most users were located within large organizations, so their use outside of these groups was limited. These organizations have computing facilities that protect users' data with a variety of security procedures such as firewalls that do not require the security built into the Internet itself. However, the use of the Internet has surged over the years. Today millions of people use the Internet and the Web on a daily basis. (Hereinafter, the terms "internet" and "web" are used in the same sense unless otherwise noted.) Users perform a variety of tasks, from exchanging e-mail messages to retrieving information about commerce. Users may access the Internet from homes where security procedures are not generally available, from their cellular phones, or from numerous other environments. In order to support the growth of the Internet as a space where a business referred to as "e-commerce" or simply "e-commerce" can survive, easily accessible and inexpensive security procedures must be developed. SSL is one common solution and is commonly used with applications that send and receive data using the hypertext transfer protocol (“HTTP”). HTTP is the most commonly used protocol for accessing parts of the Internet called the web. HTTP is used with SSL to provide secure communication, a combination of which is referred to as "HTTPS". Non-commercial Internet traffic can also benefit from the security provided by SSL. SSL has been proposed for use with non-HTTP data transfer protocols such as Simple Mail Transfer Protocol (SMTP) and Network News Transfer Protocol (NNTP).

SSL is designed to provide some different but complementary security. The first is message privacy. Privacy refers to protecting the content of a message so that it cannot be read by anyone other than the sender and recipient. Privacy is provided using cryptography to encrypt and decrypt messages. SSL also uses symmetric ciphertext, also known as public key cryptography. The message receiver can decrypt the encrypted message if it has the appropriate private key and decryption algorithm associated with the message producer's public key. Secondly, SSL provides data integrity for the messages that are sent. Data integrity refers to the ability of a message receiver to detect whether the contents of a message have changed since the message was created (and thus make the message unreliable). The message producer sends the message through an algorithm that generates what is called a "message digest" or "message authentication code." On the other hand, the algorithm output is sometimes referred to as the "hash" of the message because this type of algorithm is known as a "hashing algorithm". The digest or hash is sent with a message. When a message is received, the receiver also processes the message through an algorithm that produces another digest. If the digest calculated by the receiver does not match the digest sent with the message, one can infer that the message content has changed in some way after the message was created. The third security feature that SSL provides is known as authentication. Since communication over the Internet occurs as a series of electronic signals, the communication side cannot see each other and cannot visually determine what they are communicating with. Authentication is a technique that helps the communication side to indicate who they are, regardless of whether the communication side is a person or an application program. For example, if a user (man) purchases a product over the Internet using a credit card, the application that the user is waiting for at the other end that the user is accessing for his credit card information is actually trading. It's important to know if you're a seller who is willing to sell or a scammer who's waiting to steal his credit card information.

These security features are very powerful and provide a high level of protection for Internet users. However, the operation of the SSL protocol incurs a significant amount of processing overhead. Secure Internet servers, such as secure HTTP servers, must be able to respond appropriately to a very large number of requests for secure message content. The overhead of the SSL protocol makes these servers bottlenecks in handling client requests. SSL protocol overhead is due to three factors: (1) extra network traffic (e.g., in a handshaking protocol in which a number of various security related parameters negotiate a series of message exchanges), and (2) when a secure session is initiated between a client and a server. Use of relatively expensive asymmetric key ciphertext behavior for cryptographic and decryption keys, and (3) symmetric encryption of bulk data transmitted between client and server.

The first factor was addressed by the efficient implementation of the SSL protocol for sockets. The second factor is solved by various vendors of cryptographic hardware adapter cards and accelerators. During encryption of bulk data, the third factor does not incur as much overhead as other factors, but still consumes a significant amount of processing time. Many cryptographic hardware accelerators include circuitry for symmetric cryptography (also known as "symmetric ciphers"), such as known DES, 3DES, RC4 cryptography. However, the nature of the SSL protocol makes it impossible to benefit from these accelerators. This is because the SSL protocol limits the maximum size to 16 kilobytes for data sent in the payload of any individual message transfer. Therefore, messages or fields exceeding this size must be exchanged by segmentation using multiple message transmissions. (Some higher level applications lower the size limit, and the optimal segment size of the application is known to be determined to be 4K.) The problem with this is that most cryptographic hardware cards and accelerators are driven by large blocks of data. It works best. However, since each encrypted block must contain a calculated hash value (prior to the encryption process) for the data in the block, the SSL protocol prohibits encrypting data in the block that is larger than the maximum record size. Because of this limitation, large messages are sent to the encryption engine using a plurality of segments smaller than the maximum record size (i.e., having space for hash values inserted within each segment), which results in an optimal encryption engine. You cannot use it. (As used herein, "encryption engine" refers to an encryption process that may be implemented in hardware, such as a card or accelerator, but may be implemented in software or a combination of hardware and software in certain circumstances.)

Transaction layer security (TLS) protocol is designed as a subsequent technology to replace SSL. (SSL ends with version 3.0, and TLS begins with version 1.0 based on the SSL version 3.0 specification.) TLS is standardized by the Working Group of the Internet Engineering Task Force (IETF), and was published in January 1999, "The TLS Protocol, Version 1.0 "(RFC 2246). The message exchange in the TLS protocol is similar to the message exchange in the SSL protocol, so TLS also has the above inefficiency.

One way to increase SSL throughput is to embed the entire protocol into a hardware device. In this case, the entire SSL protocol is done at the network layer, and the application only clearly sees the data going to the card interface and the data (unencrypted) coming from the card interface. However, since a typical server may have hundreds of SSL sessions running simultaneously, it can be difficult to manage efficiently within a single card. Also, different applications (and sometimes some different ports within the same application) may require variables in SSL processing, such as different key values, client authentication, and the like. SSL hardware devices that perform the entire protocol will not be flexible or the cost of the card (both in throughput and dollars) will increase as features increase. In addition, SSL hardware will be difficult to update when new ciphers are added to SSL and / or TLS.

Accordingly, there is a need for a technique that improves the method of performing symmetric encryption of bulk data for transmission using a security protocol such as SSL or TLS.

It is an object of the present invention to provide a technique for improving the symmetric encryption of bulk data to be transmitted using a secure protocol such as SSL or TLS.

Another object of the present invention is to use the above technique so that the advantages of larger data blocks can be realized even if the data is to be transmitted in a plurality of smaller blocks.

It is yet another object of the present invention to provide such a technique through pre-processing of a data file to be transmitted using a secure protocol, wherein the preprocessing insists on protocol requirements for transmitting smaller block sizes. A large block size is used to create a modified file in an optimal format for encryption.

Still other objects and advantages of the invention are set forth in part in the following detailed description and drawings.

1 is a block diagram of a computer workstation environment in which the present invention may be practiced,

2 illustrates a networked computing environment in which the invention may be practiced;

3 and 4 are flow diagrams of logic that can be used to implement a preferred embodiment of the present invention,

5 illustrates a data file transmitted to a requestor before and after file processing according to a preferred embodiment of the present invention.

Explanation of symbols for the main parts of the drawings

10 workstation 14 bus

16: user interface adapter 18: keyboard

20: mouse 22: interface device

24: display device 26: display adapter

28: memory 30: storage device

32: communication channel

In order to achieve the above object, the present invention provides a method, system and computer program product for improving how symmetric encryption of bulk data is performed for transmission using a secure protocol. The technique includes determining a file to be transmitted securely and preprocessing the file to optimize a symmetric encryption process to be authorized before secure transmission. The preprocessing step includes calculating a record size of data to be used for the file during the secure transfer, wherein the record size is (segment size-hash length), and dividing the file into a series of records of record size. One of the records may be shorter than the record size—adding free space to each record row, and writing each record string and added free space to an output file. In the last block, a padding block may be appended to the last of the records before the additional step is operated.

The header may be pre-attached to the first record of the output file, which stores information including one or more of the following. (1) identification of the encryption algorithm used in the symmetric encryption process, (2) identification of the hashing algorithm applied to the record before the operation of the symmetric encryption process, and (3) record size.

The technique includes receiving a file request, disposing an output file in response to the receiving, obtaining an encryption key and a hash key associated with the received request, and using the obtained hash key in a sequence. Applying a hashing algorithm to each record, generating an encrypted file for each record by replacing the added empty space with the result of the hashing algorithm, and transmitting the encrypted file in response to the request. It further comprises a step. In this case, the technique also includes adding a header to the head of the output file, the header storing information including identification of a symmetric encryption algorithm, and adding the obtained encryption key to the header for use in encryption. It further comprises a step. Alternatively, the header added to the front may store information including identification of a hashing algorithm, in which case the technique further includes adding a hash key to the header obtained for use in the applying step.

The security protocol may be secure socket layer (SSL), transaction layer security (TLS) or other security protocol.

Hereinafter, the present invention will be described with reference to the accompanying drawings. Like reference numerals in the drawings denote like elements.

1 illustrates an exemplary workstation hardware environment in which the present invention may be practiced. The environment of FIG. 1 includes a representative single user computer workstation 10 that includes associated peripherals such as personal computers. Workstation 10 includes a microprocessor 12 and a bus 14 used to enable connection and communication between the components of workstation 10 and microprocessor 12 in accordance with known techniques. do. Workstation 10 is typically one or more via bus 14, such as keyboard 18, mouse and / or other interface device 22, which may be any user interface device such as a touch screen, digitized input pad, or the like. And a user interface adapter 16 that connects the microprocessor 12 to the interface device. The bus 14 also connects a display device 24, such as an LCD screen or monitor, to the microprocessor 12 through the display adapter 26. Bus 14 also connects microprocessor 12 to long-term storage device 30 and memory 28, which may include hard drives, diskette drives, tape drives, and the like.

Workstation 10 may communicate with another computer or computer network, for example, via a communication channel or modem 32. On the other hand, workstation 10 may communicate using a wireless interface, such as a cellular digital packet data (CDPD) card at 32. Workstation 10 may be associated with other computers in a local area network (LAN) or wide area network (WAN), or may be a client in a client / server device having other computers or the like. All such configurations and appropriate communication hardware and software are known.

2 illustrates a data processing network 40 in which the present invention may be practiced. Data processing network 40 may include a plurality of individual networks, such as wireless network 42 and network 44, which may each include a plurality of individual workstations 10. Those skilled in the art will also appreciate that one or more LANs may be included. Here, the LAN may include a plurality of intelligent workstations coupled to a host processor.

In FIG. 2, networks 42 and 44 may include mainframe computers or servers, such as gateway computer 46 or application server 47 (which may access data store 48). Gateway computer 46 acts as an entrance to each network 44. Gateway 46 may be preferably coupled to other network 42 by communication link 50a. Gateway 46 may also be coupled directly to one or more workstations 10 using communication links 50b and 50c. The gateway computer 46 may be implemented using an Enterprise Systems Architecture / 370, Enterprise Systems Architecture / 390 computer, etc. of IBM Corporation. Depending on the application, a midrange computer such as application system / 400 (also called AS / 400) may be used. ("Enterprise Systems Architecture / 370" is a trademark of IBM. "Enterprise Systems Architecture / 390", "Applicatin System / 400" and "AS / 400" are registered trademarks of IBM.)

Gateway computer 46 may also be coupled to a storage device (such as data store 48) (49). Gateway 46 may also be connected directly or indirectly to one or more workstations 10.

Those skilled in the art will appreciate that the gateway computer 46 may be located geographically remote from the network 42, and likewise, the workstation 10 may be located at a significant distance from the networks 42, 44. will be. For example, network 42 may be located in California, but gateway 46 may be located in Texas, and one or more workstations 10 may be located in New York. The workstation 10 may be connected to the wireless network 42 using a networking protocol such as Transmission Control Protocol / Internet Protocol (TCP / IP) through a number of other connection media such as cellular phones, radio frequency networks, satellite networks, and the like. It may be. The wireless network 42 may be connected to a network such as TCP or User Datagram Protocol (UDP) through IP, X.25, Frame Relay, Integrated Services Digital Network (ISDN), Public Switched Telephone Network (PSTN), or the like. It is preferable to connect to the gateway 46 using 50a). Workstation 10 may also be directly connected to gateway 46 using dial connection 50b or 50c. In addition, wireless network 42 and network 44 may be connected to one or more other networks (not shown) in a manner similar to that shown in FIG.

Software programming code embodying the present invention is typically accessed by a server (eg, server 47) from some type of long-term storage medium 30, such as a CD-ROM drive or hard drive. The software programming code may be executed on any known media for use with data processing systems such as diskettes, hard drives, or CD-ROMs. The code may be distributed on such media and distributed to users for use by users of such other systems from storage or memory of one computer system to other computer systems via some type of network. On the other hand, programming code may be implemented within memory 28 or may be accessed by microprocessor 12 using bus 14. The above techniques and methods for implementing software programming code in memory or on a physical medium and / or techniques and methods for distributing software code over a network are well known and will not be described any further.

A user requesting a file processing the present invention may connect the computer to a server using a wired or wireless connection. Wired connections use physical media, such as cable telephone lines, and wireless connections use media such as satellite links, radio frequency waves, and ultraviolet waves. Many connection techniques can be used with various media such as a computer modem establishing a connection over a telephone line, a LAN card such as token ring or Ethernet, a cellular modem establishing a wireless connection, and the like. The user's computer may be any type of computer processor with processing (and potentially computing) capabilities, such as laptops, handheld or mobile computers, onboard devices, desktop computers, mainframe computers, and the like. Similarly, the remote server can be any one of any number of different types of computers with processing and computing power. These techniques are well known, and hardware devices and software that make use of these hardware are readily available. In the following, a user computer is referred to as a "workstation", "device", or "computer", and these terms or "server" refer to any type of computing device described above.

In a preferred embodiment, the present invention is implemented as one or more computer software programs. The software may be implemented as one or more modules (also called code subroutines or "objects" in object-oriented programming). The logic for practicing the invention may be combined with the code of a program implementing the SSL protocol, or may be implemented as one or more individual utility modules that provide services caused by such a program without departing from the novel concepts disclosed herein. The server operating the present invention may also function as a web server, where the web server provides a service in response to a request from a client connected via the Internet. On the other hand, the server may be in an integrated intranet or extranet, in which the client's workstation constitutes part thereof, or in any other network environment.

Next, a preferred embodiment of the present invention will be described in more detail with reference to FIGS. 3 to 5.

3 illustrates the logic of a file that is preprocessed according to a preferred embodiment. The pre-processing prepares a file that requires minimal processing for use with the SSL protocol, which file is encrypted in one or more large blocks to take advantage of the optimized processing available in the encryption engine. Can be supplied to the engine. 4 illustrates the logic that is preferably used when a request for a file is received at a server, wherein the file has preferably been preprocessed in accordance with the logic of FIG.

The preprocessing of FIG. 3 is preferably performed in advance before receiving a client request for the file. On the other hand, the preprocessing may be done upon receipt of such a request without departing from the scope of the present invention. (In this case, the preprocessed file resulting from the operation of FIG. 3 is preferably stored in persistent storage and may be used to increase efficiency in fulfilling subsequent client requests.) In short, the preprocessing operation is a hall. A hole or empty space is inserted where the SSL protocol of the file requires a hash value.

The preprocessing operation begins at block 300 of FIG. 3, where a file to be preprocessed is obtained. As indicated by block 310, an optional file header may be generated. The file header contains information about the file that can be used to distinguish similar files from each other and to increase the efficiency of subsequent encryption of the file. The SSL protocol is provided for the use of many different bulk encryption algorithms and hashing algorithms. There are a number of differences between the different algorithms. For example, for bulk RC4 ciphers, there are two SSL cipher pairs, one of which uses the MD5 hashing algorithm and the other uses the SHA-1 hashing algorithm. The MD5 hash uses 128 bits, while the SHA-1 hash uses 140 bits. Thus, files that are preprocessed for use with MD5 hashes require inserting smaller holes than files that are preprocessed for use with SHA-1 hashes. Another difference also exists between cipher pairs and algorithms, such as whether padding is requested at the end of a file that does not end on a particular boundary, the number of record sizes used for transmission. Because of these types of differences, it may be desirable to preprocess individual files in more than one format. The header of each stored version may be used to identify which algorithm is used with the preprocessed file, and the appropriate version stored may be selected based on which cipher pairs are determined between the client and the server. (This will be described later with reference to block 430 of FIG. 4). The header also preferably indicates the record size used when inserting the hole. (If the default record size of 16K is always used, the information will be omitted. May be).

5A illustrates an example of a data file to be sent to the requestor prior to processing the file in accordance with the present invention. The contents of the file are stored as byte strings as in the prior art. FIG. 5B illustrates a data file after processing the file according to the logic of FIG. 3. The optional header is shown at 510 and is stored once at the beginning of the preprocessed file. (The header is not sent to the client, but used internally within the server for the purposes of the present invention.)

In FIG. 3, the record size used for transmitted message segments for the file is calculated at block 320. This involves subtracting the length of the hash from the length of the data used for the message payload. For example, if 16K bytes of data are sent in each message segment and a 128 bit (16 bytes) hash is used in the MD5 hash described above, the record size calculated at block 320 is (16K-16) bytes. to be. Then, the optional header, when used, is written to the resulting output file (block 330). As mentioned above, the information recorded in the header preferably includes the identification of the encryption algorithm and hashing algorithm for preparing the file, and the record size used. (Next, other information may be inserted into the header when preparing a file for encryption and transmitting it to a specific client according to Fig. 4. This will be described later.)

Block 340 queries whether the end of the file to be processed has been reached. If the end is reached, the process of FIG. 3 ends. Otherwise, the process is repeated through the logic of blocks 350 and 360 until the end of the input file. Block 350 obtains the next bytes of the input file, for the length specified by the record size calculated at block 320, and adds a blank space at the end of the data. The empty space has the same length as requested by the hashing algorithm for preparing the file. If the number of remaining bytes processed in the input file is less than the calculated record size, and if the cipher pair in use requires this type of padding short block, block 350 may add the required amount before adding free space. Add padding of. Block 360 then writes the data block generated by block 350 to an output file, after which control passes to block 340.

The output file of FIG. 5B illustrates how the input file of FIG. 5A is modified by the processing operation of FIG. 3. An empty space (eg, elements 525 and 535) follows each data block (elements 520 and 530). The empty space is inserted where the SSL protocol requires a hash of each data block. The final data block 590 in this example is followed by a padding space 592, followed by the last empty space 595.

The logic of Figure 4 occurs when a file transfer request to a client is received. When the request is received (block 400 of FIG. 4A), a test is made to determine if a preprocessed version of the file is available. If not available, the file may be processed and sent according to the prior art, as shown in block 420, and then the processing of FIG. 4 for the request ends. (On the other hand, the logic of Figure 3 may be implemented to generate a preprocessed version of the file as described above. In this case, the processing of Figure 4 preferably continues at block 430 after the preprocessing operation is complete. If the test at block 410 has a positive result, block 430 checks whether a version that prepares the encryption algorithm and the hashing algorithm that is determined for use between the server and the requesting client is available. If not available, the file may be processed and sent according to the prior art as shown in block 420, and in other embodiments the logic of FIG. 3 may be implemented to generate the appropriate version, Next, the processing of FIG. 4 preferably continues at block 440.

If a preprocessed version of the requested file is available, control passes to block 440. The file has a free space where the hash values requested by SSL need to be inserted before sending the file to the requesting client. Block 450 obtains an encryption key and a hash key used to further prepare the file for transmission. According to the SSL protocol, both the encryption key and the hash key are determined once again for the SSL connection. This requires delaying the calculation of the hash value until the receiver knows it (this leads to storing the preprocessed file with empty space to which the hash value belongs, not the actual calculated hash value).

Block 460 (FIG. 4B) then checks to see if the end of the file being processed has been reached. If the end of the file has not been reached, blocks 480 and 495 repeat the output file processing and prepare to send it to the intended receiver. Block 480 calculates a hash for the next block of data in the file using a hashing algorithm determined (according to the prior art SSL handshaking protocol). Block 495 then inserts the calculated hash instead of the free space reserved for the block, and then control is returned to block 460. (Preferably, a data buffer or temporary file is used instead of writing back directly to the preprocessed file.)

Once the hash value for the entire file to be transferred is calculated, control passes to block 470. Block 470 is sent to the encryption engine along with the encryption key used to send the processed data buffer to the client. If an initialization vector is used to prepare the encryption engine, the vector is also preferably transmitted at this time. After the encryption engine encrypts the data buffer (using a block of data appropriate for a particular encryption engine in use), the data is partitioned according to the record size used (e.g., up to 16K record size of the SSL protocol). . Using prior art SSL messages and techniques, multiple segments of the file are then inserted into the payload of multiple outgoing SSL messages (one segment per message payload) as shown in block 490 to the client. Is sent. (The actual transmission of the data is preferably performed directly from the encryption engine. The operation is shown in Figure 4, indicating that the encrypted data must be returned to the same logic to perform the operations of Figure 4 before being sent to the client. The processing of the client's request is then completed using the improved process of the present invention.

In an optional aspect of the preferred embodiment, the header of the processed file may be updated to include additional information prior to operation of block 470. The additional information includes an encryption key used by the encryption engine, and an initialization vector if there is an initialization vector used to prepare the encryption algorithm. In this way, all the information needed by the encryption engine is provided in the file header. This method is particularly advantageous when used with a hardware device or software interface that is designed to take a data file and return valid SSL records in bulk.

In another aspect, a hash key may be included in the file header. When the method is used, the hashing process shown at blocks 460, 480, 495 is not performed before sending the file to the encryption engine, but is performed by the encryption engine itself upon receiving the file.

In another aspect, when a hashing process is performed by the encryption engine, the hash key is sent to the encryption engine during the processing of block 470 (described above).

Additional processing efficiency may be realized by pipelining the encryption process in parallel via an encryption engine (or an array of encryption engines), so that the encryption process responds with overlapping network delays in client / server requests.

As noted above, the present invention provides an improved technique for symmetric encryption of bulk data sent to a requestor using a secure protocol such as SSL or TLS, which can increase throughput when sending a file to the requester. The delay can be reduced. The files are prepared and stored in such a way that much more than 16K can be sent to the encryption engine. With minor modifications to the supplied file, only minor modifications are required to the existing SSL processing. No modifications to the SSL or TLS protocols are required. The technique provides a flexible solution that can be easily applied for use with changes in message payload size and changes in encryption algorithms and hashing algorithms (including variable hash value lengths). The technique can increase the throughput of SSL traffic by adding only minimal processing.

While the preferred embodiment of the present invention has been described above, once a person skilled in the art understands the basic concept of the present invention, additional changes and modifications may be made to the embodiment. The technique disclosed herein is based on predefined features of the security protocols (SSL, TLS) to be processed. The concepts of the invention disclosed herein may be adapted to changes in the security protocol as changes in the security protocol occur, including a complete replacement with a new protocol having the same meaning as discussed herein. Accordingly, it is noted that the appended claims are intended to cover all such variations and modifications as fall within the spirit and scope of the preferred embodiment and invention described above.

Claims (26)

delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete delete A method for improving the efficiency of symmetric encryption of bulk data to be transmitted using a secure protocol, the method comprising: Determining a file to be securely transferred, Preprocessing the file to optimize a symmetric encryption process to be performed prior to the secure transmission, The preprocessing step, Calculating a record size of data used for the file during the secure transmission, wherein the record size is (transmission segment size-hash length); Dividing the file into a record row of the record size, wherein the last record of the records may be shorter than the record size; Adding an empty space to each of said record columns; Writing each of the record strings and the added empty spaces to an output file. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 17, Adding a padding block to the last record of the records before adding the empty space to each of the record columns is done on the last block. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 17, Adding a header to the beginning of the first of the records in the output file, the header comprising (1) an identification of an encryption algorithm used by the symmetric encryption process, and (2) I) identifying a hashing algorithm applied to the records prior to operation of the symmetric encryption process, and (3) storing information comprising at least one of the record size A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 17, Receiving a request for the file, In response to receiving the request, locating the output file; Obtaining a hash key and an encryption key associated with the received request; Applying a hashing algorithm to each record in the record row using the obtained hash key; For each record, generating a hash file by replacing the added empty space with the result of the hashing algorithm; Encrypting the hash file using the obtained encryption key and a symmetric encryption algorithm for performing the symmetric encryption process to generate an encrypted file; Sending the encrypted file in response to the request. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 20, Prepending a header to the head of the output file, the header storing information including identification of the symmetric encryption algorithm; Adding the obtained encryption key to the header to be used by encrypting the hash key. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 20, Prepending a header to the head of the output file, the header storing information including an identification of the hashing algorithm; Adding the obtained hash key to the header for use by applying the hashing algorithm. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 21, The header further includes an initialization vector used by encrypting the hash file. A method for improving the efficiency of symmetric encryption of bulk data. The method of claim 22, The header further includes an initialization vector used by encrypting the hash file. A method for improving the efficiency of symmetric encryption of bulk data. A computer-readable recording medium having recorded thereon a program for implementing the method according to any one of claims 17 to 24 on a computer. A system for improving the efficiency of symmetric encryption of bulk data to be transmitted using a security protocol, comprising respective means for implementing each step of the method according to any one of claims 17 to 24.