Symmetric cryptographic method and system and applications thereof

REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit from U.S. Provisional Application Ser. No. 62/464,160 filed on Feb. 27, 2017 entitled “CRYPTOGRAPHIC METHOD AND SYSTEM”, the entire contents of which are incorporated herein by reference. This application also claims the benefit from U.S. Provisional Application Ser. No. 62/524,576 filed on Jun. 25, 2017 entitled “CRYPTOGRAPHIC METHOD AND SYSTEM AND APPLICATIONS THEREOF”, the entire contents of which are incorporated herein by reference.

FIELD OF THE INVENTION

0002The present application relates to the general field of cryptography, and in particular to the generation and management of keys for cryptography.

BACKGROUND OF THE INVENTION

0003In a cryptographic system using symmetric cryptography (also known as “secret-key” cryptography), the involved parties share a common secret (password, pass phrase, or key). Data is encrypted and decrypted using the same key. Any party possessing a specific key can create encrypted messages using that key as well as decrypt any messages encrypted with the key. In systems involving a number of users who each need to set up independent, secure communication channels, symmetric cryptosystems can have practical limitations due to the requirement to securely distribute and manage large numbers of keys. Security of encrypted information is optimized when a different, random key is used for each piece of information. Consequently, a very large number of keys is required to deliver optimal security using symmetric cryptography.

0004Widely used cryptographic algorithms, such as the Advanced Encryption Standard (AES) and the Data Encryption Standard (DES) in its Triple-DES incarnation, are openly published and publicly available. These algorithms deliver strong security when an attacker cannot determine the key or keys used for encryption even though the attacker is fully aware and knowledgeable regarding the cryptographic algorithm used for encryption and may have the encrypted data available to repeatedly attempt to determine the encryption key(s).

0005The encryption keys used in cryptographic operations for symmetric cryptography are typically genuinely random. The use of a genuinely random key prevents an attacker from determining that key other than through what is known as a “brute-force attack”. In a brute force attack, the attacker has to find the key through trial-and-error by sequentially trying permutations of possible keys in the space of all potential keys. If the number of possible permutations for a key is sufficiently large, it is infeasible for attackers to mount effective brute-force attacks to find keys in any reasonable time frame (on average), even using highly advanced computing systems.

0006A primary challenge to the use of cryptography is the management of the encryption keys. In this context, “encryption key management” refers to how strong encryption keys (i.e., random keys of sufficient length) are securely generated, stored, shared and, if and when necessary, recovered.

0007Key management issues can be very challenging to solve, as solving one of the key management issues often generates one or more additional key management issues or makes another key management issue more difficult to execute optimally.

0008For example, traditionally, symmetric encryption keys have been generated using hardware-based random number generators or software-based pseudo random number generators (PRNGs). However, once a traditional random number generator is used to generate a genuinely random number that is to be used as an encryption key, that key must be stored for later retrieval for decryption because it is impossible to deterministically re-generate that same key in the future using that same random number generator. In this regard, then, generating genuinely random numbers for strong symmetric keys leads directly to the need to store those keys securely for future retrieval.

0009Additionally, it is optimal to use a unique, genuinely random symmetric key for each distinct piece of information, rather than using a single key for all pieces of information or re-using a key across multiple pieces of information. If a different key is used for each piece of information, all other pieces of data will remain secure even if one key associated with one piece of information is compromised by some means.

0010However, when a unique key is used to protect each piece of information, the number of unique keys expands rapidly. This issue requires the management of keys to be executed in a scalable manner that will not limit the number of keys that can be generated and used. This ability to scale the key management can make it increasingly substantially difficult to securely store these keys.

0011Secure key storage is further made difficult for certain types of computer processes. For instance, services that operate on servers or in dedicated hardware appliances have a challenging requirement to store and access keys in a secure manner. Unlike servers and hardware appliances, endpoint devices, such as workstations and mobile devices, can be directly accessed by users and, therefore, keys can be stored securely using user-entered passwords or other techniques that can generate keys to encrypt and decrypt stored keys. In other words, when a key need to be accessed, an end user can be prompted to enter the corresponding password, passphrase, or other information that generates a key to decrypt the key or keys stored securely.

0012However, it is not possible for humans to easily or effectively enter passwords on computer servers or hardware appliances for server applications, other than potentially when the server applications first “boot up” and initialize. Once a server application is operating, it is not realistically possible to stop the application to wait for a person to enter information to “unlock” a key. Given the speed and capacities of modern servers and appliances serving many users at one time, stopping a server application to have a human “unlock” a key is infeasible from all perspectives. Therefore, the technique explained above to protect keys stored on end-user devices cannot be used to protect keys on servers. This is a significant issue because servers often hold vast amounts of information that would be optimally secured using a large number of keys.

0013Further, the sharing of a large number of keys is also extremely difficult. If each piece of information is encrypted with a unique key, those keys need to be shared by any users and software/hardware processes needing to access the information. Securely sharing one key or a small number of keys among a group of people or software/hardware processes is challenging. Securely sharing a large number of keys among a similar group is completely untenable. There is a significant problem in scalability related to key sharing.

0014Clearly, there is a need for a cryptographic system that mitigates these issues by enabling broad-scale use of symmetric cryptography with genuinely random keys, but eliminating the need for users to share keys to enable encryption/decryption, and eliminate the need for keys to be stored.

SUMMARY OF THE INVENTION

0015There is an object of the invention to provide an improved symmetric cryptographic system and method.

0016There is also another object of the invention to provide an improved method and system for generating and managing a cryptographic key for a symmetric cryptographic system.

0017Also there is an object of the invention to provide various applications of the improved cryptographic system and method, as substantially described herein below.

0018According to one aspect of the invention, there is provided a symmetric cryptographic system, comprising: a memory having computer executable instructions stored thereon, causing a processor to form: two or more inputs, at least one of said two or more inputs being secret; a key generator configured to use said two or more inputs to reproducibly generate a secret key; and a cryptographic engine configured to use the secret key for encrypting data, thereby creating encrypted data.

0019In the system described above, the cryptographic engine is further configured to generate and use the secret key for decrypting the encrypted data.

0020In the system described above, said two or more inputs comprise a first input and a second input; and the second input is based at least in part on the first input. In the system described above, the second input may be a fixed string of data bits.

0021Alternatively, the second input may be a plurality of bits from an entropy bit string. Accordingly, the key generator further comprises an entropy bit string generator generating the plurality of bits from the entropy bit string based in part on the first input.

0022In the system described above: the key generator comprises a deterministic algorithm module using a symmetric algorithm for generating random numbers; the symmetric algorithm reproducibly generates the same random number based on same said two or more inputs; the random number is utilized to create said secret key.

0023The system further comprises a third input, and the key generator is configured to further use the third input to reproducibly generate the secret key. The third input may be at least one bit mask.

0024Alternatively, the third input may be one or more bit masks, and at least one of the following is secret: the first input, the first input being a token; the second input, the second input comprising at least one of the following which is secret: an entropy bit string; a random number generator for selecting a plurality of bits from the entropy string based in part on the token; the plurality of bits; and the third input.

0025The secret key is generated prior to the encrypting, and destroyed after completion of the encrypting.

0026According to another aspect of the invention, there is provided an apparatus for generating and managing a cryptographic key for a symmetric cryptographic system, the apparatus comprising: a memory device having computer readable instructions stored thereon for execution by a processor, causing the processor to form: the cryptographic key having two states: a potential state where the cryptographic key is comprised of two or more input components from which the cryptographic key is to be generated, at least one of said two or more input components being secret, the cryptographic key in the potential state not being suitable for encrypting or decrypting data; an active state where the cryptographic key has been generated using said two or more input components, the cryptographic key in the active state being suitable for encrypting or decrypting data; a cryptographic key generator for transforming the cryptographic key from the potential state into the active state using said two or more input components immediately prior to the encrypting or decrypting the data, and transforming the cryptographic key from the active state back into the potential state immediately upon the encryption or decryption of the data has been completed.

0027According to yet another aspect of the invention, there is provided a symmetric cryptographic system, comprising: at least two cryptographic modules, each of the at least two cryptographic modules having a memory having computer executable instructions stored thereon, causing a processor to form: two or more inputs, at least one of said two or more inputs being secret; a key generator configured to use said two or more inputs to reproducibly generate a secret key; an cryptographic engine configured to use the secret key for encrypting data, thereby creating encrypted data, the cryptographic engine configured to use the secret key for decrypting the encrypted data, said at least one of said two or more input is secret.

0028The least one of the at least two cryptographic modules encrypts the data and another one of the at least two cryptographic modules decrypts the encrypted data.

0029In the system described above, the two or more inputs comprise a first input and a second input; the first input is a token, and the second input is a fixed string of bits obtained from an entropy bit string.

0030The key generator comprises a deterministic algorithm module using a symmetric algorithm for generating random numbers; the symmetric algorithm reproducibly generates the same random number based on same said two or more inputs; and the random number is utilized to create said secret key.

0031Additionally a third input may be further used, the third input being one or more bit masks for example.

0032The system is configured to generate the secret key respectively prior to the encrypting or decryption, and respectively destroy the secret key after completion of the encrypting or decrypting.

0033According to one more aspect of the invention, there is provided a method for symmetric cryptography, comprising: employing at least one hardware processor for: at an encryption location: obtaining two or more inputs, at least one of said two or more inputs being secret; using said two or more inputs to reproducibly generate a secret key; encrypting data using the secret key, thereby creating encrypted data; at a decryption location: obtaining said two or more inputs; using said two or more inputs to reproducibly generate the secret key; using the secret key generated at the decryption location to decrypt the encrypted data; communicating said at least one of said two or more inputs which is secret, and computer readable instructions for reproducibly generating the secret key to both the encryption and decryption locations prior to the encrypting and the decrypting.

0034In the method described above, the obtaining the two or more inputs further comprises obtaining a first input and a second input, wherein the first input is a token, and the second input is a fixed string of bits obtained from an entropy bit string.

0035In the method described above: the step to reproducibly generate the secret key comprises applying a deterministic symmetric algorithm for generating random numbers; wherein the same random number is generated based on same said two or more inputs and the random number is utilized to create said secret key.

0036In the method described above, the obtaining the two or more inputs further comprises obtaining a third input, which is one or more bit masks.

0037The method further comprises generating the secret key respectively prior to the encrypting or decrypting, and respectively destroying the secret key after completing the encrypting or decrypting.

0038According to yet one more aspect of the invention, there is provided a one-to-many symmetric cryptographic system having a central location being in communication with at least one remote location, the system comprising: the central location having a memory having executable instructions stored thereon, causing a processor to: receive a document from at least one of at least one remote location; and provide the document to a cryptographic module for encryption, the cryptographic module having: two or more inputs, at least one of said two or more inputs being secret and at least one of said two or more inputs being specific to the document; a key generator configured to use said two or more inputs to reproducibly generate a secret key specific to each document; and a cryptographic engine configured to use the secret key for encrypting the document, thereby creating an encrypted document.

0039In the one-to-many system described above, the processor is further configured to provide the document to the cryptographic module for decryption, and the cryptographic engine is further configured to generate and use the secret key for decrypting the encrypted data.

0040The document may be an email message, or a file. The file may be stored locally, or at a remote location.

0041The one-to-many system described above further comprises a storage configured to store the encrypted document.

0042In the one-to-many system described above, at least one of the two or more inputs is publicly available.

0043In the one-to-many system described above, one of the two or more inputs is a fixed string of data bits. Additionally, a third input may be also provided, and the key generator is configured to further use the third input to reproducibly generate the secret key. The third input is at least one bit mask.

0044In the one-to-many system described above, the key generator may comprise a deterministic algorithm module using a symmetric algorithm for generating random numbers; the symmetric algorithm reproducibly generates the same random number based on same said two or more inputs; and the random number is utilized to create said secret key.

0045Alternatively, in the one-to-many system described above, said two or more inputs comprise a first input and a second input; the first input is a token, and the second input is a fixed string of bits obtained from an entropy bit string. The second input may be based at least in part on the first input, and the key generator may further comprise an entropy bit string generator generating the plurality of bits from the entropy bit string based in part on the first input.

0046In the one-to-many system described above, the secret key is generated prior to the encrypting, and destroyed upon completion of the encrypting.

0047According to yet one more aspect of the invention, there is provided a method for one-to-many symmetric cryptography within a symmetric cryptographic system having a central location being in communication with at least one remote location, comprising: at the central location: receiving a document from at least one of at least one remote locations; and encrypting the document comprising: obtaining two or more inputs, at least one of said two or more inputs being secret and at least one of said two or more inputs being specific to the document; using said two or more inputs to reproducibly generate a secret key specific to each document; and encrypting the document using the secret key, thereby creating an encrypted document.

0048The method further comprises decrypting the encrypted document using the secret key.

0049In the method described above, the document is an email message or a file.

0050In the method described above, at least one of the two or more inputs is publicly available.

0051The step of encrypting the document may further comprise obtaining a third input, and using the third input to reproducibly generate the secret key. The third input may be a bit mask.

0052According to yet one further aspect of the invention, there is provided a many-to-many symmetric cryptographic system comprising: a plurality of cryptographic modules being in communication over a communication network; each of the plurality of cryptographic modules having a memory having executable instructions stored thereon, causing a processor to: receive a document from at least one of the remaining plurality of cryptographic modules for encryption creating an encrypted document; provide the encrypted document to at least one of the remaining plurality of cryptographic modules for decryption creating a decrypted document; each of the plurality of cryptographic modules having: two or more inputs, at least one of said two or more inputs being secret and at least one of said two or more inputs being specific to the document; a key generator configured to use said two or more inputs to reproducibly generate a secret key specific to each document; and a cryptographic engine configured to use the secret key for encrypting the document, thereby creating the encrypted document and configured to use the secret key for decrypting the encrypted document, thereby creating the decrypted document, wherein the secret key specific to the document is destroyed after the completion of the encrypting and after the completion of the decrypting.

0053The many-to-many system described above further comprises a storage in communication with the communication network and being configured to store each encrypted document.

0054In the many-to-many system described above, at least one of the two or more inputs is publicly available, and the at least one publicly available inputs is at stored on the storage.

0055In the many-to-many system described above, one of the two or more inputs is a fixed string of data bits.

0056In the many-to-many system described above, one of the two or more inputs may be a plurality of bits from an entropy bit string.

0057In the many-to-many system described above, the key generator is a deterministic algorithm module using a symmetric algorithm for generating random numbers; the symmetric algorithm reproducibly generates the same random number based on same said two or more inputs; and the random number is utilized to create said secret key.

0058In the many-to-many system described above, the two or more inputs comprise a first input and a second input; and the second input is based at least in part on the first input. The key generator further has an entropy bit string generator generating a plurality of bits from an entropy bit string based in part on the first input.

0059The many-to-many system may further have a third input; and the key generator is configured to further use the third input to reproducibly generate the secret key. The third input may be at least one bit mask.

0060According to yet one more aspect of the invention, there is provided a method for many-to-many symmetric cryptography within a symmetric cryptographic system having a plurality of cryptographic modules being in communication over a communication network, the method comprising: employing a plurality of hardware processor for performing the following: at each cryptographic module, receiving a document from at least one of the remaining of the plurality of cryptographic modules for encryption for creating an encrypted document; providing the encrypted document to at least one of the remaining of the plurality of cryptographic modules for decryption creating a decrypted document, each the cryptographic module: obtaining two or more inputs, at least one of said two or more inputs being secret and at least one of said two or more inputs being specific to the document; reproducibly generating a secret key specific to the document using said two or more inputs; and encrypting the document using the secret key, thereby creating the encrypted document, and decrypting the encrypted document using the secret key, thereby creating the decrypted document.

0061The method further comprises storing the encrypted document at a storage in communication with the communication network.

0062In the method described above, at least one of the two or more inputs is publicly available.

0063In one embodiment of the invention, one of the two or more inputs is a fixed string of data bits. In another embodiment, one of the two or more inputs is a plurality of bits from an entropy bit string.

0064The step of reproducibly generating the secret key may comprise a symmetric algorithm for generating random numbers; the symmetric algorithm reproducibly generates the same random number based on same said two or more inputs; and the random number is utilized to create the secret key.

0065In the method described above, the step of obtaining the two or more inputs comprises obtaining a first input and a second input; and the second input is based at least in part on the first input.

0066The step of reproducibly generating the secret key comprises generating a plurality of bits from an entropy bit string based in part on the first input.

0067The method further comprises obtaining a third input; and reproducibly generating the secret key using the third input. The third input is at least one bit mask.

0068Thus, an improved symmetric cryptographic system and method, and method and system for generating and managing a cryptographic key for a symmetric cryptographic system have been provided.

BRIEF DESCRIPTION OF THE DRAWINGS

0069In drawings which illustrate embodiments of the invention wherein similar characters of reference denote corresponding parts in each view,

0070<figref idref="DRAWINGS">FIG. 1A</figref> is a block diagram of a cryptographic system illustrating encryption in accordance with an embodiment of the present invention;

0071<figref idref="DRAWINGS">FIG. 1B</figref> is a block diagram of the cryptographic system shown in <figref idref="DRAWINGS">FIG. 1A</figref> illustrating decryption in accordance with an embodiment of the present invention;

0072<figref idref="DRAWINGS">FIG. 2A</figref> is a flowchart of a method for encrypting data utilizing the cryptographic system shown in <figref idref="DRAWINGS">FIG. 1A</figref> in accordance with the embodiment of the present invention;

0073<figref idref="DRAWINGS">FIG. 2B</figref> is a flowchart of a method for decrypting data utilizing the cryptographic system shown in <figref idref="DRAWINGS">FIG. 1B</figref> in accordance with the embodiment of the present invention;

0074<figref idref="DRAWINGS">FIG. 3</figref> is a block diagram of a cryptographic system illustrating encryption and decryption in accordance with an embodiment of the present invention;

0075<figref idref="DRAWINGS">FIG. 3A</figref> is a block diagram of a cryptographic system illustrating encryption and decryption in accordance with an embodiment of the present invention;

0076<figref idref="DRAWINGS">FIG. 4A</figref> is part of a flowchart of a method for encrypting and decrypting data utilizing the cryptographic system shown in <figref idref="DRAWINGS">FIG. 3</figref> in accordance with the embodiment of the present invention;

0077<figref idref="DRAWINGS">FIG. 4B</figref> is part of a flowchart of a method for encrypting and decrypting data utilizing the cryptographic system shown in <figref idref="DRAWINGS">FIG. 3</figref> in accordance with the embodiment of the present invention;

0078<figref idref="DRAWINGS">FIG. 5A</figref> is a block diagram of an embodiment of a cryptographic module key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref> illustrating a token being generated from a token generator;

0079<figref idref="DRAWINGS">FIG. 5B</figref> is a block diagram of an embodiment of a cryptographic module key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref> illustrating a token being received from a storage;

0080<figref idref="DRAWINGS">FIG. 6</figref> is a block diagram of an embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0081<figref idref="DRAWINGS">FIG. 6A</figref> is a block diagram of an additional embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0082<figref idref="DRAWINGS">FIG. 6B</figref> is a block diagram of an additional embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0083<figref idref="DRAWINGS">FIG. 7</figref> is a block diagram of an embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0084<figref idref="DRAWINGS">FIG. 8</figref> is a block diagram of an embodiment of a random number generator shown in <figref idref="DRAWINGS">FIG. 7</figref>;

0085<figref idref="DRAWINGS">FIG. 9A</figref> is part of a flowchart of a method for generating a key utilizing the key generator in <figref idref="DRAWINGS">FIG. 7</figref> in accordance with the embodiment of the present invention;

0086<figref idref="DRAWINGS">FIG. 9B</figref> is part of a flowchart of a method for generating a key utilizing the key generator in <figref idref="DRAWINGS">FIG. 7</figref> in accordance with the embodiment of the present invention;

0087<figref idref="DRAWINGS">FIG. 10</figref> is a block diagram of an additional embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0088<figref idref="DRAWINGS">FIG. 11</figref> is a block diagram of an embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0089<figref idref="DRAWINGS">FIG. 12</figref> is a table illustrating results from a bit mask processing using an XOR procedure;

0090<figref idref="DRAWINGS">FIG. 13</figref> is a flowchart of a method for encrypting data utilizing the key generator shown in <figref idref="DRAWINGS">FIG. 11</figref> in accordance with the embodiment of the present invention;

0091<figref idref="DRAWINGS">FIG. 14</figref> is a block diagram of an additional embodiment of a key generator shown in <figref idref="DRAWINGS">FIG. 1A</figref>;

0092<figref idref="DRAWINGS">FIG. 15</figref> is a schematic diagram of an embodiment of an application of the embodiments of the present invention;

0093<figref idref="DRAWINGS">FIG. 16</figref> is a schematic diagram of an additional embodiment of another application of the embodiments of the present invention;

0094<figref idref="DRAWINGS">FIG. 17</figref> is a schematic diagram of an additional embodiment of yet another application of the embodiments of the present invention;

0095<figref idref="DRAWINGS">FIG. 18</figref> is a schematic diagram of an additional embodiment of yet one more application of the embodiments of the present invention; and

0096<figref idref="DRAWINGS">FIG. 19</figref> is a schematic diagram of an additional embodiment of yet one further application of the embodiments of the present invention.

DETAILED DESCRIPTION OF EMBODIMENTS OF THE INVENTION

0097Embodiments of the present invention generally provide systems and methods that perform encryption and decryption of data. In particular, embodiments of the present invention use symmetric cryptography for encryption/decryption.

0098Embodiments of the present invention minimize the challenges of key management by avoiding key storage and transmission altogether. This accomplished by enabling software and hardware processes to generate and re-generate keys when needed, rather than storing and/or transmitting keys through complex schemes. These embodiments provide keys that are scalably and securely generated and re-generated when needed by the processes that use the keys.

0099Embodiments of the present invention can generate and regenerate the same symmetric key from a token, but knowledge of the token does not provide any advantage to an attacker to derive the symmetric key. This provides advantages over conventional cryptography systems because conventional approaches to using symmetric keys for cryptography require securely storing large numbers of symmetric keys in a central location, or a shared secret for users to enter to generate and regenerate the same key, or the use of key sharing techniques, such as public-key cryptography.

0100Improving key management for symmetric cryptography is important because it is projected that currently used, widely available algorithms for public-key cryptography, such as an Rivest-Shamir-Adleman (RSA) algorithm or a wide variety of Elliptic-Curve Cryptography algorithms, will be rendered breakable through the use of quantum computers, whereas symmetric cryptography algorithms, such as AES with 256-bit keys, will not be broken by quantum computing when keys are genuinely random.

0101Embodiments of the present invention eliminate the need for cryptographic key management. Generating a random number for a symmetric key and being able to regenerate the same random number in the future based on a “token” mitigates the problems of key management. The ability to have a “token” be able to be known, but to have knowledge of the “token” provide no advantage to an attacker determining the key is essential to the elimination of key management issues.

0102Referring to <figref idref="DRAWINGS">FIGS. 1A and 1B</figref>, there is shown a block diagram of a system <b>100</b> in accordance with an embodiment of the present invention.

0103The system <b>100</b> includes a cryptographic module <b>102</b> having a key generator <b>106</b> for reproducibly generating the same symmetric key <b>108</b> using a first input, referred to as token <b>104</b> and a second input, referred to as KeyGen data <b>105</b>. The token <b>104</b> may be a randomly generated number and the KeyGen data <b>105</b> may be a sequence of bits (0's and 1's), which may or may not be random, which are used by the key generator <b>106</b> to create symmetric key <b>108</b>. Token <b>104</b> may be publicly available while KeyGen data <b>105</b> may be secured and not available publicly. KeyGen data <b>105</b> is illustrative as residing within cryptographic module <b>102</b>. This is not meant to be limiting as those skilled in the art will recognize that KeyGen data <b>105</b> may be securely stored outside of cryptographic module <b>102</b>. Further, it is indicated that token <b>104</b> is publicly available while KeyGen data <b>105</b> is not publicly available. This is illustrative and not meant to be limiting. Those skilled in the art will recognize that it is within the scope of the invention that only one of token <b>104</b> and KeyGen data <b>105</b> may be not publicly available while the remaining input may be publicly available.

0104Token <b>104</b> may be a set of bits that includes random bits and, if desired, information bits. Token <b>104</b> may also be initially a random number generated using traditional hardware-based or software-based random number generation. It can be of varying sizes depending on system configuration. The token <b>104</b> is a number that is used as a first input to key generator <b>106</b>. Token <b>104</b> is initially created by a token generator <b>502</b>, see <figref idref="DRAWINGS">FIG. 5A</figref>, during the initial process of generating a key <b>108</b> for encryption. Once generated, tokens may be stored with the encrypted data or separately in a storage device <b>522</b>. When there is a need to decrypt the encrypted data at a later time, the token <b>104</b> may be received from the storage device <b>522</b> or along with encrypted data and used to regenerate the key <b>108</b>, see <figref idref="DRAWINGS">FIG. 5B</figref>.

0105KeyGen data <b>105</b>, as referred to as the second input, may be a fixed, static sequence of bits, a sequence of bits generated independently from the first input or a sequence of bits generated based in part on the first input. Various embodiments of KeyGen data <b>105</b> are described below.

0106Key generator <b>106</b> is the module of the present invention that reproducibly generates key <b>108</b>. Key generator <b>106</b> is configured to use two or more unique inputs, i.e. a number and sequences of bits, in this embodiment a token <b>104</b> and a KeyGen data <b>105</b>, to create the key <b>108</b>. The processes by which key <b>108</b> is created by key generator <b>106</b> is largely dependent upon the type and condition of the inputs. As will be described below, key generator <b>106</b> may include one or more algorithms, such as symmetric cryptography algorithms, bit selection algorithms and entropy bit string generator algorithms.

0107Reproducibly generating the same symmetric key <b>108</b> means key <b>108</b> can be reproduced at different points in time and is not maintained or stored after its use to encrypt or decrypt data. Key <b>108</b> can be of variable length. Key generator <b>106</b> can generate/regenerate an appropriate length key <b>108</b> for a cryptographic algorithm that will use the key <b>108</b>. This is advantageous since various symmetric algorithms use different lengths of cryptographic keys.

0108Cryptographic module <b>102</b> also includes a cryptographic engine <b>110</b> for encrypting an input plain data <b>112</b> using key <b>108</b> provided by key generator <b>106</b> into encrypted data <b>114</b>, see <figref idref="DRAWINGS">FIG. 1A</figref>, and for decrypting encrypted data <b>114</b> into plain data <b>124</b> which is substantially identical to plain data <b>112</b>, see <figref idref="DRAWINGS">FIG. 1B</figref>. The cryptographic engine <b>110</b> may be, for example, a Triple-Data Encryption Standard (Triple-DES) algorithm, an Advanced Encryption Standard (AES) algorithm or any other symmetric algorithm known in the art, whether that algorithm is known now or is developed at some point in the future.

0109This embodiment illustrates a single cryptographic module <b>102</b> configured to both encrypt and decrypt data while being located at a single location utilizing a single publicly available input and a single not publicly available input. Those skilled in the art will recognize this is illustrative and not meant to be limiting. As will be shown below, it is within the scope of the present invention to have multiple cryptographic modules located at various locations having more than one publicly and/or not publicly available inputs.

0110Further, system <b>102</b> may create multiple encryption keys by changing token <b>104</b>. When token <b>104</b> is changed, key generator <b>106</b> may generate a completely different key <b>108</b>. Thus, system <b>102</b> enables a highly scalable key management approach but does not require keys to be stored. This type of system is ideal for server-based computer processes where human intervention is not possible and there is a need for a large number of encryption keys to deliver optimal security.

0111Referring now to <figref idref="DRAWINGS">FIG. 2A</figref> there is shown a flowchart <b>200</b> of a method for encrypting data in accordance with an embodiment of the present invention.

0112First, token <b>104</b> is received <b>202</b> by cryptographic module <b>102</b>. Token <b>104</b> may be generated, as set out above, if this is the token's initial use as input to the key generator <b>106</b>. If token <b>104</b> has previously been generated and stored in a storage device or along with data, cryptographic module <b>102</b> may receive token <b>104</b> from that storage device or along with data.

0113Next, key <b>108</b> is generated <b>204</b> using token <b>104</b> and KeyGen data <b>105</b> by key generator <b>106</b> as described in detail herein below.

0114Next, the input plain data <b>112</b> is encrypted <b>206</b> into encrypted data <b>114</b> by the cryptographic engine <b>110</b> using key <b>108</b>.

0115Referring now to <figref idref="DRAWINGS">FIG. 2B</figref> there is shown a flowchart <b>210</b> of a method for decrypting data in accordance with an embodiment of the present invention.

0116First, token <b>104</b> is received <b>212</b> by cryptographic module <b>102</b>. Next, key <b>108</b> is regenerated <b>214</b> using the first token <b>104</b> and KeyGen data <b>105</b> by key generator <b>106</b>. Then, the encrypted data <b>114</b> is decrypted <b>216</b> by the cryptographic engine <b>110</b> using key <b>108</b>.

0117Referring to <figref idref="DRAWINGS">FIG. 3</figref>, there is shown a block diagram of a system <b>300</b> in accordance with an additional embodiment of the present invention.

0118The system <b>300</b> includes a first cryptographic module <b>302</b> located at a first location and a second cryptographic module <b>303</b> located at a second location, with first cryptographic module <b>302</b> being in communication with second cryptographic module <b>303</b> by a communication channel <b>316</b> over which information is transmitted. The use of communication channel <b>316</b> is illustrative and not meant to be limiting. Those skilled in the art will recognize that two or more cryptographic modules may be capable of utilizing shared information, i.e. a token, encrypted/decrypted data files, etc, over a variety of network configurations. First cryptographic module <b>302</b> has the same cryptographic module components as the second cryptographic module <b>303</b>.

0119First cryptographic module <b>302</b> includes a first key generator <b>306</b> and KeyGen data <b>305</b> for reproducibly generating a first key <b>308</b> using token <b>304</b>. The first key <b>308</b> can be of variable length. The first key generator <b>306</b> can generate/regenerate an appropriate length first key <b>308</b> for a cryptographic algorithm that will use the first key <b>308</b>. Reproducibly generating the same symmetric key <b>308</b> means key <b>308</b> can be reproduced at different points in time and does not have to be maintained or stored after its use to encrypt or decrypt data.

0120First cryptographic module <b>302</b> also includes a first cryptographic engine <b>310</b> for encrypting and decrypting data. In this embodiment, first cryptographic engine <b>310</b> encrypts input plain data <b>312</b> using the first key <b>308</b> provided by the first key generator <b>306</b> into encrypted data <b>314</b>. The first cryptographic engine <b>310</b> may be, for example, a Triple-Data Encryption Standard (Triple-DES) engine algorithm, an Advanced Encryption Standard (AES) engine algorithm or any other symmetric encryption engine algorithm known in the art, whether that algorithm is known now or is developed at some point in the future. Once encrypted data <b>314</b> has been created, first key <b>308</b> may be deleted or otherwise not stored or saved.

0121Second cryptographic module <b>303</b> is substantially identical to the first cryptographic module <b>302</b> having a second key generator <b>318</b> and KeyGen data <b>305</b> for reproducibly generating a key and a second cryptographic engine <b>322</b> for encrypting and decrypting data. In this embodiment, the second cryptographic module <b>303</b> receives token <b>304</b> and encrypted data <b>314</b> across a communication channel or through accessing a shared media storage location <b>316</b>, which could be an open communication channel, such as the Internet, or a file server, or a Cloud storage service. Second key generator <b>318</b> uses token <b>304</b> and KeyGen data <b>305</b> to produce a second key <b>320</b>, which is identical to the first key <b>308</b>. Cryptographic engine <b>322</b> then decrypts encrypted data <b>314</b> using the second key <b>320</b> thereby producing an output plain data <b>324</b>, which is substantially identical to the original input plain data <b>312</b>.

0122While token <b>304</b> may be stored together with encrypted data <b>314</b>, there is no requirement that token <b>304</b> be stored with the encrypted data <b>314</b> or transmitted with the encrypted data <b>314</b>. However, there needs to be an association maintained between encrypted data <b>314</b> and token <b>304</b>.

0123This embodiment illustrates two cryptographic modules <b>302</b>, <b>303</b> configured to both encrypt and decrypt data while being located at two separate locations.

0124Referring now to <figref idref="DRAWINGS">FIG. 3A</figref>, there is shown a block diagram of the system <b>300</b> having multiple cryptographic modules along a time line. At the first time interval, t<b>1</b>, is the first cryptographic module <b>302</b>. At the second time interval, t<b>2</b>, is the second cryptographic module <b>303</b>. At the third time interval, t<b>3</b>, is the third cryptographic module <b>305</b>. All of the cryptographic modules have similar components for encryption and decryption, include a key generator, not shown, and KeyGen data <b>305</b> for use with the key generator, according to embodiments of the present invention. Each key generator utilizes at least two inputs, in this embodiment two inputs, KeyGen data and token <b>304</b>, to create a key <b>108</b> which is used during the encryption and decryption procedures. In this embodiment, token <b>304</b> is publicly available which KeyGen data <b>305</b> is kept secret.

0125At the first time interval, t<b>1</b>, first cryptographic module <b>302</b> receives token <b>304</b>. Since this is the initial use of token <b>304</b>, it is created, or generated by a token generator, not shown. First cryptographic module <b>302</b> also receives plain data <b>312</b>. Utilizing token <b>304</b> and KeyGen data <b>305</b>, first cryptographic module <b>302</b> encrypts plain data <b>312</b> into encrypted data <b>314</b>.

0126At the second time interval, t<b>2</b> encrypted data <b>314</b> and token <b>304</b> are provided to the second cryptographic module <b>303</b> across communication channel <b>316</b>. Encrypted data <b>314</b> and token <b>304</b> may be stored in a data storage device during the time between the first time interval, t<b>1</b>, and the second time interval, t<b>2</b>. Once encrypted data <b>314</b> and token <b>304</b> are received by the second encryption module <b>303</b>, token <b>304</b> and KeyGen data <b>305</b> are used in the process to decrypt encrypted data <b>314</b> into plain data <b>324</b>, which is substantially similar to plain data <b>312</b>.

0127If it is desired to decrypt encrypted data <b>314</b> at a third time interval, t<b>3</b>, encrypted data <b>314</b> and token <b>304</b> are provided to the third cryptographic module <b>305</b> across communication channel <b>316</b>. Encrypted data <b>314</b> and token <b>304</b> may be stored in a data storage device during the time between the first time interval, t<b>1</b>, and the third time interval, t<b>3</b>. Once encrypted data <b>314</b> and token <b>304</b> are received by the third encryption module <b>305</b>, token <b>304</b> and KeyGen data <b>305</b> are used in the process to decrypt encrypted data <b>314</b> into plain data <b>324</b>, which is substantially similar to plain data <b>312</b>.

0128Referring now to <figref idref="DRAWINGS">FIGS. 4A and 4B</figref> there is shown a flowchart <b>400</b> of a method in accordance with an embodiment of the present invention.

0129First, the first token <b>304</b> is received <b>402</b> by cryptographic module <b>302</b>. Token <b>304</b> may be generated, as set out above, if this is the token's initial use as input to the key generator <b>306</b>. If token <b>304</b> has previously been generated and stored in a storage device, cryptographic module <b>302</b> may receive token <b>304</b> from that storage device.

0130Next, the first key <b>308</b> is generated <b>404</b> using the first token <b>304</b> and KeyGen data <b>305</b> by the first key generator <b>306</b> as described in detail herein below.

0131Next, the input data <b>312</b> is encrypted <b>406</b> by the first cryptographic engine <b>310</b> using the first key <b>308</b>.

0132Next, the encrypted data <b>314</b> and token <b>304</b> are sent <b>408</b> over a communication channel or to a shared media storage location <b>316</b>, which is subsequently received or accessed by the second cryptographic module <b>303</b>. Next, the token <b>304</b> and encrypted data <b>314</b> are received <b>410</b> by the second cryptographic module <b>303</b>.

0133Next, the second key generator <b>318</b> generates <b>412</b> the second key <b>320</b>, which is substantially identical to the first key <b>308</b>, using the token <b>304</b> and KeyGen data <b>305</b>. The structure and operation of the second key generator <b>318</b> is substantially the same as the first key generator <b>306</b> which is described in detail herein below.

0134Finally, the encrypted data <b>314</b> is decrypted <b>414</b> by the second cryptographic engine <b>322</b> using the second key <b>320</b> thereby providing an output plain message <b>324</b> that is substantially the same as the input plain message <b>312</b>. The second cryptographic engine <b>322</b> is substantially the same in structure and operation as the encryption engine <b>310</b> as is the usual practice in conventional symmetric key systems.

0135Referring now to <figref idref="DRAWINGS">FIG. 6</figref>, there is shown a block diagram of an embodiment <b>600</b> of KeyGen data <b>105</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this embodiment, token <b>104</b> is the first input and KeyGen data <b>105</b> is the second input. Key generator <b>106</b> utilizes token <b>104</b> and KeyGen data <b>105</b> to create key <b>108</b> for encryption and decryption. Key generator <b>106</b> can have various embodiments include being a random number generator. Additional embodiments are set out below.

0136Referring now to <figref idref="DRAWINGS">FIG. 6A</figref>, there is shown a block diagram of an embodiment <b>600</b>A of KeyGen data <b>105</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this embodiment, KeyGen data <b>105</b> is a fixed string of data bits <b>602</b>. In this embodiment, the fixed string of data bits <b>602</b> would be used as a second input to a key generator <b>106</b>A along with the token <b>104</b> as the first input. The output of the key generator <b>106</b>A would be a random string of bits from which a set of those bits can be deterministically selected as the key <b>108</b> for encryption and decryption.

0137Referring now to <figref idref="DRAWINGS">FIG. 6B</figref>, there is shown a block diagram of an additional embodiment <b>600</b>B of KeyGen data <b>105</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this embodiment, KeyGen data <b>105</b> are bits <b>614</b> from an entropy space <b>612</b>. In operation, entropy bits <b>614</b> from the entropy space <b>612</b> are selected by key generator <b>106</b>B based on input from token <b>104</b> to create a second, reproducible string of random bits.

0138Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, there is shown a block diagram of an embodiment of key generator <b>106</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0139The key generator <b>106</b> includes an entropy bit string generator <b>702</b> for generating an entropy bit string <b>704</b>. The entropy bit string <b>704</b> is stored in an entropy space <b>706</b>. The entropy bit string <b>704</b> includes a large set of random digital information. It can be of variable size and variable content among different instantiations of the system. Its primary characteristic is that the content is completely random digital information (i.e. random 1's and 0's). Although the entropy space <b>706</b> must be static in any one instantiation of the system <b>100</b>, the entropy space <b>706</b> can take different forms in different instantiations of the system <b>100</b>. The random number generator <b>712</b> uses a pointer <b>708</b> to extract n bits from the entropy space <b>706</b>. To ensure a random selection of bits is chosen from the entropy space <b>706</b>, the random number generator <b>712</b> moves the pointer <b>708</b> to various locations in the entropy space <b>706</b> to fetch random bits.

0140In general, the random number generator <b>712</b> is a set of computer instructions whose execution sequence and output is dependent on the combination of the token <b>104</b> and the information contained in the entropy space <b>706</b>. There are numerous different forms this random number generator can take in terms of computer programming instructions to achieve the desired outcome of generating a key that cannot be derived by knowing only the token. Although the random number generator must be static in any one instantiation of the system, the random number generator can take different forms in different instantiations of the system.

0141The random number generator <b>712</b> receives the token <b>104</b>. The random number generator <b>712</b> generates the key <b>108</b> using the token <b>104</b> to calculate changes in the pointer <b>708</b> position to fetch random bits from the entropy space <b>706</b>. Further details of the random number generator <b>712</b> are described herein below with reference to <figref idref="DRAWINGS">FIG. 8</figref>.

0142Referring to <figref idref="DRAWINGS">FIG. 8</figref>, there is shown a block diagram of the random number generator <b>712</b> shown in <figref idref="DRAWINGS">FIG. 7</figref>. The random number generator <b>712</b> includes a step offset generator <b>802</b> that receives the token <b>104</b> and calculates a step <b>804</b>. The step <b>804</b> is a number generated from the token <b>104</b> (alternatively, it could be passed in as a parameter) that defines a length of each step taken in the entropy space <b>706</b> using the pointer <b>708</b>. The step <b>804</b> can be calculated using MOD arithmetic to be a number within the length of the entropy space <b>706</b>, although this approach should be considered as only one example of a choice for the step size for the sake of having an example solution.

0143The random number generator <b>712</b> also includes an offset determination module <b>806</b> for determining an offset <b>808</b> for moving the pointer <b>708</b> position in the entropy space <b>706</b>. This offset <b>808</b> could be used to modify the size of the step each time the pointer <b>708</b> is moved in the entropy space <b>706</b>. As an example, after the first fetching of bits from the entropy space <b>706</b>, each subsequent fetching of bits could use the bits just fetched in calculating an offset <b>808</b> to the next step <b>804</b> for moving the pointer <b>708</b> to various positions in the entropy space <b>706</b>. For instance, if the bits just fetched represent an even number, the offset <b>808</b> could be added to the step <b>804</b> for moving the pointer <b>708</b>. Alternatively, if the bits just fetched represent an odd number, the offset <b>808</b> could be subtracted to the step <b>804</b> for moving the pointer <b>708</b>.

0144The random number generator <b>712</b> also includes a fetching module <b>810</b> for fetching the n bits <b>711</b> using the pointer <b>708</b> generated from the step <b>804</b> and offset <b>808</b>. When all bits are fetched from the entropy space <b>706</b>, a number bit string <b>710</b> is produced, ultimately providing the key <b>108</b> based on the fetched n bits <b>711</b>.

0145Referring now to <figref idref="DRAWINGS">FIGS. 9A and 9B</figref> there is shown a flowchart <b>900</b> of a method for generating the key <b>108</b> in accordance with the embodiment of the present invention.

0146First, the entropy space <b>706</b> is generated <b>902</b>. Entropy space is based on entropy bit string <b>704</b> which may be generated from the Web site RANDOM.ORG ( ) or any other means for generating random numbers known in the art.

0147The token <b>104</b> is then input <b>904</b> to the random number generator <b>712</b>, where the step <b>804</b> and offset <b>808</b> are calculated <b>908</b>, <b>910</b>. Next, the pointer <b>708</b> in the entropy space <b>706</b> is moved <b>912</b> to pointer <b>708</b> plus step <b>804</b> plus offset <b>808</b>.

0148Next, n bits <b>711</b> from the entropy space <b>706</b> at the pointer <b>708</b> is fetched <b>914</b> and are appended <b>918</b> to the number bit string <b>710</b>.

0149Provided the number bit string is complete <b>920</b>, the number bit string <b>710</b> becomes the key <b>108</b> and the method is finished, otherwise execution returns to step <b>910</b>. In the disclosure, complete is defined by collecting at least enough bits for a key. If more bits are collected than the number needed for a key, the number bit string <b>710</b> would have to be translated into a key.

0150Referring now to <figref idref="DRAWINGS">FIG. 10</figref>, there is shown a block diagram of an additional embodiment of key generator <b>106</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>.

0151In this embodiment, key generator <b>106</b> is shown as a deterministic algorithm module <b>1002</b> using a symmetric algorithm <b>1004</b> for generating random numbers. Unlike traditional hardware and software-based random number generators, which cannot be used to reliably re-generate previously generated random numbers, the symmetric algorithm <b>1004</b> will generate and re-generate the same random number based on two input parameters, a token <b>104</b> and fixed, static KeyGen data <b>105</b> as the data input to the symmetric algorithm <b>1004</b>. Symmetric algorithm <b>1004</b> utilizes token <b>104</b> and KeyGen data <b>105</b> to create a random output <b>1006</b>, referred to as random_output_bits. This random output <b>1006</b> is then utilized to create key <b>108</b>. For example, deterministic algorithm module <b>1002</b> may select every 4^thor 5^thvalue from random output <b>1006</b> to create key <b>108</b>.

0152By utilizing token <b>104</b> in combination with KeyGen data <b>105</b>, the resulting random output <b>1006</b> is created in such a way that it is difficult to correlate the token <b>104</b> with the random output <b>1006</b> without knowing the intimate details of the deterministic algorithm module <b>1002</b>. This allows token <b>104</b> to be stored and shared in a non-secret manners (e.g., over a public network). With KeyGen data <b>105</b> being kept secret, the ability of an attacker to determine the encryption key from the corresponding token is rendered highly unlikely. Symmetric algorithm <b>1004</b> by be any type of standard encryption algorithm, such as the Triple-Data Encryption Standard (Triple-DES) or the Advanced Encryption Standard (AES).

0153Referring now to <figref idref="DRAWINGS">FIG. 11</figref>, there is shown a block diagram of an additional embodiment of key generator <b>106</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this embodiment, key generator <b>106</b> is configured to receive token <b>104</b> and KeyGen data <b>105</b> as previously discussed. Key generator <b>106</b> also receives a third input, referred to as bit mask data <b>1102</b>. The three inputs, e.g. token <b>104</b>, KeyGen data <b>105</b> and bit mask data <b>1102</b>, are utilized by key generator <b>106</b> to create reproducible key <b>108</b>.

0154In this embodiment, key generator <b>106</b> has a symmetric algorithm component <b>1104</b> that processes token <b>104</b> and KeyGen data <b>105</b>. The output <b>1108</b> thereof is processed in combination with bit mask data <b>1102</b> to further randomize key <b>108</b>.

0155In general, bit mask data <b>1102</b> is a set of bits that can be applied to another set of bits using a bit mask processing operation <b>1106</b>, such as exclusive-or (XOR) operation, other similar single operations, or an algorithm using multiple operations.

0156In this embodiment, bit mask processing <b>1106</b> utilizes an XOR operation. In operation, each bit of the original data is compared to a corresponding bit of the bit mask data <b>1102</b> in sequence. The XOR operation, as illustrated in <figref idref="DRAWINGS">FIG. 12</figref>, works as follows: <ul id="ul0001" list-style="none"><li id="ul0001-0001" num="0000"><ul id="ul0002" list-style="none"><li id="ul0002-0001" num="0157">If there is a 1 in the output data <b>1108</b> and a 1 in the bit mask, the result is a zero;</li><li id="ul0002-0002" num="0158">If there is a 0 in the output data <b>1108</b> and a 0 in the bit mask, the result is a zero;</li><li id="ul0002-0003" num="0159">If there is a 0 in the output data <b>1108</b> and a 1 in the bit mask, the result is a one; and</li><li id="ul0002-0004" num="0160">If there is a 1 in the output data <b>1108</b> and a 0 and the bitmaps, the result is a one.</li></ul></li></ul>

0161The addition of bit mask data <b>1102</b> in key generator <b>106</b> provides an additional source of randomness making it more difficult for an attacker to reverse engineer random number generator <b>106</b>. As with the previous embodiments, only one of the token <b>104</b>, KeyGen data <b>105</b> or bit mask data <b>1102</b> needs to be not publicly available, although the most secure configuration would minimize information that is publicly available. For example, as discussed, it may be optimal to enable the token <b>104</b> to be publicly available. In such a case, the most secure configuration would be to ensure the KeyGen data <b>105</b> and bit mask data <b>1102</b> were not publicly available.

0162Further, bit mask data <b>1102</b> may be created manually by a user or algorithmically by a piece of software or hardware by accessing some data. For example, a user could manually type in a long passphrase that is used directly as a bit mask itself (using the binary form of the characters entered). Alternatively, a piece of software or hardware could take a static, fixed data file, for example a picture, document, spreadsheet etc., as input and convert the data file algorithmically and deterministically into a bit mask <b>1110</b>. In this embodiment, for example, raw data <b>1112</b> is provided into data conversion algorithm <b>1114</b> where it is converted into bit mask data <b>1102</b> for use with bit mask processing.

0163Further, modification to token <b>104</b>, KeyGen data <b>105</b> and/or bit mask data <b>1102</b> can effectively create different keys <b>108</b>. By employing the bit mask data <b>1102</b>, system <b>100</b> increases security and provides an additional flexible system component that may be changed to achieve different random results. For example, an organization may use different bit masks for different types of data, e.g. emails, documents, spreadsheets etc. while maintaining the other elements of key generator <b>106</b> the same.

0164The use of a single bit mask data <b>1102</b> is illustrative. Those skilled in the art will recognize that multiple bit masks may be utilized and are within the scope of the present invention.

0165Referring now to <figref idref="DRAWINGS">FIG. 13</figref> there is shown a flowchart <b>1300</b> of a method for encrypting data in accordance with an embodiment of the present invention.

0166First, token <b>104</b> is received <b>1302</b> by cryptographic module <b>102</b>. Token <b>404</b> may be generated, as set out above, if this is the token's initial use as input to the key generator <b>106</b>. If token <b>104</b> has previously been generated and stored in a storage device, cryptographic module <b>102</b> may receive token <b>104</b> from that storage device.

0167Next, output <b>1108</b> is generated <b>1304</b> using token <b>104</b> and KeyGen <b>105</b> by symmetric algorithm <b>1104</b>. Bit mask data <b>1102</b> is then received <b>1306</b> and processed in combination with output <b>1108</b> by bit mask processing algorithm <b>1106</b> to generate <b>1308</b> key <b>108</b>.

0168Next, the input data <b>112</b> is encrypted <b>1310</b> into encrypted data <b>114</b> by the cryptographic engine <b>110</b> using key <b>108</b>.

0169Referring now to <figref idref="DRAWINGS">FIG. 14</figref>, there is shown a block diagram of an additional embodiment of key generator <b>106</b> shown in <figref idref="DRAWINGS">FIG. 1</figref>. In this embodiment, key generator <b>106</b> is configured to receive token <b>104</b> and KeyGen data <b>105</b> as previously discussed. Key generator <b>106</b> also receives a plurality of third inputs, referred to as bit mask data <b>1302</b>A, <b>1302</b>B and <b>1302</b>C. The inputs, e.g. token <b>104</b>, KeyGen data <b>105</b> and bit mask data <b>1302</b>, are utilized by key generator <b>106</b> to create reproducible key <b>108</b>.

0170In this embodiment, key generator <b>106</b> has a symmetric algorithm component <b>1104</b> that processes token <b>104</b> and KeyGen data <b>105</b>. The output <b>1308</b> thereof is processed in combination with bit mask data <b>1302</b> to further randomize key <b>108</b>.

0171In this embodiment, bit mask data has a plurality of individual bit mask data <b>1302</b>A, <b>1302</b>B, and <b>1302</b>C that are individually, sequentially applied to output <b>1308</b> using bit mask processing operations <b>1306</b>A, <b>1306</b>B and <b>1306</b>C, where each operation may be an exclusive-or (XOR) operation, other similar single operations, or an algorithm using multiple operations, including various logical operations.

0172This embodiment illustrates multiple bit masks being utilized with the present invention.

0173In an application of embodiments of the present invention, if multiple bit masks were used and one or more of the bit masks was purposely destroyed (non-recoverable or not used any longer), the result would be to render all of the information encrypted with keys generated using the destroyed bit mask(s) unrecoverable. This is referred to as digital shredding. It is also possible to achieve digital shredding by destroying other components of a deterministic algorithm module, not only bit masks; for example, the KeyGen data could be destroyed to also achieve digital shredding.

0174An efficient implementation of bit masks generated from data would be to generate the bit masks using a data conversion algorithm and then store the result of the conversion (e.g., in memory or in storage media) for use in the cryptographic module, rather than doing the conversion each time the cryptographic module is executed.

0175Further, it is also possible to create a multi-variable system employing multiple bit masks. For example, a service provider could offer the option for customers to create their own, personalized bit masks and the organization would use each specific customer's personalized bit mask when securing that customer's data. However, since the use of a personalized bit mask could be optional, the organization would apply an initial, global bit mask for all secure data, to ensure that data was properly secured even if the customer was not using the option to have a personalized bit mask.

0176After applying the global bit mask, the service provider could then apply the customer's personalized bit mask if the customer selected the option to do so. A customer who chose the option to use a personalized bit mask could delete their personalized bit mask and, in so doing, ensure that all data encrypted with keys generated using the personalize bit mask could not be reproduced—achieving personalized digital shredding, which could be highly valuable from a privacy perspective.

0177Referring to <figref idref="DRAWINGS">FIG. 15</figref>, an embodiment of the system is shown in operation performing file encryption. This embodiment provides a transparent system to encrypt/decrypt all files on a storage device using a unique encryption key for each file, without the need to store these encryption keys securely.

0178In operation, application <b>1510</b> sends a command to file system <b>1512</b> to save <b>1520</b> File <b>1530</b>. File system <b>1512</b> can be a command system such as an operating system. Application <b>1510</b> may be any application that creates or otherwise modifies a document, e-mail, spreadsheet, etc. Upon receiving the save command <b>1520</b>, a plain text version of File <b>1530</b> is provided to cryptographic module <b>1502</b>. Token <b>1504</b> is generated and is then utilized by cryptographic module <b>1502</b> to encrypt the plain text version of File <b>1530</b> to create an encrypted File <b>1524</b> as previously set out above. Encrypted File <b>1524</b> and token <b>1504</b> are provided <b>1532</b> to file system <b>1512</b> and stored <b>1534</b> in a storage device <b>1514</b>. Storage device <b>1514</b> may be any data storage device such as a local memory storage, a local file server, or an Internet-based cloud storage service provided by an independent third-party (e.g., Google, Microsoft, Amazon, . . . ), etc.

0179Referring to <figref idref="DRAWINGS">FIG. 16</figref>, the embodiment of the inventive system as shown in <figref idref="DRAWINGS">FIG. 15</figref>, is shown in operation performing file decryption. In operation, application <b>1510</b> sends a command to file system <b>1512</b> to open <b>1610</b> File <b>1530</b>. File system <b>1512</b> retrieves <b>1612</b> the encrypted File <b>1524</b> along with the related token <b>1504</b>. File system <b>1512</b> provides <b>1614</b> token <b>1504</b> and encrypted File <b>1524</b> to cryptographic module where encrypted File <b>1524</b> is decrypted as previously provided to create plain text File <b>1522</b>. Plain text File <b>1522</b> is then provided <b>1618</b> to file system <b>1512</b> where it is then provided <b>1620</b> to application <b>1510</b> for use.

0180Referring to <figref idref="DRAWINGS">FIG. 17</figref>, an embodiment of the inventive system is shown in operation within a one-to-many centralized service provider <b>1802</b> configuration. This configuration may be utilized when a centralized service provider desires to provide secure storage of data for a plurality of users of the service provider's services. For example, a centralized email provider <b>1802</b> may desire to provide secure storage of email messages on its servers.

0181In operation, users <b>1810</b>A, B and C create and save multiple email messages <b>1812</b>A, B and C that are routed to a service provider's email file server <b>1816</b>. These email messages <b>1812</b> are in a plain text version of the email message. A plain text version of email <b>1812</b> is a non-encrypted version of that file. File server <b>1816</b> provides each plain text email <b>1812</b> to a cryptographic module <b>1806</b> for processing. Cryptographic module <b>1806</b> is capable of encrypting and decrypting data as set out above. It may include two or more inputs, i.e. token, KeyGen data, bit mask data, with at least one input being publicly available and at least one input being not publicly available.

0182For each plain text email <b>1812</b>, a token <b>1804</b> is generated and is also provided cryptographic module <b>1806</b>. Each plain text email <b>1812</b> is encrypted into encrypted email <b>1824</b>, which are then stored in data storage <b>1820</b>. Token <b>1804</b> may also be stored in data storage <b>1820</b>. This example refers to a single email file server <b>1816</b>. This is illustrative and not meant to be limiting. Those skilled in the art will recognize that other network configurations are within the scope of the present invention.

0183Referring to <figref idref="DRAWINGS">FIG. 18</figref>, the embodiment of the system as shown in <figref idref="DRAWINGS">FIG. 18</figref> is illustrated in decryption operations.

0184In operation, when user's <b>1810</b>A, B and C desires to read an encrypted email message <b>1824</b>A, B and C, email service provider's email file server <b>1816</b> retrieves the encrypted version of email <b>1824</b> A, B and C and related token <b>1804</b> from data storage <b>1820</b>. Token <b>1804</b> and encrypted email <b>1824</b> are provided to cryptographic module <b>1806</b>. Encrypted email <b>1824</b> and token <b>1804</b> are processed resulting in plain text email <b>1824</b>A, B and C, which is substantially identical to the original plain text email <b>1812</b>. Plain text email <b>1824</b> is then provided to email file server <b>1816</b> allowing access by user <b>1810</b>.

0185In alternative embodiments, individual bit masks may be associated with each user <b>1810</b> through a personal data file, for example a deterministically calculated data file based off of a photograph of the individual. The individual bit masks may be used in combination with or separate from a global bit mask thereby providing provides additional security for an individual's data. In the event that an individual does not have an individual bit mask, only the global bit mask would be utilized.

0186Referring to <figref idref="DRAWINGS">FIG. 19</figref>, an embodiment of the inventive system is shown in operation within a many-to-many decentralized configuration. This configuration may be utilized when it is desired to provide secure documents to two or more users. For example, a banking system having multiple locations <b>2002</b>A, B and C may desire to provide secure information across its system.

0187In this embodiment, a banking system <b>2000</b> has a plurality of locations <b>2002</b>A, B and C, each being part of a communication network <b>2008</b>AB, BC and AC. This use of a communication network is illustrative and not meant to be limiting. Those skilled in the art will recognize that any suitable communication system capable of transmitting data is within the scope of the present invention.

0188Each location <b>2002</b>A, B and C has a cryptographic module <b>2004</b>A, B and C. Each cryptographic module <b>2004</b>A, B and C is structurally and functionally as previously discussed.

0189Further, each location <b>2002</b>A, B and C are in secured communication with shared storage <b>2006</b> which is configured to store encrypted data and token data. By having access to shared storage <b>2006</b>, each location <b>2002</b>A, B and C is capable of encrypting and decrypting the same data files across the communication network. While this embodiment utilizes a shared storage, this is illustrative and not meant to be limiting. Those skilled in the art will recognize that the encrypted data and token data may be transferred directly between the multiple locations without utilizing a storage device.

0190An application of the present invention would be to create a trusted computing system with tamper detection capabilities. By implementing embodiments of the present invention, if tampering is detected, the embodiment could be destroyed by destroying one or more of the inputs, i.e. token, KeyGen data, bit mask data for the embodiment. This destruction would minimize the chance of any secrets of the embodiment being determined by an attacker, which is highly valuable in many circumstances. If such a destruction occurred, one significant benefit of these embodiments is that the system could be reconstructed and all of the keys would be “recovered”. This is substantially different from a key storage approach where, if the key storage is destroyed for any reason (including purposely destroying it because of an attack), all of the keys are lost forever.

0191An additional application of the present invention would be to create a hot standby network. By implementing embodiments having at least two locations, the handling of encryption/decryption could be maintained across an “operational” and “hot standby” network. Because traditional approaches using stored keys makes it is almost impossible to guarantee compatibility for encryption/decryption across operational and hot standby networks, embodiments of the present invention allow additional functionality over the prior art.

An Example of the Method of Generating a Random Number

0192The example method presented below is an example of an algorithm for generating smaller random numbers, in according to embodiments of the present invention. To generate larger random numbers, the algorithm could be effectively the same, but the size of the ENTROPY_BIT_STRING would be increased and, instead of picking up 2 bits at a time (as in this example), a larger-scale algorithm could pick up a byte (or more) at a time from the ENTROPY_BIT_STRING.

0193This algorithm meets the requirements of being able to regenerate the same random number from a “TOKEN” (a separate number), but it would have to be “scaled up” to generate random, symmetric cryptographic keys, for example.

Variable Definitions

0194“ENTROPY_STRING”—the random string (array) of bits of length 2p.

0195“TOKEN”—a number used as input to the algorithm; typically, we expect the TOKEN to be generated by a regularly available pseudo-random number generator on operating systems and hardware.

0196“STEP”—a number generated from the random TOKEN (alternatively, it could be passed in as a parameter) that defines the length of each step taken in the ENTROPY_STRING; STEP is sized using MOD arithmetic to be a number within the first half of the length 2p.

0197“ES_POSITION”—defines the bit position in the ENTROPY_STRING.

0198“OFFSET”—used when walking through the ENTROPY_STRING picking up 2 bits at a time; also used to offset the next STEP into the ENTROPY_STRING (forward on even number loops and backward on odd number loops).

0199“NUMBER_LENGTH”—the number of bits in NUMBER_BIT_STRING.

0200“NUMBER_BIT_STRING”—a linear array of bits of length RN_LENGTH.

0201“LOOPS_MAXIMUM” AND “LOOPS_COUNTER” control the number of loops executed.

0202“ONE_TIME_SEED”—may also be referred to as a bit-mask and is entered at run-time as an 8-bit Hexadecimal number (for the purposes of this example algorithm, but it could be much longer, depending on the circumstances). The ONE_TIME_SEED may be Bit Mask as set out above, which may be provided, or directed to, or supplied with data from which a Bit Mask could be algorithmically, deterministically generated/regenerated.

Constants:

P=10.

0203For this example algorithm, ENTROPY_BIT_STRING is defined to 1024 bits long. Each row in the following list contains 128 random bits (in hexadecimal format), generated from the Web site RANDOM.ORG (https://www.random.org/bytes/). Although the presentation is in row format in this document for readability purposes only, the ENTROPY_BIT_STRING is a long, contiguous string of bits in software. <ul id="ul0003" list-style="none"><li id="ul0003-0001" num="0204">ENTROPY_BIT_STRING=</li><li id="ul0003-0002" num="0205">40 5f 3f88 2a55 41 52 df f3 4cf6 77 95 3a02 [1]</li><li id="ul0003-0003" num="0206">d1 31 16 0f fe 20 70 21 8c93 88 8e4e be 7a4b [2]</li><li id="ul0003-0004" num="0207">7f 0c 7f78 c1 51 c4 9d91 79 a1 05 04 8c e1 89 [3]</li><li id="ul0003-0005" num="0208">f9 dd 38 65 5c 55 8a 92 43 16 5b 64 2e 1d 46 e3 [4]</li><li id="ul0003-0006" num="0209">9c 2f 4d 4e 9d 15 fe 84 10 a5 a5 f3 94 b5 34 6e [5]</li><li id="ul0003-0007" num="0210">e2 77 4e 5b 25 26 57 7b bf c1 3a 92 a3 8d 3f b2 [6]</li><li id="ul0003-0008" num="0211">e4 44 8f 6e da 25 e4 9f c2 7b 0e fc d0 82 f2 93 [7]</li><li id="ul0003-0009" num="0212">aa c5 6b 52 9f b0 d5 58 53 8b 7b24 6b ae 86 eb [8]</li><li id="ul0003-0010" num="0213">NUMBER_LENGTH=8</li></ul>

0214For this example algorithm, numbers are generated having a length of 8 bits, but this could be any length, so long as it is divisible by 2 since 2 bits at a time are being picked up.

0215For numbers of a longer length, the size of the ENTROPY_BIT_STRING should also be increased (to increase the randomness) and, in such a case, the algorithm could be amended to pick up a byte (or more) at a time, rather than 2 bits at a time in this example algorithm.

Algorithm:

0000<ul id="ul0004" list-style="none"><li id="ul0004-0001" num="0216">INPUT→TOKEN</li><li id="ul0004-0002" num="0217">INPUT→ONE_TIME_SEED</li><li id="ul0004-0003" num="0218">STEP=TOKEN MOD 2p−1</li></ul>

0219This ensures the initial STEP is within the first half of the ENTROPY_BIT_STRING, although this is arbitrary. The STEP value could be any number between 0 and (2p−1) and the algorithm would work just fine. <ul id="ul0005" list-style="none"><li id="ul0005-0001" num="0220">LOOPS_MAXIMUM=NUMBER_LENGTH/2</li></ul>

0221This number is looped a number of times to pick up NUMBER_LENGTH bits since 2 bits at a time are being picked up. <ul id="ul0006" list-style="none"><li id="ul0006-0001" num="0222">LOOPS_COUNTER=0</li><li id="ul0006-0002" num="0223">OFFSET=0</li><li id="ul0006-0003" num="0224">ES_POSITION=0</li><li id="ul0006-0004" num="0225">LOOP START:</li><li id="ul0006-0005" num="0226">IF LOOPS_COUNTER IS ODD, THEN OFFSET=OFFSET*(−1)</li><li id="ul0006-0006" num="0227">ES_POSITION=ABS((ES_POSITION+STEP+OFFSET) MOD 2p)</li></ul>

0228Take the Absolute Value of the ES_POSITION to cover the boundary condition where the value calculated inside the brackets is negative <ul id="ul0007" list-style="none"><li id="ul0007-0001" num="0229">IF ES_POSITION=(2p−1) THEN</li><li id="ul0007-0002" num="0230">OFFSET=2 BITS AT ENTROPY_BIT_STRING[ES_POSITION] and ENTROPY_STRING[0] ELSE</li><li id="ul0007-0003" num="0231">OFFSET=2 BITS AT ENTROPY_BIT_STRING[ES_POSITION] and ENTROPY_STRING[ES_POSITION+1]</li><li id="ul0007-0004" num="0232">NUMBER_BIT_STRING[LOOPS_COUNTER*2]=2nd least significant bit in OFFSET</li><li id="ul0007-0005" num="0233">NUMBER_BIT_STRING[LOOPS_COUNTER*2+1]=least significant bit in OFFSET</li><li id="ul0007-0006" num="0234">IF (LOOPS_COUNTER*2+2) MOD 8=0 THEN</li><li id="ul0007-0007" num="0235">XOR(NUMBER_BIT_STRING[LOOPS_COUNTER-3)*2:LOOPS_COUNTER*2+1], ONE_TIME_SEED)</li></ul>

0236After every 8 bits are collected, XOR those 8 bits with the ONE_TIME_SEED <ul id="ul0008" list-style="none"><li id="ul0008-0001" num="0237">LOOPS_COUNTER=LOOPS_COUNTER+1</li><li id="ul0008-0002" num="0238">IF LOOPS_COUNTER&lt;LOOPS_MAXIMUM THEN GO TO “LOOP START”</li><li id="ul0008-0003" num="0239">FINISH:</li><li id="ul0008-0004" num="0240">RETURN(NUMBER_BIT_STRING)</li></ul>

0241When the loops are done, the NUMBER_BIT_STRING will be full of NUMBER_LENGTH random bits picked up from the ENTROPY_BIT_STRING and combined with the ONE_TIME_SEED to generate further randomness.

General System Description

0242The keys generated by the system can be reliably and precisely reproduced by the system using the same tokens. However, knowledge of a token will not allow someone to generate the associated key without access to each of the entropy space, the one-time seed, and the random number generator. In fact, someone with knowledge of any of these combinations of components will be unable to reproduce a key:

0000a) token, random number generator, and entropy space, or <br /> b) token, entropy space, one-time seed, or <br /> c) token, random number generator, one-time seed.

0243In other words, so long as one of the random number generator, entropy space, or one-time seed is kept secret, it is not possible to derive the key from the “token”. Ideally, the concept is to have the entropy space and random number generator be able to be known and the one-time seed be kept secret. This is the ideal configuration because the entropy space and the random number generator are static in nature (i.e., they could, in theory and in practice, be the same across multiple customer environments), whereas the one-time seed is only used once and is completely variable depending on the instance of use (meaning, the specific instantiation of a system).

0244Importantly, the system does not require external input (e.g., from a keyboard) at the time of generating or regenerating a key. Also important is the fact that the system does not (and likely cannot) require sources of entropy frequently or universally used in random number generation, such as time/date. The only required inputs to the random number generator are the token, the entropy space, and the one-time seed. With those inputs, the system will re-generate the same key as initially generated after the initial generation of the token.

0245Often, the current time/date, or some other variable that changes over time, is used to provide some randomness (or “entropy”) in the process of creating a computer-generated random number. Embodiments of the invention cannot use that type of input because doing so would make regenerating a key from a “token” impossible. A “token” and associated key created at time t<b>1</b> would not be possible to re-generate at a later time, t<b>2</b>, if the current time/date was used to create randomness in the random number generation process.

0246While it is possible to include additional parameters in the generation/re-generation process, there is no requirement to do so. For example, it could be possible to require additional input from a human to generate/regenerate the key. The main requirement of any such input(s), however, is that it/they would have to be identical on the initial generation of the key and all subsequent re-generation(s) of the key.

System Construction and Run-Time Usage

Time Zero:

02471) Construct random number generator—this is a set of computer programming instructions that uses the one-time seed, the entropy space, and the token as input. The execution of the random number generator is directly affected by each of the inputs, so that someone examining the computer programming instructions of the random number generator would be unable to determine a resulting key from a known token without also understanding both the entropy space and the one-time seed. <br /> 2) Construct entropy space—this is a large set of random data bits (1's and 0's). It could be constructed in any manner that delivers sufficient entropy. For example, it could be created by taking digital samples of a noisy environment and combining that digital sound information with other random digital data to produce an array of random 1's and 0's. This array can be of variable size, but it is static once created for a particular instantiation of a system. If the entropy space was not static after creation, it would be impossible to regenerate a key from a token. <br /> 3) Enter the one-time seed—this is a set of data that impacts how the random number generator executes. The one-time seed is used as an input to the random number generator during “Run Time”. The one-time seed is combined with bits “fetched” from the entropy space to generate further randomness. As discussed above, the on-time seed may be a Bit Mask as set out above, and

0248Bit Mask may be provided, or directed or supplied with data from which a Bit Mask could be algorithmically, deterministically generated/regenerated.

Run Time:

0249To initially generate a key: <br /> 1) Generate a random number representing the “token” using a computer program that generates random numbers of sufficient entropy. <br /> 2) Provide the token as an input to the random number generator, along with the entropy space and one-time seed. <br /> 3) With those inputs, the random number generator generates a random string of bits of a length required to represent the required key. The key can then be used as an appropriate symmetric key for an appropriate symmetric cryptography algorithm OR any other process that requires a truly random number of any length.

0250This approach requires no manual input at run-time to generate a random number that can be derived (re-generated) again by using the same random “token”. Similarly, it does not use traditional inputs for random number generation, such a time/date, to impart randomness into the process of specifically generating the key. (Note: Time/date, and other traditional inputs and approaches for generating random numbers, may be used to generate the random number represented by the token, but this number does not need to be regenerated, so there is no problem using traditional methods for random number generation to generate the token).

0251To regenerate a key from a known token:

00001) Provide the previously generated token as an input to the random number generator, along with the entropy space and one-time seed. <br /> 2) With those inputs, the random number generator generates a random string of bits of a length required to regenerate the key. The key can then be used as an appropriate symmetric key for an appropriate symmetric cryptography algorithm OR any other process that requires a truly random number of any length.

Various Applications of the Described Technology (Additional Embodiments

0252Knowledge of the token cannot enable derivation of the key without specific knowledge of the algorithm and each of its inputs to generate the key.

0253Further, the random number generator used to generate the key does not require human input or any newly entered, “secret” value input at the time of generating and regenerating the key.

0254The approach also does not depend on traditional inputs to create entropy in random number generators, such as time/date, at the time the key is generated/regenerated.

0255To reliably regenerate the key, the approach requires that the algorithm and all of the inputs, with the exception of the token, to the algorithm to generate/regenerate the key remain static (or “the same”) once the system is put in place.

0256Ultimately, the system enables the use of a token that can be publicly known and can be used to reliably and repeatedly derive a second random number (the key) that is not publicly known. Knowing the token gives no advantage to an attacker for determining the key.

Local Key Generation for Local Encryption & Regeneration for Local Decryption

0257A desktop computer, a server computer, a hardware security module (HSM), a mobile (phone) device/iPad, an Internet-of-Things (IoT) device, or any other device with processing capability (e.g., a computer-controlled car) can hold one or more of the following components to generate keys for encryption and regenerate keys for decryption of data: entropy bit string (EBS), bit string (BS), and bit mask (BM). In this concept, keys are used to encrypt data local to the device (desktop, server, mobile phone, IoT device, etc.). In this case, the data is not intended to be shared, so the only expectation is for the data to be decrypted and used on the local device. Note: the data may be stored off of the device, e.g., in the Cloud, but all encryption/decryption happens locally on the device.

0258The principle advantages of this approach to generating keys for local encryption and regenerating keys for local decryption are: <ul id="ul0009" list-style="none"><li id="ul0009-0001" num="0000"><ul id="ul0010" list-style="none"><li id="ul0010-0001" num="0259">Local encryption can be done with random keys that can be regenerated later for decryption.</li><li id="ul0010-0002" num="0260">Local encryption can be done without having to store keys (in memory, on disk, or anywhere else) for later decryption.</li><li id="ul0010-0003" num="0261">Note that not needing to store keys is really “sharing” keys across time. By not physically storing keys anywhere, we effectively can share keys forever. Physically stored keys always face physical constraints (e.g., an HSM containing stored keys cannot last forever).</li><li id="ul0010-0004" num="0262">Local encryption/decryption can be done with only symmetric cryptography, which should require less powerful and sophisticated computing capabilities compared to public-key cryptography</li><li id="ul0010-0005" num="0263">A separate TOKEN may be generated for any data to be encrypted, resulting in a unique/random key for each piece of encrypted data. Compared with:</li><li id="ul0010-0006" num="0264">Typically, desktop computers effectively encrypt data using a single cryptographic key for all encrypted objects.</li><li id="ul0010-0007" num="0265">Typically, it is challenging for operating servers to encrypt/decrypt data at rest because there is no ability for anyone to enter a password or other key-protection approach to “unlock” keys to make them available for encryption/decryption. Servers that do encrypt data almost always have a single key that encrypts/decrypts all data and this key is “unlocked” at system boot and held in memory thereafter; for example, database encryption.</li></ul></li></ul>

0266In cases where a single key is used for a period of time, there is a need to update/rotate that key to a new key. Key update/rotation is a highly complex activity that is entirely obviated when a different key is used for each piece of encrypted data. In a system that uses a different key for each piece of encrypted data, it is very easy to change the key on any piece of data simply by re-encrypting it.

0267An additional embodiment of the present invention is discussed below.

0268This embodiment incorporates randomness into its key generation process—the KeyGen_TOKEN may be a random number supplemented with some additional information bits. Although keys are algorithmically derived, they are random because a critical input (TOKEN) to the algorithm is random. The KeyGen_ENTROPY_BIT_STRING is another source of randomness, even though it is static. The KeyGen_BIT_MASK is another source of randomness—even if someone knows, the TOKEN, the ENTROPY_BIT_STRING, and the BIT_SELECTOR, they will still have no idea what the key should be without knowing the BIT_MASK.

0269Keys do not need to be stored. They are initially generated for encryption and re-generated, when needed, for decryption.

0270Keys are not re-used in any predictable manner, unlike all other cryptographic systems. If a key is ever re-used, it is purely by random chance in a very large “space” of chance.

0271If organizations do not want to share KeyGen elements directly, they can go through an intermediary, which can translate from one domain to another domain.

0272Flexibility regarding the content of the KeyGen elements and their level of confidentiality (from nothing to high).

0273The security in public-key cryptography (e.g., RSA, elliptic-curve) is based on complex math problems. It is believed that quantum computing will be able to solve those math problems, thereby rendering public-key cryptography ineffective. Symmetric cryptography, however, bases its security entirely on “randomness”. Therefore, symmetric cryptography is not subject to attacks like public-key cryptography and, as a result, symmetric cryptography will become increasingly more important as public-key cryptography loses its effectiveness. Scalable methods for sharing symmetric keys securely will become very important and highly valuable. Increasing the “randomness” factor in symmetric cryptography is very easy—simply increasing key lengths even a small amount substantially increases security.

0274There are two models for sharing KeyGen-based keys:

00001) Direct sharing, where two or more domains share all KeyGen elements, including BIT_MASKs. A piece of data encrypted in one domain can be directly decrypted in the other domain(s). In a Direct sharing system, there is a need to share all elements between each domain that wants to communicate securely. There are a wide variety of possible configurations based on the sharing or not of specific KeyGen elements. For example, two domains can share ENTROPY_BIT_STRINGs and BIT_SELECTORs, but have separate BIT_MASKs for their cross-domain encrypted data and their internal-only encrypted data. <br /> a. An example of where there are big advantages to this approach is in an “operational” and “hot standby” network (considered separate “domains” for these purposes). Since this embodiment does not store any keys, there is no need to synchronize cryptographic keys across an operational and hot stand-by network. This alone solves very significant hot standby issues in networks employing cryptography. <br /> 2) Intermediate sharing, where each domain shares all KeyGen elements with an Intermediary. The Intermediary, for example, can decrypt data encrypted by domain A and then re-encrypt the information with a key that can be regenerated for decryption by domain B. In this way, domain's A and B do not have to share any KeyGen elements directly, but yet they can still communicate securely through an Intermediary, which could be a software service on the Internet. <br /> a. Further, in Intermediate sharing, an organization can employ a set of KeyGen elements that is specifically and solely for the purpose of communicating with the Intermediary. Such a domain could use a separate set of KeyGen elements for generating/regenerating keys for its own internal use. A local intermediary service would convert from the internal KeyGen elements to the Intermediary KeyGen elements prior to sending sensitive data to the Intermediary for conversion to be delivered to one or more domains, which would themselves then convert from their local intermediaries to their internal KeyGen domains. <br /> i. In this “domain hopping” approach, data can be decrypted, analyzed and transformed prior to being passed on to the next domain. For example, a document could be translated to a different language meeting the needs of the next domain. The same document could be analyzed for sensitive information which does not match the classification (e.g., Top Secret information in a Secret document) and have that data redacted prior to passing it along. <br /> ii. BMs and other elements could be stored in HSMs so an intermediary would not have access to the detailed keying information it is using to provide its service. If decryption/encryption happen on the HSM entirely, the service could be prevented from seeing the keying information and the information itself. The intermediary service is ultimately just a centralized hub to receive, transform (without seeing anything confidential) and then redistribute secure information.

Authenticated Keygen Sharing & Recovery

0275The ability to recover encryption/decryption keys is a fundamental requirement. In this context, encryption of stored data is the focus, not encryption of data being transmitted, which is decrypted at the other end of the transmission and not stored.

0276Loss of access to keys used to encrypt stored data means loss of that data—forever. Therefore, all systems that encrypt stored data include a mechanism to be able to recover keys for decryption.

0277Key recovery is extremely difficult to do well without introducing vulnerabilities that undermine the entire encryption system. For example, in public key infrastructure (PKI) based systems, key pairs used for encryption are backed up in centralized, secure systems. In this approach, key pairs are recoverable, but the centralized key storage system represents an attack point from technical and social engineering perspectives. Much care needs to be taken around such a system.

0278Hardware security modules that store keys also have backup mechanisms. Although keys are not intended to be able to be extracted from an HSM, HSM vendors provide the ability to generate a “copy” of the keys in one HSM into one or more additional HSMs to ensure there is a backup/restore capability in case the “master HSM” becomes dysfunctional or is destroyed somehow.

0279Furthermore, for symmetric cryptography, HSMs store keys that are called “key encrypting keys” (KEKs). These keys are used to encrypt other symmetric keys that are actually used to secure data. Since the encrypting symmetric, sometimes referred to as “data encrypting keys” (DEKs), are encrypted with KEK's, and because KEKs can be backed up/restored, there is always a way to recover the DEKs.

0280Although these solutions can work from a technical perspective, they are complex and costly. For example, not all computing environments are amenable to HSMs or can afford the cost associated with HSMs. It is infeasible from a cost and management perspective to install an HSM on end-user computers and mobile devices to protect content stored locally.

0281It can be particularly difficult to keep an “operational” network in synchronization with a “hot stand-by”/“recovery” network when encryption is occurring, particularly with regard to ensuring that everything encrypted in the operation environment can be decrypted in the hot stand-by environment. This can be referred to as a “key synchronization problem”.

0282This embodiment is also highly valuable for secure communications across domains (or installed in a parallel, hot stand-by environment) in either a mediated or unmediated approach. In these situations, there is a need to share “KeyGen” elements in an authenticated and secure manner across domains and/or intermediaries.

0283However, the KeyGen approach eliminates the “key synchronization problem” because any keys generated in the operational environment can be easily re-generated in the hot stand-by environment. Other than having the same KeyGen elements in place (static), there is no need for any dynamic synchronization between an operational and hot stand-by domain.

0284In summary, there is a need to ensure that the appropriate elements of a KeyGen system must be authenticated on initial installation, recovery, and sharing.

0285In this context, the term “authenticated” means that the KeyGen elements are coming from a known, trusted source and that the elements are genuine—they are correct and they have integrity that can be verified.

0286There are a number of ways in which KeyGen elements can be authenticated and recoverable:

00001) The elements can be digitally signed by a known, trusted entity. Digitally signing KeyGen elements provides a verifier with the knowledge that the elements are coming from a trusted source and that they have integrity—nobody has altered them in even a minor way since they were created (which is incredibly important for recovery). <br /> 2) The elements can have an integrity check done through a symmetric cryptography-based Message Authentication Code (MAC). <br /> 3) The elements can be stored in a location that requires on-line authentication using digital certificates. Such an approach can be enhanced by employing an online encryption protocol, such as Transport Layer Security (TLS) or Secure Sockets Layer (SSL) to ensure that that delivered data has integrity. Of course, there is another benefit of ensuring that the transmission is secure/encrypted.

0287The above list of approaches can be used individually or in various combinations to achieve the goal of distributing secure, authenticated, and recoverable KeyGen elements.

0288This embodiment is flexible with regard to which element is kept secret. Any one of the KeyGen_ENTROPY_BIT_STRING, KeyGen_BIT_SELECTOR, or KeyGen_BIT_MASK elements can be the one secret in the system.

0289In this embodiment, a user of the KeyGen approach keeps the BM secret and the EBS and BS can be known (although not required—users can keep their EBS and BS secret, as well).

0290In such a situation, users can download authenticated copies of the EBS and BS from a trusted network location (e.g., an authenticated Web site or other Internet site) on system installation. At any later time, the user can download those same authenticated elements if they need to recover their KeyGen system.

0291Similarly, users wishing to share KeyGen elements can download the same authenticated elements from a trusted network location. These users can also download those elements again, at any time, if needed, to recover their KeyGen system.

0292Other approaches for distributing authenticated KeyGen elements are: <ul id="ul0011" list-style="none"><li id="ul0011-0001" num="0000"><ul id="ul0012" list-style="none"><li id="ul0012-0001" num="0293">Digitally signed attachments to email messages</li><li id="ul0012-0002" num="0294">Digitally signed files on a shared folder (e.g., FTP, Google Drive, . . . )</li><li id="ul0012-0003" num="0295">Signed elements in source code</li></ul></li></ul>

0296With respect to the KeyGen_BIT_SELECTOR element, there is a need to distribute that element in both authenticated, compiled form and “source code” form. The “source code” form is required for long-term recovery if the compiled form is no longer supported by the underlying operating system. In this case, a user of the system can write an alternate KeyGen_BIT_SELECTOR element in another programming language that replicates the functionality of the original KeyGen_BIT_SELECTOR.

0297Note that there is value in having each element authenticated, but there is also value in creating an authenticated “package” of elements so that users know they are getting the appropriate KeyGen “system” (since getting the correct keys requires all of the correct elements together) for either initial installation or recovery. An authenticated “package” would include individually signed/integrity elements together with a signature/integrity on all the elements put together.

0298Packages of elements could be put together with easy-to-remember names so that users would not be concerned about remembering each element individually.

0299KeyGen elements may also be distributed confidentially by using encryption. This may be less valuable than the authentication component because confidentiality can be achieved through transmission encryption. However, if there is a need, KeyGen elements could also be encrypted.

KeyGen Elements in HSMs

0300Some users of this embodiment will prefer to have the KeyGen elements housed and operating in a hardware security module. HSMs have never before been used to generate and regenerate keys from a “public TOKEN”, but there is no reason why the concept of an HSM cannot be applied to the KeyGen approach.

0301In the HSM model, authenticated KeyGen elements (per the prior concept) could be “loaded” into an HSM. These components would be loaded on initialization and then re-loaded if necessary in a recovery scenario.

0302An HSM can hold one or many of each element of the KeyGen approach.

0303For instance, an HSM could have a single KeyGen_ENTROPY_BIT_STRING and a single KeyGen_BIT_SELECTOR algorithm, but numerous KeyGen_BIT_MASKs with each BM corresponding to a domain with which the system connected to the HSM communicates securely. Alternatively, the system could have numerous EBS and BS elements, together with numerous BMs, to enable individual, secure communications with multiple domains, without those domains having to share any of the elements with anything other than the HSM.

0304In a preferred scenario, the EBS and BS components could be loaded into an HSM, with the authentication of those components being verified either outside the HSM or inside the HSM. The BMs could be entered manually into the HSM so that they would never be stored in the memory of any computer.

0305A main advantage of an HSM approach is to ensure that the generation and re-generation of cryptographic keys, and the use of those keys, would be done entirely inside the HSM, which is a secure environment that resists attack. When data needs to be decrypted, the data together with its associated KeyGen_TOKEN would be passed into the HSM.

0306Another advantage of an HSM approach is that the organization/system using a KeyGen system on an HSM does not actually need to know the KeyGen elements. When considered from this perspective, a central organization can distribute HSMs provisioned with full KeyGen systems to customers/partners and have confidential communications with those customers/partners, without those customers/partners needing to know the “secrets” (e.g., BM) required to generate/re-generate symmetric keys. This approach would be highly valuable in a financial network, such as SWIFT, that is a centralized organization communicating securely with thousands of organizations for executing financial transactions.

0000One-to-Many Security with Derived/Personalized KeyGen_BIT_MASKs

0307Numerous service providers deal with many external parties and store data for those external parties. For example, Google® Gmail® service has over 1 Billion users and each user has up to 15 GB of storage for emails. The email information stored in Gmail represents a treasure of information for hackers to access. However, encryption of stored data is difficult enough that Google only provides protection for emails while they are “in transit”.

0308If a service provider could easily provide “personalized” encryption of stored email messages, it would be valuable for their customers. By “personalized”, it is meant that no two customers would share the same single key or a small set of keys for encryption, but rather each person would have keys that are only used for their data. An ideal solution would involve a unique, “personalized” key for each piece of each user's data; in this case, a unique, “personalized” key for each email.

0309Embodiments of the present invention enable this type of solution very easily, including the capability to provide key recovery and key sharing across a worldwide domain like Gmail where a user could be anywhere in the world while traveling but still want access to their Gmail.

0310Embodiments of the present invention could be implemented having one or more EBSs and BSs, but with each user having their own BM. The BMs provide the “personalization” and make a direct attack on the data fruitless since discovering the key for one email does not provide any information to discover the key for another email. The “personalization” of encryption keys makes a “multi-tenant” environment, such as an e-mail server, secure and individualized.

0311The BMs could be derived from secret information on each user. For example, a service provider could combine answers to security questions (for authenticating the user) to form a “personalized” BM. The main proviso is that the BM could not change for the user once data is encrypted, or the BM could not be changed easily because doing so would mean that data encrypted under the old BM would still have to be decrypted with the old BM.

0312In this model, the service provider has a one to many relationship with its customers. There is no sharing of keys required because the service provider is doing all of the storage and releases data to its customers on their request, and this release can be done securely using TLS/SSL transmission security. The primary exposure of the data is when it is at rest on service provider's servers (insider/external threat).

0313For many services, like online email protocols, this solution is ideal for secure storage because the users do not store data on their local devices. All of the data is stored by the service provider. So, users do not need the capability to generate keys on their local devices.

0314Service providers could charge extra for this type of security. It enables their customers to have protection and compliance with regulations like general data protection regulations (GDPR).

0000One-to-Many Encryption of a Single Data Object Using Only Symmetric Cryptography with a Unique Key-Encrypting-Key for Each Party

0315There are many cases where encrypting a single object with a single key for access by multiple, distinct and trusted parties is valuable. For example, a centralized intermediary service (as defined earlier in this document) that communicates with multiple parties. Another example is a satellite system that has many secure communications with different customers/parties. A business or research collaboration, or military coalition is another example where one entity in the coalition wants to distribute a single object of information to all members of the coalition in a secure manner. A final example is a centralized organization for financial services like SWIFT.

0316Traditionally with public-key cryptography, if a single data object (e.g., an email) needed to be encrypted and decrypted by multiple, distinct, and trusted entities (e.g., the email recipients), the following process occurs:

0000a) A random symmetric key is generated (SK); <br /> b) SK is used to encrypt the data object; <br /> c) The public key for each entity is used to encrypt the SK. The SK can only be decrypted by the entities' corresponding private keys; <br /> d) The encrypted data is packaged together with the list of encrypted copies of SK; <br /> e) When an entity receives the encrypted package, it looks through the list of encrypted copies of SK to find its copy. The entity then decrypts its copy of SK using its private key; and <br /> f) The entity then uses SK to decrypt the data object.

0317This approach has been used for decades with numerous issues, such as: <ul id="ul0013" list-style="none"><li id="ul0013-0001" num="0000"><ul id="ul0014" list-style="none"><li id="ul0014-0001" num="0318">Entities have to make sure they have a backup copy of the private key stored in a secure place so that the backup can be recovered if the original private key is lost or destroyed somehow.</li><li id="ul0014-0002" num="0319">Entities have to have access to other users' public keys and know that those keys are trustworthy at the time of use.</li></ul></li></ul>

0320Another embodiment is to use KeyGen methods and systems of the embodiments of the invention to generate a single object that is encrypted for multiple, distinct, and trusted entities.

0321In this embodiment, the steps include:

00001) Generate a random symmetric key (KD); <br /> 2) Use KD to encrypt the data (ED); <br /> 3) Generate a Token (T<b>1</b>) for the Entity (E<b>1</b>) and then generate a random symmetric key (K<b>1</b>) using the “KeyGen elements” (space, algorithm, bitmask) associated with E<b>1</b>; <br /> 4) Use K<b>1</b> to encrypt KD-K<b>1</b>(KD); <br /> 5) Repeat steps 3) and 4) until there is a copy of KD (K<b>2</b>(KD), K<b>3</b>(KD), . . . ) encrypted for all entities (E<b>2</b>, E<b>3</b>, . . . ) that need it; <br /> 6) Assemble the set of encrypted keys (K<b>1</b>(KD), K<b>2</b>(KD), K<b>3</b>(KD), . . . ) together with the list of Tokens (T<b>1</b>, T<b>2</b>, T<b>3</b>, . . . ) and the encrypted data (ED) into a package and distribute it to all entities; and <br /> 7) Each entity finds its Token and associated encrypted key copy (Kx(KD)). It then generates a key using its Token to decrypt KD and then decrypts the data (ED) using KD.

0322This method of the embodiment of the invention: <ul id="ul0015" list-style="none"><li id="ul0015-0001" num="0000"><ul id="ul0016" list-style="none"><li id="ul0016-0001" num="0323">Uses only symmetric cryptography;</li><li id="ul0016-0002" num="0324">There are no keys stored anywhere except for encrypted copies of KD, and</li><li id="ul0016-0003" num="0325">The keys required to recover KD are regenerated when needed. This is unlike traditional Key-Encrypting-Keys (KEKs), which must be stored securely for as long as any data associated with the KEKs lives;</li><li id="ul0016-0004" num="0326">Different copies of KD could be encrypted using a different cryptographic algorithms, dependent on the capabilities of the entities receiving the encrypted object.</li></ul></li></ul>

0327The entities need to have a relationship with the entity doing the encryption, but do not need any relationships with each other.

Binding Data

0328This embodiment describes how to use symmetric cryptography to bind different data elements together. For example, there is little value in having data labels if the labels are not bound to data in a secure manner that preserves integrity. Symmetric cryptography, together with the use of Message Authentication Codes (MACs) or Message Digests (MDs), provides a capability to securely bind two or more data elements together.

0329Traditionally, the problem with using symmetric cryptography for broad binding of data related to scalability, key management and the secure sharing of symmetric keys.

0330This embodiment uses a public KeyGen_TOKEN to enable the regeneration of a symmetric key. This capability enables symmetric cryptography to be an applicable method to bind two or more data elements together with integrity.

0331End points can verify integrity, the server only can do a check prior to secure (TLS/SSL) delivery, or it can be done transparently to applications by a proxy checking before delivering securely (TLS/SSL).

Modifications and Variations

0332It is understood that various symmetric algorithms may be used in embodiments of the present invention, some of which being shown below.

0333Data Encryption Standard (DES): An encryption algorithm that encrypts data with a 56-bit, randomly generated symmetric key. DES is not a secure encryption algorithm and it was cracked many times. Data Encryption Standard (DES) was developed by IBM and the U.S. Government together. DES is a block encryption algorithm.

0334Data Encryption Standard XORed (DESX): DESX is a stronger variation of the DES encryption algorithm. In DESX, the input plain text is bitwise XORed with 64 bits of additional key material before encryption with DES and the output is also bitwise XORed with another 64 bits of key material.

0335Triple DES (3DES): Triple DES was developed from DES, uses a 64-bit key consisting of 56 effective key bits and 8 parity bits. In the Triple DES, DES encryption is applied three times to the plain text. The plain text is encrypted with key A, decrypted with key B, and encrypted again with key C. 3DES is a block encryption algorithm.

0336RC2 and RC5: Ronald Rivest (RSA Labs), developed these algorithms. They are block encryption algorithms with variable block and key sizes. It is difficult to break if the attacker does not know the original sizes when attempting to decrypt captured data.

0337RC4: A variable key-size stream cipher with byte-oriented operations. The algorithm is based on the use of a random permutation and is commonly used for the encryption of traffic to and from secure Web sites using the SSL protocol.

0338Advanced Encryption Standard (AES): Advanced Encryption Standard (AES) is a newer and stronger encryption standard, which uses the Rijndael algorithm developed by Joan Daemen and Vincent Rijmen of Belgium. AES is capable to use 128-bit, 192-bit, and 256-bit keys.

0339International Data Encryption Algorithm (IDEA): IDEA encryption algorithm is the European counterpart to the DES encryption algorithm. IDEA is a block cipher, designed by Dr. X. Lai and Professor J. Massey. It operates on a 64-bit plain text block and uses a 128-bit key. IDEA uses a total of eight rounds in which it XOR's, adds and multiplies four sub-blocks with each other, as well as six 16-bit sub-blocks of key material.

0340Blowfish: Blowfish is a symmetric block cipher, designed by Bruce Schneier. Blowfish has a 64-bit block size and a variable key length from 32 up to 448 bits. Bruce Schneier later created Twofish, which performs a similar function on 128-bit blocks.

0341CAST: CAST is an algorithm developed by Carlisle Adams and Stafford Tavares. CAST uses a 40-bit to 128-bit key.

0342Methods of the embodiment of the invention are performed using one or more hardware processors, executing processor-executable instructions causing the hardware processors to implement the processes described above. Computer executable instructions may be stored in processor-readable storage media such as floppy disks, hard disks, optical disks, Flash ROMS, non-volatile ROM, and RAM. A variety of processors, such as microprocessors, digital signal processors, and gate arrays, may be employed.

0343The system <b>100</b> of the embodiment of the invention may be implemented as any of a variety of suitable circuitry, such as one or more microprocessors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), discrete logic, software, hardware, firmware or any combinations thereof. When modules of the system <b>100</b> are implemented partially or entirely in software, the modules contain a memory device for storing software instructions in a suitable, non-transitory computer-readable storage medium, and software instructions are executed in hardware using one or more processors to perform the techniques of this disclosure.

0344As discussed above, the methods and systems of embodiments of the present invention provide numerous advantages, thus making network communications more secure.

0345It should be noted that methods and systems of the embodiments of the invention and encrypted and decrypted data streams described above are not, in any sense, abstract or intangible. Instead, the data is necessarily presented in a digital form and stored in a physical data-storage computer-readable medium, such as an electronic memory, mass-storage device, or other physical, tangible, data-storage device and medium. It should also be noted that the currently described data-processing and data-storage methods cannot be carried out manually by a human analyst, because of the complexity and vast numbers of intermediate results generated for processing and analysis of even quite modest amounts of data. Instead, the methods described herein are necessarily carried out by electronic computing systems having processors on electronically or magnetically stored data, with the results of the data processing and data analysis digitally stored in one or more tangible, physical, data-storage devices and media.

0346Although specific embodiments of the invention have been described in detail, it should be understood that the described embodiments are intended to be illustrative and not restrictive. Various changes and modifications of the embodiments shown in the drawings and described in the specification may be made within the scope of the following claims without departing from the scope of the invention in its broader aspect.

0347While preferred embodiments of the present inventive concept have been shown and disclosed herein, it will be obvious to those persons skilled in the art that such embodiments are presented by way of example only, and not as a limitation to the scope of the inventive concept. Variations, changes, and substitutions may occur or be suggested to those skilled in the art without departing from the intent, scope, and totality of this inventive concept. Such variations, changes, and substitutions may involve other features which are already known per se and which may be used instead of, in combination with, or in addition to features already disclosed herein. Accordingly, it is intended that this inventive concept be inclusive of such variations, changes, and substitutions, and by no means limited by the scope of the claims presented herein.