Patent Application
20190044697
In the last several decades, personal computers and other consumer computing devices, such has hand-held devices and smart phones, have become ubiquitous among the general public. As the proliferation of personal computers and other computing devices became prevalent, the usefulness of the computers and other computing devices was increased by interconnected communications between different computers/computing devices via various electronic networking communications systems. With the advent of the publicly accessible Internet and the establishment of the World Wide Web (WWW) for common communications between computers and/or other computing devices on the Internet, it became common for private identification and financial information to be transferred over the publicly accessible Internet. To ensure that the private information is not accessed by parties that are not intended to be privy to the private information, various encryption techniques have been applied to the private data being transferred over the Internet. As data storage has become accessible over networking technologies, including over the publicly accessible Internet, it has also become prudent to store sensitive data in an encrypted format.
Modern encryption employs mathematical techniques that manipulate positive integers or binary bits. Asymmetric encryption, such as RSA (Rivest-Shamir-Adleman), relies on number theoretic one-way functions that are predictably difficult to factor and can be made more difficult with an ever increasing size of the encryption keys. Symmetric encryption, such as DES (Data Encryption Standard) and AES (Advanced Encryption Standard), uses bit manipulations within registers to shuffle the cryptotext to increase “diffusion” as well as register based operations with a shared key to increase “confusion.” Diffusion and confusion are measures for the increase in statistical entropy on the data payload being transmitted. The concepts of diffusion and confusion in encryption are normally attributed as first being identified by Claude Shannon in the 1940s. Diffusion is generally thought of as complicating the mathematical process of generating unencrypted (plain text) data from the encrypted (cryptotext) data, thus, making it difficult to discover the encryption key of the encryption process by spreading the influence of each piece of the unencrypted (plain) data across several pieces of the encrypted (cryptotext) data. Consequently, an encryption system that has a high degree of diffusion will typically change several characters of the encrypted (cryptotext) data for the change of a single character in the unencrypted (plain) data making it difficult for an attacker to identify changes in the unencrypted (plain) data. Confusion is generally thought of as obscuring the relationship between the unencrypted (plain) data and the encrypted (cryptotext) data. Accordingly, an encryption system that has a high degree of confusion would entail a process that drastically changes the unencrypted (plain) data into the encrypted (cryptotext) data in a way that, even when an attacker knows the operation of the encryption method (such as the public standards of RSA, DES, and/or AES), it is still difficult to deduce the encryption key.
Homomorphic Encryption is a form of encryption that allows computations to be carried out on cipher text as it is encrypted without decrypting the cipher text that generates an encrypted result which, when decrypted, matches the result of operations performed on the unencrypted plaintext.
The word homomorphism comes from the ancient Greek language: óμóζ (homos) meaning “same” and μoρφ{tilde over (η)} (morphe) meaning “form” or “shape.” Homomorphism may have different definitions depending on the field of use. In mathematics, for example, homomorphism may be considered a transformation of a first set into a second set where the relationship between the elements of the first set are preserved in the relationship of the elements of the second set.
For instance, a map f between sets A and B is a homomorphism of A into B if
f(a1opa2)=f(a1)opf(a2)|a1,a2∈A
where “op” is the respective group operation defining the relationship between A and B.
More specifically, for abstract algebra, the term homomorphism may be a structure-preserving map between two algebraic structures such as groups, rings, or vector spaces. Isomorphisms, automorphisms, and endomorphisms are typically considered special types of homomorphisms. Among other more specific definitions of homomorphism, algebra homomorphism may be considered a homomorphism that preserves the algebra structure between two sets.
An embodiment of the present invention may comprise a method for performing homomorphic searching of an intermediary computing system that stores at least one cryptotext encrypted data representation of at least one corresponding plain text data value wherein the homomorphic search is initiated using a plaintext search data value without encrypting the plaintext search data value and without the intermediary computing device decrypting the at least one stored cryptotext encrypted data representation, the method comprising: distributing by at least one source computing device at least one numeric message data value (Mn) into coefficients of at least one corresponding message multivector (
An embodiment of the present invention may further comprise a method for encrypting a numeric message data value (M) on a source computing device in order to transfer a cryptotext multivector (
An embodiment of the present invention may further comprise a method for a search request computing device to request that an intermediary computing system perform a homomorphic search of cryptotext multivectors stored on the intermediary computing system, the method comprising: distributing by the search request computing device a search request numeric message data value (SR) into coefficients of a corresponding search request message multivector (
An embodiment of the present invention may further comprise a method for performing a homomorphic search of cryptotext multivectors stored on an intermediary computing system in response to a search request from a search request computing device, the method comprising: receiving by the intermediary computing system the at least one cryptotext multivector (
An embodiment of the present invention may further comprise a method for decrypting at least one cryptotext multivector (
An embodiment of the present invention may further comprise a homomorphic search Enhanced Data-Centric Encryption (EDCE) system for homomorphic searching of an intermediary computing system that stores at least one cryptotext encrypted data representation of at least one corresponding plain text data value wherein the homomorphic search is initiated using a plaintext search data value without encrypting the plaintext search data value and without the intermediary computing device decrypting the at least one stored cryptotext encrypted data representation, the homomorphic search EDCE system comprising: at least one source computing device, wherein each of the at least one source computing devices further comprises: a source numeric message distribution subsystem that distributes at least one numeric message data value (Mn) into coefficients of at least one corresponding message multivector (
An embodiment of the present invention may further comprise a homomorphic search Enhanced Data-Centric Encryption (EDCE) system source computing device for encrypting a numeric message data value (M) in order to transfer a cryptotext multivector (
An embodiment of the present invention may further comprise a homomorphic search Enhanced Data-Centric Encryption (EDCE) system search request computing device to request that an intermediary computing system perform a homomorphic search of cryptotext multivectors stored on the intermediary computing system, the homomorphic search EDCE system search request computing device comprising: a search request numeric message distribution subsystem that distributes a search request numeric message data value (SR) into coefficients of a corresponding search request message multivector (
An embodiment of the present invention may further comprise a homomorphic search Enhanced Data-Centric Encryption (EDCE) system intermediary computing system for performing a homomorphic search of cryptotext multivectors stored on the homomorphic search EDCE system intermediary computing system in response to a search request from a search request computing device, the homomorphic search EDCE system intermediary computing system comprising: an intermediary receive subsystem that receives the at least one cryptotext multivector (
An embodiment of the present invention may further comprise a homomorphic search Enhanced Data-Centric Encryption (EDCE) system destination computing device for decrypting at least one cryptotext multivector (
In the drawings,
Homomorphic Encryption is a form of encryption that allows computations to be carried out on cipher text as it is encrypted without decrypting the cipher text that generates an encrypted result which, when decrypted, matches the result of operations performed on the unencrypted plaintext.
The essential purpose of homomorphic encryption is to allow computation on encrypted data without decrypting the data in order to perform the computation. In this way, the encrypted data can remain confidential and secure while the encrypted data is processed for the desired computation. Accordingly, useful tasks may be accomplished on encrypted (i.e., confidential and secure) data residing in untrusted environments. In a world of distributed computation and heterogeneous networking, the ability to perform computations on encrypted data may be a highly desirable capability. Hence, finding a general method for computing on encrypted data is likely a highly desirable goal for cryptography.
The most sought after application of homomorphic encryption may be for cloud computing. Data that is stored in the Cloud is typically not encrypted, and the breach of the Cloud stored, unencrypted data is ranked by the Cloud Security Alliance as the number one threat to data security. Encrypting Cloud stored data may mitigate the threat of data being compromised by a breach, but then the remote clients (owners of the data) would not then be able to perform operations (i.e., add, multiply, etc.) on the Cloud stored data while the data remains in the Cloud. In order to perform operations on encrypted data stored in the Cloud, it would be necessary to download the encrypted Cloud stored data, decrypt the data, perform all desired operations on the data locally, encrypt the resulting data and send the resulting data back to the Cloud. Alternatively, if a user wants the Cloud services provider to perform the computations, the Cloud would require access to the user's encryption keys. It is becoming increasing undesirable to provide the Cloud access to a user's security keys as the more entities that have access to the security keys inherently increases the susceptibility of the security keys to being breached, or even stolen by an unscrupulous provider. Homomorphic encryption would allow the Cloud to operate on client data without decryption, and without access to the client's security keys.
An embodiment may advantageously utilize Geometric Algebra to provide the encryption and decryption of numeric messages that are to be transmitted through, and possibly have operations performed by, an intermediary computing system (e.g., the broad-based computing system currently, and commonly, referred to as the Cloud, or cloud computing). An embodiment of the Geometric Algebra encryption/decryption system that performs the foundational “core” encryption/decryption functions of transferring data securely using Geometric Algebra based encryption/decryption from a source system to a destination system without having arithmetic or other comparative operations performed on the transmitted encrypted data by an intermediary system may be referred to as an Enhanced Data-Centric Encryption (EDCE) system. When an EDCE system is further enhanced to support and provide for arithmetic and/or other comparative operations to be performed at an intermediary computing system (e.g., the Cloud) without decrypting and re-encrypting the data at the intermediary computing system, that system may be referred to as an Enhanced Data-Centric Homomorphic Encryption (EDCHE) system.
Geometric Algebra is an area of mathematics that describes the geometric interaction of vectors and other objects in a context intended to mathematically represent physical interactions of objects in the physical world. The use of Geometric Algebra for cryptography represents a new, manmade use of Geometric Algebra for a purpose entirely outside of the natural basis of Geometric Algebra for representing physical interactions of objects in the real, physical, word. As used herein, this area of mathematics encompasses Geometric Algebra, Conformal Geometric Algebra and Clifford Algebra (referred to collectively herein as “Geometric Algebra”). Generally, Geometric Algebra defines the operations, such as geometric product, inverses and identities, which facilitate many features of embodiments of the core EDCE and the EDCHE systems disclosed herein. Further, Geometric Algebra allows for the organization and representation of data into the “payload” of a multivector where the data in the payload may represent, for example, plaintext, cryptotext, or identifying signatures. Consequently, Embodiments of both the core EDCE system and the EDCHE system make beneficial use of Geometric Algebra properties to provide encryption, decryption, and intermediary homomorphic operations in a relatively computationally simplistic manner while still providing robust security for both data in motion and data at rest (e.g., data stored in the Cloud).
For an embodiment of an EDCHE system, methods and systems to encrypt and decrypt messages using Geometric Algebra may utilize the intrinsic algebraic homomorphic properties of Geometric Algebra to permit arithmetic and other comparative operations on encrypted messages handled by an intermediary computing system without the need for the intermediary computing system to decrypt the encrypted messages prior to performing the arithmetic and other comparative operations. Accordingly, the intermediary computing system does not need to know any information regarding any of the secret security keys of the encryption/decryption processes to properly perform the arithmetic and other comparative operations. The encrypted results of the arithmetic and other comparative operations performed by the intermediary computing system, when decrypted at a destination computing device, produce results equivalent to the same operations as if the operations were performed on the unencrypted plain text messages. To properly achieve the homomorphic effect for intermediary arithmetic and other comparative operations, a proper data organization methodology that preserves such homomorphic properties (i.e., the mathematical relationship between the vectors utilized in the encryption process and the original plaintext messages being encrypted) should be enforced on the choice of coefficients for the vectors representing the plain text messages. As discussed in more detail below, ensuring that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization methodology (i.e., a homomorphic preserving mathematical relationship) between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value will provide the proper data organization to preserve the homomorphic properties of the Geometric Algebra operations of the core EDCE encryption/decryption processes. Due to the use of the proper data organization, an embodiment of an EDCHE system provides a cryptosystem that allows unlimited multiplications and additions of cipher text (i.e., transmitted/stored encrypted messages at the intermediary/cloud computer system) due solely to the intrinsic algebraic homomorphic properties of an embodiment of the EDCHE system. Thus, an embodiment of an EDCHE system may provide the homomorphic properties as a product of algebraic homomorphism without the need to use additional methods, such as “bootstrapping” (e.g., performing a recursive operation to reduce the noise associated with a cipher text) to achieve the homomorphic properties.
The encrypted data values may be stored on the intermediary computing system until such time that particular arithmetic or other comparative operations are desired by a user, then the intermediary computing system may perform the requested arithmetic or other comparative operations. Likewise, the encrypted data values may be immediately operated on by the intermediary computing system as soon as the subject encrypted data values are received by the intermediary computing system. However, as one skilled in the art will recognize, the process of receiving the encrypted data values at the intermediary computing system inherently includes storing the encrypted data values at the intermediary computing system even if only fleetingly in an immediately used and erased Random Access Memory (RAM) location or operational register location of a computational subsystem of the intermediary computing system.
Embodiments of both EDCE and EDCHE may be comprised of functional blocks, each of which may be tailored as described in more detail below according to objectives for scope, capability and security. The following sections provide a mathematical and numerical description of these functional blocks.
In order to help minimize the potential confusion of the complex subject matter herein, the descriptions below have been split up to separately cover foundational “core” EDCE concepts and the additional enhancements concepts that permit homomorphic operations for EDCHE. In view of that, Section 1 provides a general description of embodiments of the foundational “core” EDCE system. Section 2 provides additional descriptions of embodiments of the foundational “core” EDCE system, including the packing of information into multivectors, the encryption and decryption of such multivectors and the unpacking to recover the original information. Section 3 provides a description of the further enhancements to embodiments of the foundational “core” EDCE system that achieve homomorphic properties for embodiments of an EDCHE system. Generally, in this description, as is the typical convention, for particular examples of operations, Alice and Bob are used for the sending/source and receiving/destination entities, respectively. Thus, the arrangement of the disclosure may be summarized as follows:
Section 1: General Core EDCE Message Encryption/Decryption
Section 2: Additional Descriptions of Core EDCE Message Encryption/Decryption
Section 3: Homomorphic EDCHE Enhancements to EDCE Operation
With the arrival of the internet and many forms of mobile devices, the volume of encrypted data is growing exponentially. Portable devices like “thumb drives,” “smart cards” and Solid State Disks (SSDs) contain both plain text and or encrypted “passive” data storage. Passive data storage is found on the tiny devices for the Internet of Things (IoT) as well as the large memories in server farms.
When data leaves storage, when it is in motion, it is even more vulnerable to attack. Current encryption techniques have not evolved alongside network security infrastructure and they are not well suited for the sheer volume of data in motion. As we move towards “cloud computing,” as mobile devices move us towards “perimeter-less” network security, the industry is moving away from trusting just the security of networks, servers or applications and focusing toward data-centric encryption. With data-centric encryption and authentication there are controls that are traveling with the data rather than just happening at the application layer or the final destination in a network.
However, the fluidity of this data in motion stalls with the computationally intensive mathematics that remain at the heart of current encryption infrastructures. Ciphers such as RSA (Rivest-Shamir-Adleman), DES (Data Encryption Standard) and/or AES (Advanced Encryption Standard) are little more than static “machinery” that bogs down communication efficiency. The actual problem is much bigger. How can robust security be provided when:
A “core” embodiment may be described as enhanced data-centric encryption, or EDCE. Compared to incumbent encryption schemes, EDCE is computationally simplistic while providing robust security over the span of the communication channel. EDCE security is scalable from tiny embedded IoT (Internet of Things) devices up to server farms. EDCE functionality enables many cipher schemes that show speed and bandwidth advantages over current methods. One aspect of EDCE that provides speed enhancement in the encryption/decryption of data is that the EDCE encryption/decryption may be implemented using basic arithmetic operations of addition, subtraction, multiplication, and division. Notably, EDCE does not require a complex operation to select a large prime number, to calculate a logarithm function, to calculate a natural logarithm function, and/or to calculate other complex and computationally intensive mathematical functions (i.e., prime numbers, logarithms, natural logarithms, and/or other complex mathematical operations are not required in the Geometric Algebra calculations disclosed herein).
A central feature of the various embodiments is the use of Geometric Algebra, an area of mathematics that has not been utilized before in encryption. Geometric Algebra as used herein is an area of mathematics that encompasses Geometric Algebra, Conformal Geometric Algebra and Clifford Algebra (collectively herein, “Geometric Algebra”). Geometric Algebra allows for the organization and representation of data into the “payload” of a multivector where the data may be plaintext, cryptotext, or signatures, for example. Geometric Algebra defines the operations, such as geometric product, inverses and identities, which are the enablers of encryption/decryption calculations of various embodiments.
Multivectors are simply the additive combination of a scalar, a vector, a bi-vector and so forth up to an n-dimension vector. However, the unit vectors follow the algebraic structure of quatemions (Hamilton) and non-commutative algebra (Grassman). These two types of algebra allowed Clifford to conceive of the Geometric Product which is used by the various embodiments as one of the “primitive” functions of the embodiments of EDCE and EDCHE systems.
An example of a two-dimension (2D) multivector Ā that includes a scalar and a vector is:
Ā=a
0
+a
1
ē
1
+a
2
ē
2
+a
12
ē
12
where ēi is a unit vector along the i-axis and ē12 represents the orientation of the area created by a12. The operations of Geometric Algebra on multivectors are discussed more fully in “Appendix A: Geometric Algebra Overview” of the parent patent application Ser. No. 15/667,325, entitled “Methods and Systems for Enhanced Data-Centric Encryption Systems Using Geometric Algebra,” but some general observations may be helpful to the description of the various embodiments disclosed below. First, each of the ai values in the multivector Ā above may be “packed” with information and each ai value may range from zero to very large (e.g., >256,000 bits or an entire message). Secondly, the inverse of Ā when multiplied by Ā yields unity, or:
ĀĀ
−1=1
Thus, if a second multivector
ĀĀ
−1
For the various embodiments, the “payload” may be packed in the values of the scalars and coefficients of the multivector elements. The packing method may define, among many things, the Geometric Algebra operations permissible for EDCE and/or EDCHE embodiments. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. As discussed in more detail below, the decryption methodology for EDCE and EDCHE systems utilize the inverse of the cryptotext multivector being decrypted and of the security key(s) multivector to perform the decryption. Therefore, the cryptotext multivector being decrypted should not have all equal value coefficients. One means to ensure that the cryptotext multivector being decrypted does not have all equal value coefficients is to have the packing/coefficient distribution method ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients) when creating the shared security multivector(s) and the data message multivectors. For an embodiment of the EDCE that simply transfers the data message, this will ensure that the cryptotext multivector to be decrypted will not have all equivalent coefficients. For an EDCHE system that may perform operations involving multiple encrypted data values, the same packing/coefficient distribution method to ensure that the source message multivectors do not have all equivalent coefficients will minimize the potential for the cryptotext multivector being decrypted from having all equivalent coefficients, but, when various addition and subtraction operations are performed with multiple distinctly different cryptotext multivectors, there is a remote possibility that the cryptotext multivector result of the homomorphic operations will have all equivalent coefficients. The destination computing device may simply assert that such a result cryptotext multivector is “undefined,” or, the destination or intermediary computing system may provide a means to update the result cryptotext multivector so the result cryptotext multivector does not have all equivalent coefficients. Great care should be taken to ensure that such an update of the result cryptotext multivector does not change the ultimate value of the result plaintext value of the result cryptotext multivector after decryption.
For embodiments that intend to retain homomorphic properties for encrypted data messages such as an embodiment of an EDCHE system, there is an additional restriction that the “packed” multivector that represents the original plaintext numeric message have a mathematical relationship (i.e., the homomorphic preserving mathematical relationship) to the original plaintext numeric message. In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value. The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway.
Additionally, separate multivectors may be encoded for many purposes, such as a shared secret (defined below), authentication information, and timestamps. In addition to the encryption and decryption of a message, the EDCE multivector format and Geometric Algebra foundation of a core EDCE embodiment may enable a single transmission to contain far more than just cryptotext, including dummy data to increase encryption security, command instructions for additional operations, and/or configuration data for the additional operations.
Further, as shown in
Various embodiments may implement the network/bus communications channel 104 using any communications channel 104 capable of transferring electronic data between the first 102 and second 106 computing devices. For instance, the network/bus communication connection 104 may be an Internet connection routed over one or more different communications channels during transmission from the first 102 to the second 106 computing devices. Likewise, the network/bus communication connection 104 may be an internal communications bus of a computing device, or even the internal bus of a processing or memory storage Integrated Circuit (IC) chip, such as a memory chip or a Central Processing Unit (CPU) chip. The network/bus communication channel 104 may utilize any medium capable of transmitting electronic data communications, including, but not limited to: wired communications, wireless electro-magnetic communications, fiber-optic cable communications, light/laser communications, sonic/sound communications, etc., and any combination thereof of the various communication channels.
The various embodiments may provide the control and management functions detailed herein via an application operating on the first 102 and/or second 106 computing devices. The first 102 and/or second 106 computing devices may each be a computer or computer system, or any other electronic device(s) capable of performing the communications and computations of an embodiment. The first 102 and second 104 computing devices may include, but are not limited to: a general-purpose computer, a laptop/portable computer, a tablet device, a smart phone, an industrial control computer, a data storage system controller, a CPU, a Graphical Processing Unit (GPU), an Application Specific Integrated Circuit (ASI), and/or a Field Programmable Gate Array (FPGA). Notably, the first 102 and second 106 computing devices may be the storage controller of a data storage media (e.g., the controller for a hard disk drive) such that data delivered to/from the data storage media is always encrypted so as to limit the ability of an attacker to ever have access to unencrypted data. Embodiments may be provided as a computer program product which may include a computer-readable, or machine-readable, medium having stored thereon instructions which may be used to program/operate a computer (or other electronic devices) or computer system to perform a process or processes in accordance with the various embodiments. The computer-readable medium may include, but is not limited to, hard disk drives, floppy diskettes, optical disks, Compact Disc Read-Only Memories (CD-ROMs), Digital Versatile Disc ROMS (DVD-ROMs), Universal Serial Bus (USB) memory sticks, magneto-optical disks, ROMs, random access memories (RAMs), Erasable Programmable ROMs (EPROMs), Electrically Erasable Programmable ROMs (EEPROMs), magnetic optical cards, flash memory, or other types of media/machine-readable medium suitable for storing electronic instructions. The computer program instructions may reside and operate on a single computer/electronic device or various portions may be spread over multiple computers/devices that comprise a computer system. Moreover, embodiments may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection, including both wired/cabled and wireless connections).
At process 208, the source 202 converts any alphanumeric text in the message into numeric message data (M) based on the alphanumeric encoding protocol (e.g., ASCII, other English language/alphabetic coding systems, foreign language encoding for non-alphabetic languages (e.g., katakana for Japanese), or even pure symbol to numeric values such as for emoji's) of the original text. Again, both the source 202 and destination 204 need to know and use the same alphanumeric text conversion into a numeric value process to ensure that results of both the source 202 and the destination 204 are the same. If the message data is already in numeric form, it is not necessary to perform process 208 as the original numeric message data (M) may be used as is. The various embodiments may perform the encryption process with numeric message data (M) that is, but is not limited to: positive numbers, negative numbers, zero, integer numbers, rational numbers (including fractions), and/or real numbers. At process 210, the source 202 distributes the numeric message data (M) into message multivector (
The distributing/packing method defines, among many things, the Geometric Algebra operations permissible for EDCE and/or EDCHE embodiments. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. As discussed in more detail below, the decryption methodology for EDCE and EDCHE systems utilize the inverse of the cryptotext multivector being decrypted and of the security key(s) multivector to perform the decryption. Therefore, the cryptotext multivector being decrypted should not have all equal value coefficients. One means to ensure that the cryptotext multivector being decrypted does not have all equal value coefficients is to have the packing/coefficient distribution method ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients) when creating the shared security multivector(s) and the data message multivectors. For an embodiment of the EDCE that simply transfers the data message, this will ensure that the cryptotext multivector to be decrypted will not have all equivalent coefficients. For an EDCHE system that may perform operations involving multiple encrypted data values, the same packing/coefficient distribution method to ensure that the source message multivectors do not have all equivalent coefficients will minimize the potential for the cryptotext multivector being decrypted from having all equivalent coefficients, but, when various addition and subtraction operations are performed with multiple distinctly different cryptotext multivectors, there is a remote possibility that the cryptotext multivector result of the homomorphic operations will have all equivalent coefficients. The destination computing device may simply assert that such a result cryptotext multivector is “undefined,” or, the destination or intermediary computing system may provide a means to update the result cryptotext multivector so the result cryptotext multivector does not have all equivalent coefficients. Great care should be taken to ensure that such an update of the result cryptotext multivector does not change the ultimate value of the result plaintext value of the result cryptotext multivector after decryption. Therefore, it may be desirable for the distribution/packing method to also ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients).
For embodiments that intend to retain homomorphic properties for encrypted data messages such as an embodiment of an EDCHE system, there is an additional restriction that the “packed” multivector that represents the original plaintext numeric message have a mathematical relationship (i.e., the homomorphic preserving mathematical relationship) to the original plaintext numeric message. In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value. The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway.
The restriction to retain homomorphic properties is only applicable to the distribution (i.e., “packing”) of the message multivector (
At process 214, the source 202 encrypts a cryptotext multivector (
Due to the nature of the geometric product operation of Geometric Algebra, there are many possible variations of the geometric product application that will provide similar degrees of confusion and diffusion. Some, but not all, of the potential geometric product calculations to encrypt the message data (M) include: a geometric product (
At process 220, the destination 204 receives the cryptotext numeric data (C) sent by the source 202. At process 222, the destination distributes the cryptotext numeric data (C) into the cryptotext multivector (
At process 304, the source computing device distributes the second shared secret key numeric value (SS
At process 306, the source computing device encrypts the cryptotext multivector (
At process 314, the destination computing device also distributes the second shared secret key numeric value (SS
At process 316, the destination computing device decrypts the cryptotext multivector (
At process 404, the source computing device distributes the second shared secret key numeric value (SS
At process 406, the source computing device encrypts the cryptotext multivector (
At process 408, in the process of the source computing device for converting the cryptotext multivector (
The remaining decryption process 226 of the destination 204 of
At process 416, the destination computing device also distributes the second shared secret key numeric value (SS
At process 416, the destination computing device decrypts the cryptotext multivector (
Additionally, while the flow charts and flow chart details described above with respect to
The disclosure below provides a simplified example of the operations and data relationships during the performance of a fundamental “core” EDCE embodiment. The amount of data, the type of data, and the particular data values shown and described in the example are not meant to represent any particular real system, but are provided only for the purpose of showing the operations and data relationships of an embodiment. Further, the embodiments described below are not meant to restrict operations to particular data types, encryption shared secret key exchange techniques, text to numeric and back conversion techniques, and/or number to multivector coefficient assignment techniques.
In addition to the utilization of the Geometric Algebra geometric product as a novel encryption primitive, the various embodiments may be comprised of functional blocks, each of which may be tailored as described according to objectives for scope, capability and security. The following sections provide a mathematical and numerical description of one or more example embodiments of these functional blocks. The numerical results in the examples are generally derived from Geometric Algebra executing in the C programming language.
For the example EDCE embodiment described herein, each text message needs to be converted to a number in order to become a valid operational unit for all EDCE computations. For the embodiments shown herein, the numbers are typically shown in base 10, but the various embodiments may choose other number bases as desired by the system designer. For instance, a hex (base 16) representation may provide particular advantages when dealing with ASCII numerical representations as standard ASCII has a representation based on the numbers 0-127 (i.e., 27), which is one power of two (i.e., hex is 28) less than the typical 8 bits represented by a hex number of xFF. According to the ASCII character-encoding scheme, symbols such as the letters a, b, c and so on, are represented in order formats (such as binary, decimal, octets, hexadecimal, etc.), which are described in the ASCII printable code chart, a table that presents the relationship between formats. So the letters “a,” “b” and “c” in ASCII decimal code are 97, 98 and 99, respectively.
As an example, assume that the plaintext text message is “message.” In ASCII decimal code, this is represented as follows:
With this relationship between symbols and decimal numbers, the conversion from text to number in base 10, using the text “message”, is executed as follows:
The variable n represents the final number of the conversion from text to number. We start defining this variable to zero. So, n=0.
Then we create an array with the ASCII decimal codes for each letter of the message:
This array has a size of 7 elements, thus array size=7
Then, for each value of the array of ASCII characters, in a loop, we will
For i=0; i<array_size; i++
Note the details of each iteration below:
By performing the above calculation, the final value of n is: 30792318992869221
Thus, the plain text “message” as a number in base 10 is equal to 30792318992869221. Once we have a base 10 number it is possible to perform the calculations described herein for message encryption. If desired, entropy may be added at this step by performing transformations on the ASCII codes, such as addition or modulo operations, but those entropy adding operations may affect whether intermediary homomorphic operations may properly be performed on the message data as those entropy adding operations may adversely affect the mathematical relationship to the original message values. No such entropy adding transformations are used in the examples that follow.
After performing various calculations, a base 10 number is transmitted and received. From the above example of a message multivector, the coefficients are concatenated to form a number string. The “number to text” conversion process for this number string also uses the ASCII printable code chart, but the recovery routine is different from the “text to number” conversion. The procedure is described below:
We start with the variable s, which is an empty string that will become the final text recovered from the input number. (Note: the symbol ““ ”” is from the C-language and means empty string)
s=“ ”
The input number is 30792318992869221.
n=30792318992869221
Now, we perform a loop until n is “emptied”, since this number refers to an actual text message. This means the loop will stop when n is equal to zero. In each loop iteration, we will recover, from the last to the first, each ASCII decimal code correspondent to the text that we are retrieving. To do that, we will perform a bitwise AND operation using the value 0xFF (which is 256-1 in hexadecimal format or in base 16). We will convert the code to character symbols and concatenate with the current string, always putting the most recent recovered character in the front of the string. Lastly, we will update the value of n by performing a right shift of 8 bits.
Let's say that the function “get_char” converts the ASCII decimal code to a character symbol.
The procedure is as follows:
while n>0
Note the details of each iteration below:
n=30792318992869221
while n>0
Thus, the number 30792318992869221 is converted to the text string “message,” which agrees with the original plaintext.
For the example embodiment discussed herein, any number in base 10 may be a coefficient of a multivector element. A multivector may contain arbitrary data, or data that is a result of a series of operations. A base 10 number may also be represented in multivector form by distributing pieces of this number string to the coefficients in the multivector. Multivectors that are 2D have 4 elements/coefficients available to pack with pieces of this number string, a 3D multivector has 8 elements, and 4D has 16. EDCE has been demonstrated up to at least 7D. A 4D multivector with 16 elements is written as:
Ā=a
0
+a
1
e
1
+a
2
e
2
+a
3
e
3
+a
4
e
4
+a
12
e
12
+a
13
e
13
+a
14
e
14
+a
23
e
23
+a
24
e
24
+a
34
e
34
+a
123
e
123
+a
124
e
124
+a
134
e
134
+a
234
e
234
+a
1234
e
1234
Given the base 10 number string 30792318992869221, this string may be a single coefficient of, say, a 2D multivector, as follows:
0+30792318992869221e1+e2+e12
EDCE has been demonstrated where the number string distributed to an element of the multivector exceeds 4,000 digits. However, the base 10 number in our example will typically be “distributed” in an ad hoc manner across all the multivector elements, such as:
30792+31899e1+28692e2+21e12
The above distribution is called “number to multivector.” For a core EDCE embodiment, the method of distributing the number string may be according to any of a variety of algorithms as long as the method is known and used by both the sending and receiving entities. To increase cryptographic “confusion,” the distribution algorithm may include shuffling of the assignments to elements, performing functional operations on numbers assigned to elements or changing the algorithm between messages in a conversation. More operations increase encryption entropy. However, it should be noted that shuffling and other algorithms to increase cryptographic confusion may break the potential for homomorphic operations by and EDCHE embodiment.
In order to ensure that the Geometric Algebra operations properly impart encryption security and also provide decryption capability, there are also some other rules that should be followed when performing the “number to multivector” process. For instance, the distributing/packing method defines, among many things, the Geometric Algebra operations permissible for EDCE and/or EDCHE embodiments. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. As discussed in more detail below, the decryption methodology for EDCE and EDCHE systems utilize the inverse of the cryptotext multivector being decrypted and of the security key(s) multivector to perform the decryption. Therefore, the cryptotext multivector being decrypted should not have all equal value coefficients. One means to ensure that the cryptotext multivector being decrypted does not have all equal value coefficients is to have the packing/coefficient distribution method ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients) when creating the shared security multivector(s) and the data message multivectors. For an embodiment of the EDCE that simply transfers the data message, this will ensure that the cryptotext multivector to be decrypted will not have all equivalent coefficients. For an EDCHE system that may perform operations involving multiple encrypted data values, the same packing/coefficient distribution method to ensure that the source message multivectors do not have all equivalent coefficients will minimize the potential for the cryptotext multivector being decrypted from having all equivalent coefficients, but, when various addition and subtraction operations are performed with multiple distinctly different cryptotext multivectors, there is a remote possibility that the cryptotext multivector result of the homomorphic operations will have all equivalent coefficients. The destination computing device may simply assert that such a result cryptotext multivector is “undefined,” or, the destination or intermediary computing system may provide a means to update the result cryptotext multivector so the result cryptotext multivector does not have all equivalent coefficients. Great care should be taken to ensure that such an update of the result cryptotext multivector does not change the ultimate value of the result plaintext value of the result cryptotext multivector after decryption.
The simple distribution method used in some of the core EDCE embodiment examples below is described as follows: Let the input base 10 number string=30792318992869221. We count the number of digits and determine that the number size is 17 digits. We then determine how to distribute these digits to the elements of a multivector. Considering a multivector of 2D, which has 4 elements, we apply the following equation:
Where ep is “each portion” length.
Now we have the original base 10 number and its size (17), the multivector structure (2D, 8 elements) and the length of each element (5). Now we need to “slice” the base 10 number in order to distribute each part as a coefficient of the new multivector.
Computationally, the procedure is as follows:
This creates the following multivector:
30792+31899e1+28692e2+21e12
Regardless of the method of distribution, the leading digit in any coefficient must be non-zero. For example, let the number to be converted to multivector be 30792318990869221. Applying the distribution method shown above would result in:
30792+31899e1+08692e2+21e12
Note the third element=08692e2. The computer will treat this number as 8692. When converting back from multivector to number, instead of 30,792,318,990,869,221 we would have 3,079,231,899,869,221, which is not the same number (commas added only for comparability).
To avoid this outcome, it is necessary to include verification in the algorithm that the first number of a coefficient is non-zero. If it is zero, this number should be placed as the last number in the coefficient of the previous element of the multivector. So, the correct result of the conversion of the number 30792318990869221 to a 2D multivector is:
30792+318990e1+8692e2+21e12
For embodiments that intend to retain homomorphic properties for encrypted data messages such as an embodiment of an EDCHE system, there is an additional restriction that the “packed” multivector that represents the original plaintext numeric message have a mathematical relationship (i.e., the homomorphic preserving mathematical relationship) to the original plaintext numeric message. In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value. The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway.
Additional and more detailed examples of homomorphism conserving “number to multivector” processes are described in more detail below in Section 3 that covers homomorphic searching EDCHE embodiments in more detail.
The simple distribution method used in some of the core EDCE embodiment examples below is described as follows:
For the simple distribution (i.e., “packing”) method disclosed above for parsing the string representation of a base 10 number to obtain the coefficient values, converting a multivector to a base 10 number is simply the reverse process of concatenating the coefficients of the multivector in order to form a base 10 number.
As an example: the multivector: 30792+31899e1+28692e2+21e12 becomes: 30792318992869221.
Note that in the core EDCE protocol of some of the example embodiments herein, only base 10 number strings are transmitted, not multivectors, but sending only base 10 number strings is not a requirement for an embodiment. In some embodiments, the number may be sent using a numeric variable representation such as an integer or floating point data type. Further, while not typical of most encryption systems, instead of sending a single cryptotext number (C), an embodiment may also simply skip the step of converting the multivector (
A “Shared Secret” is a fundamental element in cryptography. A Shared Secret enables secure communication between two or more parties. For the various embodiments the Shared Secret is a number string of digits that may be packed into a multivector in the manner shown above. The “Shared Secret Multivector” may be used to operate on other multivectors, such as creating the geometric product of the Shared Secret Multivector and the message multivector.
A variety of methods are already in practice to establish the Shared Secret between sources and destinations. As disclosed herein, the conversion of a “Shared Secret” number to a “Shared Secret Multivector” is completely novel. Communication end-point devices may be “pre-conditioned” with a unique identifier (number string) known only to the system administrators. In a public/private key environment such as RSA, the Shared Secret may be encrypted by the source using only the destination's public key. The method used in the examples below is the Diffie-Hellman key exchange protocol. This is a convenient, widely adopted method to establish a number string Shared Secret. However, any method that securely produces a shared number string is suitable for use with the various embodiments.
The Diffie-Hellman protocol uses the multiplicative group of integers modulo p (see, for example, https://en.wikipedia.org/wiki/Multiplicative_group_of integers_modulo_n), where p is prime (see, for example, https://en.wikipedia.org/wiki/Prime_number), and g is a primitive root modulo p (see, for example, https://en.wikipedia.org/wiki/Primitive_root_modulo_n and https://en.wikipedia.org/wiki/Modular_arithmetic). These two values are chosen in this way to ensure that the resulting shared secret can take on any value from 1 to p−1. A simple example of Diffie-Hellman follows:
S
A
0
=g
a mod p
S
B
0
=g
b mod p
and sends it to Alice.
Note that Diffie-Hellman protocol is not limited to negotiating a key shared by only two participants. Any number of users can take part in the agreement by performing iterations of the protocol and exchanging intermediate data.
Assume the following:
To compute SA0, Alice's public signature and SB0, Bob's public signature:
S
A
0
=g
a mod p
S
B
0
=g
b mod p
S
A
0=49009686585026240237091226039
S
B
0=286639204586849997936652161962
To compute the shared secret, both Alice and Bob will perform the following equation, which will generate the same value for both, thus the shared secret is reference as Ss:
S
s
=S
B
0
mod p
S
s
=S
A
0
mod p
S
s=374101092446920532886590141005
The shared secret number string above may be distributed as before to create a Shared Secret Multivector:
s=37410109+24469205e1+32886590e2+141005e12
In a similar manner the SA0 and SB0 number string for Alice and Bob can be distributed in a multivector format to create
The cryptotext is created using the EDCE primitive which is the geometric product of the Message multivector and one or more other multivectors. In the most basic form, the cryptotext multivector may be the geometric product of the Message multivector and the Shared Secret Multivector.
The procedure is defined as follows. Let the plaintext message be “this is a test.” By applying the “text to number” conversion, we will get the plaintext message as the number:
By applying the “number to multivector” conversion using a 2D multivector structure the plaintext multivector is:
Using the Shared Secret multivector that was determined above:
s=37410109+24469205e1+32886590e2+141005e12
The cryptotext multivector can be defined as the geometric product:
S
Using methods for calculating the geometric product of
In order to be transmitted, as a payload,
C
10=5649796324893205335999076139905242395250959838376115938268771181474
To increase the entropy of the Cryptotext Multivector, the Geometric Product of the Message Multivector may be taken with more than one other multivector or by using the same multivector twice to form a sandwich or by the addition of left and right multivector operations on the same Shared Secret Multivector. Two examples of these types are
Note that there are several alternative methods to construct the Cryptotext Multivector. One alternative is to encrypt the plaintext message using a conventional symmetric cipher such as AES, converting the number string output of that cipher to multivector format and use this multivector in calculating the geometric product with
Since Bob has the same shared secret of the source, he can open the cryptotext by performing a geometric product of the cryptotext multivector and the inverse of the shared secret multivector. When Bob receives C10, he will apply the appropriate number to multivector conversion to get:
To recover the plaintext multivector
S
−1
The method to determine
The multivector
M
10=2361031878030638688519054699098996
Finally, this number is converted to text using the “number to text” procedure described above, resulting in:
M
plain text=“this is a test”
Setup (502): The sequence is initiated by establishing the signature and shared secret multivectors. Here the Diffie-Hellman procedure 508 is shown but other asymmetric key ciphers such as RSA may be used to generate a number string known only to the source 504 and the destination 506. Alternatively, end-point devices may be “pre-conditioned” with a secret (number string) known to the system administrator from which the session multivectors may be constructed. The Diffie-Hillman procedure 508 sets up/creates the shared secret keys 510 and then the setup 502 creates multivectors of the Diffie-Hillman keys 510 in the multivector setup 512.
Source (504): The Message Multivector 516 is constructed at the create message operation 514 by concatenating the message ASCII code string to a number string and then distributing that number to the coefficients of the message multivector at 514. The method of distributing to coefficients uses a prescribed algorithm known and used by both the source 504 and the destination 506.
The Message Multivector 516 is then encrypted 518 by computing the geometric product of the message and Shared Secret multivectors.
Destination (506): C (532) is received through a user-defined operation 530 and converted back to the Cryptotext Multivector 536 using the prescribed distribution method 534. The destination 506 computes the multivector inverse of the Shared Secret Multivector and uses this result in the decrypt equations 538 such as
F. Symmetric Key Pair Encryption/Decryption from 0-Blade Reduction Operation (
In order to increase security to the Geometric Algebra encryption primitives, a pair of symmetric shared secret keys may be used instead of a single shared secret key. The following lists the processes that may be used to generate/extract/obtain the second shared secret multivector (
Primitive 1—“Sandwich”/Triple Product
Encryption
The first encryption primitive can be created through a sequence of geometric products using the pair of keys generated via the 0-Blade Reduction Operation (described herein, above) as follows:
S
S
Decryption
The decryption process uses the previously defined inverse multivector as follows:
S
−1
S
−1
Numerical Examples for Encryption and Decryption with Doubled Shared-Secret in 3 Dimensions
Let the message multivector
and the original secret multivector
S=29+22e1+31e2+28e3+23e12+17e13+20e23+215e123
From the original secret multivector
scalar=(
scalar=2281454761
Then create the second secret multivector
S
=22+81e1+45e2+47e3+61e12+0e13+0e23+0e123
In order to encrypt the multivector
S
S
and recover the message multivector
S
−1
S
−1
G. An Unbreakable Primitive Using Geometric Algebra and Arithmetic Functions Example with Secret Sharing and 3D Multivectors
Set Up
A multivector may act as a Geometric Algebra object such that components of multi-dimensions and Clifford k-vectors are present. An example is:
0
+a
1
ē
1
+a
2
ē
2
+a
3
ē
3
+a
12
ē
12
+a
23
ē
23
+a
31
ē
31
+a
123
ē
123
which shows the components:
A typical, but not the only, arithmetic function used for secret sharing is the Diffie-Hellman function, which is based on cyclic groups with element g; for example:
S
S
=g
ab mod p
where SS is a shared secret which can be used by both the source and destination sides and where the operation gab mod p yields SS. This is standard in the cyber security field.
Given a message M, distribute the numerical content of M over a multivector
M=m
1
,m
2
,m
3
. . . m
n
such that mi is a number that constitutes a placed integer value for a coefficient. Then:
0
+m
1
ē
1
+m
2
ē
2
+m
3
ē
3
+m
4
ē
12
+m
6
ē
23
+m
7
ē
123
Note that other multivector variations are also possible.
The shared secret SS is changed to a multivector in the same or a similar manner, such as:
S
S
=s
11
,s
12
,s
13
. . . s
1n
S
=s
10
+s
11
ē
1
+s
12
ē
2
+s
13
ē
3
+s
14
ē
12
+s
15
ē
13
+s
16
ē
23
+s
17
ē
123
An operation known as “0-Blade Reduction” creates a new scalar from
S
s
=(
Then SS
s
=s
20
+s
21
ē
1
+s
22
ē
2
+s
23
ē
3
+s
24
ē
12
+s
25
ē
13
+s
26
ē
23
+s
27
ē
123
Finally, the multivector-based “sandwich”/triple product equation may be used to create a cipher. Thus, the cryptotext multivector C is:
S
S
because Ss
Up to this point the encryption may have susceptibility to a pair of known cryptotext attacks. However, as shown in part below, the final unbreakability has been achieved.
Encryption Primitives with Unbreakable Cipher:
Primitive—“Sandwich”/Triple Product
Encryption
The first encryption primitive may be created through a sequence of geometric products using the pair of keys generated via the 0-Blade Reduction Operation (described above) as follows:
S
S
In order to add another layer of security to the cipher text
C=C′ XOR SS
Decryption
The decryption process may comprise the following steps:
C′=C XOR SS
S
−1
S
−1
Note that a solution for higher dimensions requires a different formula. Further note that if the original shared secret (SS) is generated using an encrypted/secure key exchange, such as, but not limited to the Diffie-Hellman process discussed in more detail herein, there is no transmission of the original shared secret multivector (
EDCHE is an extension to the EDCE cryptosystem described in more detail in Sections 1 and 2 above. The extension to support homomorphic operations requires additional considerations, particularly in the organization of the data message multivector coefficients, but, for the most part, the extension to support homomorphic operations relies on the intrinsic algebraic homomorphism of the Geometric Algebra foundation that are part of the encryption/decryption functions of the core EDCE. For instance, the Geometric Algebra geometric product operations that perform the actual encryption and decryption operations remain the same for both EDCE and EDCHE embodiments. The handling of the security keys also remains the same for both EDCE and EDCHE embodiments, including the data organization for “number to multivector” operations and any restrictions thereon. Likewise, any operations to convert text to a number and/or operations to convert a number also remain the same for both EDCE and EDCHE embodiments. The choice of whether or not to convert a cryptotext multivector (
Potential homomorphic encryption operations for an EDCHE embodiment may include multiple operations, such as, but not limited to: encrypted addition/subtraction, scalar addition/subtraction, encrypted multiplication, scalar multiplication, encrypted searching, and encrypted sorting. Each of the potential homomorphic encryption operations involves operations particular to the particular operation. For this reason, separate disclosures for each particular operation may be presented to so as to make the clear the specific details comprising the implementation of each particular operation. An additional document that briefly presents the combination of the potential homomorphic operations may also be separately presented that provides a brief summary of each operation and provides the additional details for performing combinations of the potential encryption operations. In view of potential disclosures, this particular disclosure is intended to address the specific details that comprise the particular details of homomorphic encryption searching operations.
The description of EDCHE below will typically use the term “source” for the entity (e.g., computing device/system) where numeric values that are to be available for homomorphic searches originate and “destination” for the entity (e.g., computing device/system) that receives the result of the homomorphic search operation. The term “intermediary” will typically define the “intermediate” entity acting in between the source(s) and destination on the encrypted numeric value operands originated at the source entity(ies). The term “search request” will typically define the “search request” entity commanding the “intermediary” entity to search the encrypted values stored by the “intermediary entity.” Alternatively, the term “client” may be used to describe the owner of the operand, the issuer of the search request, and/or the receiver of search result data (i.e., the source, search request, and/or destination computing device/system), while the generic term “cloud” may be used for data that is at rest in an untrusted environment (i.e., the intermediary computing system/device). In some respects, the terms “client” and “cloud” may more closely reflect a real-world application where the source, search request, and destination are the same entity, sending data to the intermediary “cloud” for storage, then requesting an operation (e.g., a search of stored data stored in encrypted format on the cloud) from the cloud when needed by the client. Ultimately, the terms source, destination, search request, and intermediary reflect the relative operations being performed by a computing system/device, and do not necessarily define the computing system/device as whole. Thus, the source, search request, destination, and intermediary operations/systems may reside as a particular application on one or more computing systems/devices. As the source, search request, destination, and intermediary computing systems/devices may be general-purpose computing systems capable of running multiple applications at the same time, it is inherently possible that the source, search request, destination, and intermediary operations are encapsulated as separate applications/functions that may permit, one, two, three, or all of the separate applications/functions to run on a single computing device/system. Also, a single interconnected computer system of a single owner/client may have untrusted environments that include data that is at rest (i.e., stored) in the owner/client's own end-point devices outside of the owner/client's digital secure perimeter such that it is beneficial to store the data in the untrusted environment of a single computing system in encrypted format even though other environments on the same computer system/device may properly handle secured information in unencrypted format.
To assist the reader in locating information, the arrangement of the remainder of the Section 3 disclosure below may be summarized as follows:
In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” (i.e., distributed) into multivector coefficient elements should necessarily maintain some mathematical representation of the original number. Consequently, the packing/distribution method may define, among many things, the Geometric Algebra operations permissible for an EDCHE embodiment. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. As discussed in Sections 1 and 2 above, the decryption methodology for EDCE and EDCHE systems utilize the inverse of the cryptotext multivector being decrypted and of the security key(s) multivector to perform the decryption. Therefore, the cryptotext multivector being decrypted should not have all equal value coefficients. One means to ensure that the cryptotext multivector being decrypted does not have all equal value coefficients is to have the packing/coefficient distribution method ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients) when creating the shared security multivector(s) and the data message multivectors. For an embodiment of the EDCE that simply transfers the data message, this will ensure that the cryptotext multivector to be decrypted will not have all equivalent coefficients. For an EDCHE system that may perform operations involving multiple encrypted data values, the same packing/coefficient distribution method to ensure that the source message multivectors do not have all equivalent coefficients will minimize the potential for the cryptotext multivector being decrypted from having all equivalent coefficients.
For an embodiment of an EDCHE system, the methods and systems that encrypt and decrypt messages using Geometric Algebra may utilize the intrinsic algebraic homomorphic properties of Geometric Algebra to permit arithmetic and other comparative operations on encrypted messages handled by an intermediary computing system without the need for the intermediary computing system to decrypt the encrypted messages prior to performing the arithmetic and other comparative operations. Accordingly, the intermediary computing system does not need to know any information regarding any of the secret security keys of the encryption/decryption processes to properly perform the arithmetic and other comparative operations. The encrypted results of the arithmetic and other comparative operations performed by the intermediary computing system, when decrypted at a destination computing device, produce results equivalent to the same operations as if the operations were performed on the unencrypted plain text messages. In order to properly achieve the homomorphic effect for intermediary arithmetic and other comparative operations, a proper data organization methodology (i.e., packing/distributing coefficients into a multivector) that preserves such homomorphic properties (i.e., the mathematical relationship between the vectors utilized in the encryption process and the original plaintext messages being encrypted) should be enforced on the choice of coefficients for the vectors representing the plain text messages. Homomorphism in the EDCHE is built upon the commutative nature of the Geometric Algebra operations of the encryption and decryption principles described above in Sections 1 and 2 for EDCE embodiments. Therefore, the distribution/packing data arrangement should also preserve a commutative mathematical relationship to the original numeric value being encrypted. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value (i.e., the homomorphic preserving mathematical relationship). The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway. Ensuring that the coefficients of the vector representation of the plaintext numeric message meet the above described definition of the homomorphic preserving mathematical relationship will provide the proper commutative data organization (i.e., packing/distributing) methodology that preserves the homomorphic properties of the Geometric Algebra operations of the core EDCE encryption/decryption processes. Due to the use of the proper commutative data organization, an embodiment of an EDCHE system provides a cryptosystem that allows unlimited multiplications and additions of cipher text (i.e., transmitted/stored encrypted messages at the intermediary/cloud computer system) due solely to the intrinsic algebraic homomorphic properties of an embodiment of the EDCHE system. Thus, an embodiment of an EDCHE system may provide the homomorphic properties as a product of algebraic homomorphism without the need to use additional methods, such as “bootstrapping” (e.g., performing a recursive operation to reduce the noise associated with a cipher text) to achieve the homomorphic properties.
B. Number to Multivector that Supports Homomorphism
As described above, in order to preserve homomorphism, a “number to multivector” paradigm where the “packed” multivector that represents the original plaintext numeric message has a mathematical relationship (i.e., the homomorphic preserving mathematical relationship) to the original plaintext numeric message preserves the homomorphic characteristics of the Geometric Algebra operations of EDCE encryption/decryption operations. In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value. The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway. For an example three dimensional multivector there are eight possible coefficients in the multivector representation (i.e., c0, c1, c2, c3, c12, c13, c23, and c123, numbered so as to correspond with the unit vector associated with each coefficient). In an example homomorphic preserving mathematical relationship that includes both addition and subtraction, if the coefficients for the e2 and e12 unit vectors (i.e., c2 and c12) are subtracted in the calculation of the homomorphic preserving mathematical relationship for a first numeric data message conversion to a multivector, all other numeric messages converted to a message vector should also ensure that the c2 and c12 coefficients are subtracted in the conversion homomorphic preserving mathematical relationship process. Likewise, when converting a multivector into a numeric value, the homomorphic preserving mathematical relationship process should also retain the subtraction of the c2 and c12 coefficients. Other than the location of additions and subtractions within the homomorphic preserving mathematical relationship of the coefficients, the actual values of the coefficients may be selected as desired by a user so long as the homomorphic preserving mathematical relationship equals the original numeric value being encrypted. The only other restriction for multivectors representing different numeric values within a homomorphic operation is that the multivectors all share the same dimensionality (i.e., all multivectors are 2D, all multivectors are 3D, all multivectors 4D, etc.). One skilled in the art will recognize that there are many, perhaps even an infinite, number of ways to select coefficient values that meet the stated criteria/restrictions and that each of those ways will create a satisfactory EDCHE embodiment so long as the stated criteria/restrictions are, in fact, met.
Some processes are common within each multivector coefficient selection process. For instance, the first step in representing a numeric message value in a multivector is to define the number of coefficients that are present in the multivector. The total number of coefficient elements of a multivector is directly related to the dimensionality of the multivector by the equation n=2m where n is the total number of coefficient elements and m is equal to the dimensionality of the multivector (e.g., for a 3D multivector n=23=8). Thus, in order to represent the numeric message N in a 3D multivector, the total number of coefficient elements to be determined is eight.
The coefficient selections may encompass any number that may be represented in the data type chosen by a system designer to hold the coefficient values, including, but not limited to: positive numbers, negative numbers, zero, integer numbers, rational numbers (including fractions), and/or real numbers. As a base of understanding, the format of a multivector will always assume that the coefficients add together. For instance, the form for a 3D multivector representing the numeric value N would be:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
Subtractions would be represented as negative coefficients. This “form” of the multivector coefficients adding together would remain consistent regardless of whether or not the corresponding coefficient is added or subtracted in the homomorphic preserving mathematical relationship between the original numeric value and the coefficients of the representative multivector.
Below are several examples of processes to automate or otherwise demonstrate methodology for the selection of coefficient values for a message multivectors that represents a numeric message value N. One skilled in the art will again recognize that many ways to select the coefficient values that meet the stated criteria/restrictions and that embodiments are not limited to the example methodologies described herein.
In this first example, the EDCHE embodiment performs the homomorphic preserving mathematical relationship process such that all coefficients are added together and there are not any coefficients that are subtracted. A first step might be to factorize the numeric message N and write the value N as a sum of other numbers (ci) that are to represent the numeric message value in a message multivector such that:
where n is the number of elements in the multivector as determined by n=2m where m is the dimension of the multivector. (e.g., n=8 for a 3D multivector). One skilled in the art will recognize that at this point there are many ways to assign the coefficient values (c) that will satisfy the homomorphic preserving mathematical relationship equation to enable proper operation of an EDCHE embodiment. One such method might be to perform an integer division of N by the number of elements n. Given the numeric value N=5487 and a 3D multivector where n=8, the result is 5487 integer division by 8, which is equal to 685. The remainder may be obtained by calculating N mod n (i.e., 5487 mod 8), which may be added to the last coefficient, resulting in a last coefficient value (i.e., c123) of 685+7, which equals 692. The sum may then be written as:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
5487=685+685+685+685+685+685+685+692
and the resulting multivector representing the numeric value N would be:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13 e13+c23e23+c123e123
multivector N=685+685e1+685e2+685e3+685e12+685e13+685e23+692e123
The assignment of which coefficient value receives the addition of the N mod n operation may be random, or the assignment may be of a predetermined form designed to increase entropy to enhance the encryption security.
In the case where the numeric value is divisible by the number of coefficient elements n of the message multivector (i.e., N mod n=0 such that all ci are equal, which is not permitted for proper decryption operation), a number less than the value of one coefficient element (e.g., c13) may be subtracted from that coefficient element (e.g., again c13) and added to another coefficient element (e.g., c23). For example, given N=2944 for a 3D multivector where n=8, 2944 may be integer divided by 8 to equal 386 with no remainder. An embodiment may then simply subtract one from c13 and add one to c23 to ensure that not all coefficient elements are equal such that the homomorphic preserving mathematical relationship may then be written as:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
2944=368+368+368+368+368+367+369+368
and the resulting multivector representing the numeric value N would be:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
multivector N=368+368e1+368e2+368e3+368e12+367e13+369e23+368e123
As with the first example, the EDCHE embodiment performs the homomorphic preserving mathematical relationship process such that all coefficients are added together and there are not any coefficients that are subtracted. Thus, for a 3D multivector with coefficients c0, c1, c2, c3, c12, c13, c23, and c123, where the coefficients are numbered so as to correspond with the unit vector associated with each coefficient, the homomorphic preserving mathematical relationship equation to represent the numeric value N would, again, be:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
Instead of having a strict equation to follow, an algorithm that randomly finds integers that satisfy the sum of integers equation may be created. To ensure that the coefficients add up to the numeric value N, the random number for each coefficient element may be serially (i.e., successively) calculated with the random number restricted to be some amount less than the remaining sum in order to achieve the numeric value N until the last coefficient value calculated is set equal to the remaining amount in order to achieve the numeric value N. For such a random number based system, given that N is again 5487, the homomorphic preserving mathematical relationship may be written as:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
5487=385+985+685+584+786+482+887+693
and the resulting multivector representing the numeric value N would be:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13 e13+c23e23+c123e123
multivector N=385+985e1+685e2+584e3+786e12+482e13+887e23+693e123
Unlike the first two examples, in this third example the homomorphic preserving mathematical relationship equation that is set equal to the numeric value N may be defined to include some subtraction of some coefficients, addition of a constant value, and multiplication of coefficient values by a constant, as well as the omission of one of the coefficients (i.e., c123) from the homomorphic preserving mathematical relationship. In this third example, the homomorphic preserving mathematical relationship equation to represent the numeric value N might now be:
N=c
0
+c
1
−c
2
+c
3
−c
12+3*c13+c23+23
A modified version of the methodology of either the first example (use a mathematical equation to calculate the coefficient values) or the second example (randomly generated coefficient values) described above may be used to determine the coefficient values given that the homomorphic preserving mathematical relationship now subtracts some coefficients, adds a constant, multiplies a coefficient by a constant, and omits one coefficient from the homomorphic preserving mathematical relationship altogether. Using randomly generated numbers, and given that N is again 5487, the homomorphic preserving mathematical relationship may be written as:
N=c
0
+c
1
−c
2
+c
3
−c
12+3*c13+c23+23
5487=(901)+(985)−(185)+(−584)−(286)+3*(882)+(1987)+23
5487=901+985−185−584−286+2646+1987+23
and the resulting multivector representing the numeric value N would be:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
multivector N=(901)+(985)e1+(185)e2+(−584)e3+(286)e12+(882)e13+(1987)e23+333e123
multivector N=901+985e1+185e2−584e3+286e12+882e13+1987e23+333e123
where the c123 value of 333 is a dummy value not included in the homomorphic preserving mathematical relationship, but may potentially be used to provide other features such as signature capability and/or passing of command or other information.
A homomorphic preserving mathematical relationship that includes some subtractive elements has the advantage of being able to represent negative numbers and zero without the coefficient values being negative for a user that prefers to not have negative coefficient values.
C. Multivector to Number that Supports Homomorphism
Obtaining a numeric value from the coefficients of a numeric data message multivector is relatively simple and straight forward. To obtain the numeric data message value, simply perform the homomorphic preserving mathematical relationship equation for the numeric data message multivector using the values of the multivector coefficients plugged into the homomorphic preserving mathematical relationship equation. The examples given below provide the “multivector to number” process appropriate for the same example number as described above for the “number to multivector” process.
In the first example above, the EDCHE embodiment performed the homomorphic preserving mathematical relationship process such that all coefficients are added together and there are not any coefficients that are subtracted. Thus, for a 3D multivector with coefficients c0, c1, c2, c3, c12, c13, c23, and c123, where the coefficients are numbered so as to correspond with the unit vector associated with each coefficient, the homomorphic preserving mathematical relationship equation to represent the result numeric value N would be:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
As described above, the multivector has the form of:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13 e13+c23e23+c123e123
Now, given the following result multivector,
multivector N=725+21e1+685e2+286e3−721e12+85e13+601e23+192e123
and knowing the multivector of the form:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
then the result multivector may be rewritten to highlight the appropriate positive and negative values as:
(725)+(21)e1+(685)e2+(286)e3+(−721)e12+(85)e13+(601)e23+(192)e123
and the calculation of the result numeric value N would proceed as follows:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
N=(725)+(21)+(685)+(286)+(721)+(85)+(601)+(192)
N=725+21+685+286+721+85+601+192
such that result numeric value N would be:
N=3316
Now, given a different result multivector that includes some negative coefficients, such as the following vector:
333−201e1+248e2+506e3−71e12+80e13+211e23−743e123
and knowing the result multivector with the given homomorphic preserving mathematical relationship equation is of the form:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
then the result multivector may be rewritten to highlight the appropriate positive and negative values as:
(333)+(−201)e1+(248)e2+(506)e3+(−71)e12+(80)e13+(211)e23+(−743)e123
and the calculation of the result numeric value N would proceed as follows:
N=c
0
+c
1
+c
2
+c
3
+c
12
+c
13
+c
23
+c
123
N=(333)+(−201)+(248)+(506)+(−71)+(80)+(211)+(−743)
N=333−201+248+506−71+80+211−743
such that result numeric value N would be:
N=363
In the second example above, the EDCHE embodiment performed the homomorphic preserving mathematical relationship process such that all coefficients are added together and there are not any coefficients that are subtracted, which is the same homomorphic preserving mathematical relationship equation as for the first example above. Consequently, the “multivector to number” process is identical to that as described for the “multivector to number” process of the first example given above.
In the first and second example above, the EDCHE embodiment performed the homomorphic preserving mathematical relationship process such that all coefficients are added together and there are not any coefficients that are subtracted. The third example from above changed the homomorphic preserving mathematical relationship equation to include some subtraction of some coefficients, addition of a constant value, and multiplication of coefficient values by a constant, as well as the omission of one of the coefficients (i.e., c123) from the homomorphic preserving mathematical relationship. Thus, for the third example, for a 3D multivector with coefficients c0, c1, c2, c3, c12, c13, c23, and c123, where the coefficients are numbered so as to correspond with the unit vector associated with each coefficient, the homomorphic preserving mathematical relationship equation to represent the numeric value N would again be:
N=c
0
+c
1
−c
2
+c
3
−c
12+3*c13+c23+23
As described above, the multivector has the form of:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
Now, given the same following result multivector as for example 1 above,
multivector N=725+21e1+685e2+286e3−721e12+85e13+601e23+192e123
and knowing the multivector is of the form:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
then the result multivector may be rewritten to highlight the appropriate positive and negative values as:
multivector N=(725)+(21)e1+(685)e2+(286)e3+(−721)e12+(85)e13+(601)e23+(192)e123
and the calculation of the result numeric value N would proceed as follows:
N=c
0
+c
1
−c
2
+c
3
−c
12+3
*c
13
+c
23+23
N=(725)+(21)−(685)+(286)−(−721)+3*(85)+(601)+23
N=725+21−685+286+721+255+601+23
such that result numeric value N would be:
N=1947
where the c123 value of 192 is ignored as a dummy value not included in the homomorphic preserving mathematical relationship. Note that the third example result of 1947 does not equal the first example result of 3316 for the same result multivector. Thus, demonstrating the necessity of using the same homomorphic preserving mathematical relationship equation for all encrypted multivectors of any homomorphic operations that may involve multiple encrypted multivectors.
Now, given a different result multivector that includes some negative coefficients (that is the same as the negative coefficient result multivector also used for example 1 above), such as the following vector:
multivector N=333−201e1+248e2+506e3−71e12+80e13+211e23−743e123
and knowing the result multivector with the given homomorphic preserving mathematical relationship equation is of the form:
multivector N=c0+c1e1+c2e2+c3e3+c12e12+c13e13+c23e23+c123e123
then the result multivector may be rewritten to highlight the appropriate positive and negative values as:
multivector N=(333)+(−201)e1+(248)e2+(506)e3+(−71)e12+(80)e13+(211)e23+(−743)e123
where the c123 value of −743 is a dummy value not included in the homomorphic preserving mathematical relationship. Thus, the calculation of the result numeric value N would proceed as follows:
N=c
0
+c
1
−c
2
+c
3
−c
12+3*c13+c23+23
N=(333)+(−201)−(248)+(506)−(−71)+3*(80)+(211)+23
N=333−201−248+506+71+240+211+23
such that result numeric value N would be:
N=935
Note again that the third example result of 935 does not equal the first example result of 363 for the same result multivector. Thus, again, demonstrating the necessity of using the same homomorphic preserving mathematical relationship equation for all encrypted multivectors of homomorphic operations that may involve multiple encrypted multivectors.
Homomorphic Encryption Searching may be defined as a search of encrypted data for an unencrypted value without the search request requiring knowledge of the security keys and/or the actual encrypted value of the search for unencrypted value. That is, a search request may be generated by a system based on an unencrypted value and the system may search the encrypted values and locate a stored encrypted value without either the system generating the search request or the system performing the search of stored encrypted values having any knowledge of the encryption security keys.
Given any multivector Ā, the 0-blade reduction (also known as the Rationalize) of Ā is given by:
Using some involution properties, we also have:
(
and
(Ā
Now, given a ciphertext
1
Ā
2
we can find the Rationalize of
R(
By using the involution properties described in the equations above, and letting
Replacing
R(
Once again, using the involution properties described in the equations above, we can manipulate the Rationalize of
Note that
R(
Also note that this Rationalize of
We can simplify Rationalize of
R(
Since R(Ā) is a scalar, we can reorganize Eq. (12) as
R(
And finally we obtain a multiplicative homomorphic relationship between the Rationalize of the ciphertext R(
R(
Assuming the Rationalize of the security keys (R(
The above description is for encryption utilizing two security keys (
Numerical Example of the Multiplicative Homomorphic Property of EDCE as Applied for Searching:
Given the following secret multivectors:
1=3+2ē1+4ē2+8ē3+5ē12+7ē13+3ē23+6ē123
2=11+5ē1+3ē2+15ē3+4ē12+17ē13+2ē23+1ē123
And the following plaintext message multivector:
The Rationalize of the above multivectors as calculated by applying the original Rationalize equation to each individual multivector is:
R(
R(
R(
With the final relationship from above, we have:
R(
R(
R(
In order to provide one more proof of the above statement, we can calculate R(
R(
As the Rationalize of the ciphertext (R(
It is also clear that the Rationalize of the ciphertext (R(
With the understanding of the mathematical basis for homomorphic searching described above it is worthwhile to go through an example of how a homomorphic search may be performed. In the following example, Alice stores some reports on the “cloud” (i.e., intermediary computing system) and later wishes to search to see if she has saved the reports to the cloud in the past. Given the following secret multivectors:
1=3+2ē1+4ē2+8ē3+5ē12+7ē13+3ē23+6ē123
2=11+5ē1+3ē2+15ē3+4ē12+17ē13+2ē23+1ē123
Alice receives the following reports and wishes to store them in the cloud. The following are examples of the plaintext reports (in vector form already) the Alice may receive.
1=67961+67961ē6+67961ē2+67961ē3+67961ē12+67961ē13+67961ē23+67962ē123
2=121928+121928ē1+121928ē2+121928ē3+121928ē12+121928ē13+121928ē23+121935ē123
3=19334+19334ē1+19334ē2+19334ē3+19334ē12+19334ē13+19334ē23+19335ē123
4=54017+54017ē1+54017ē2+54017ē3+54017ē12+54017ē13+54017ē23+54018ē123
5=45980+45980ē1+45980ē2+45980ē3+45980ē12+45980ē13+45980ē23+45985ē123
The above reports will then be encrypted by Alice at her computing device (acting as the source computing device) by applying the triple product (i.e., “sandwich”) technique as follows:
1
=
1
2
2
=
1
2
2
3
=
1
3
2
4
=
1
4
2
5
=
1
2
which will generate:
1=−8427270−6796150ē1+32621374ē2−16582672ē3+36427198ē12−15495282ē13+7067934ē23+17398040ē123
2=−15119814−12193150ē1+58526098ē2−29751748ē3+65354122ē12−27800802ē13+12680442ē23+31213736ē123
3=−2397522−1933450ē1+9280414ē2−4717684ē3+10363126ē12−4408326ē13+20107262ē3+4949528ē123
4=−6698214−5401750ē1+25928254ē2−13180336ē3+28953214ē12−12316050ē13+56177582ē23+13828376ē123
5=−5702050−4598250ē1+22070870ē2−11220060ē3+24645790ē12−10484310e13+4781870ē23+11771000ē123
All of the above encrypted reports are then sent by Alice (acting as the source computing device) to the cloud (acting as the intermediary computing system).
Now, Alice wants to perform a very basic search. After a while, she wants to know if the report
R(
Alice (acting as the search request computing device) sends R(
R(
R(
R(
R(
R(
In order to match the R(
R(
Consequently, the cloud will calculate the Rationalize of the encrypted data “mod” the Rationalize sent by Alice as part of the search request. When the result is 0, the cloud will know that the data Alice wants is FOUND, and will send the encrypted data back to Alice (now acting as the destination computing device).
R(
R(
R(
R(
R(
Alice was looking for
The intermediary computing system 706 receives and stores the at least one cryptotext multivector 710 and may further store additional cryptotext multivectors sent before or after the currently stored cryptotext multivector 710. The search request computing device 714 creates a search request 716 of a plaintext data message. In the creation of the search request 714, the search request computing device 714, prepares a rationalize (R(
The intermediary computing system 706 receives the search request with the rationalize of the search data 716. After receiving the search request 716 from the search request computing device 714, the intermediary computing system 706 begins the process of searching the stored cryptotext multivectors stored on the intermediary computing system 706 for the plaintext to be searched included as a rationalize of the plaintext data in the search request 716. As part of the process of the homomorphic search, the intermediary computing system 706 computes the rationalize (R(
The destination computing device 708 receives the search result 712 from the intermediary computing system 706. When there are not any cryptotext multivectors included in the search result 712, the destination computing device 708 may perform operations in accord with the FOUND/NOT-FOUND result as desired by a system designer. When there is a FOUND result that includes at least one cryptotext multivector in the search result 712, if the destination computing device 708 intends to perform operations on the plaintext represented by the at least one cryptotext multivector associated with the FOUND result, the destination computing device 708 will need to decrypt the at least one cryptotext multivector.
Further, as noted in Sections 1 and 2 above, the cryptotext multivector(s) 710 may be converted to non-multivector cryptotext when being sent over the network/bus communication connection 704, then converted back into a cryptotext multivector(s) at the intermediary computing system 706 for homomorphic searching operations. Likewise, any cryptotext multivectors linked to/associated with a FOUND result being sent to the destination computing device 708 may be converted to non-multivector cryptotext when being sent over the network/bus communication connection 704, then converted back into the encrypted cryptotext multivector at the destination computing device 708 for decryption by the destination computing device 708 into a plaintext result.
Generally, communications, including encrypted communications, are bi-directional such that the source(s) computing device 702, the search request computing device 714, the intermediary computing system 706, and/or the destination computing device 708 may change roles so as to operate as a source computing device 702, the search request computing device 714, the intermediary computing system 706, and/or the destination computing device 708 as is necessary to accommodate the transfer of data back and forth between the source(s) 702, search request 714, intermediary, and/or destination 708 computing devices/systems as well as for performance of homomorphic search operations at the intermediary computing system 706.
Further, as shown in
Various embodiments may implement the network/bus communications channel 704 using any communications channel 704 capable of transferring electronic data between the source(s) 702, search request 714, intermediary 706, and/or destination 708 computing devices/systems. For instance, the network/bus communication connection 704 may be an Internet connection routed over one or more different communications channels during transmission from the source(s) 702 and/or search request 714 to the intermediary 706, and then onto the destination 708. Likewise, the network/bus communication connection 704 may be an internal communications bus of a computing device, or even the internal bus of a processing or memory storage Integrated Circuit (IC) chip, such as a memory chip or a Central Processing Unit (CPU) chip. The network/bus communication channel 704 may utilize any medium capable of transmitting electronic data communications, including, but not limited to: wired communications, wireless electro-magnetic communications, fiber-optic cable communications, light/laser communications, sonic/sound communications, etc., and any combination thereof of the various communication channels.
The various embodiments may provide the control and management functions detailed herein via an application operating on the source(s) 702, search request 714, intermediary 706, and/or destination 708 computing devices/systems. The source(s) 702, search request 714, intermediary 706, and/or destination 708 computing devices/systems may each be a computer or computer system, or any other electronic device(s) capable of performing the communications and computations of an embodiment. The source(s) 702, search request 714, intermediary 706, and/or destination 708 computing devices/systems may include, but are not limited to: a general-purpose computer, a laptop/portable computer, a tablet device, a smart phone, an industrial control computer, a data storage system controller, a CPU, a Graphical Processing Unit (GPU), an Application Specific Integrated Circuit (ASI), and/or a Field Programmable Gate Array (FPGA). Notably, the source(s) 702 and/or destination 706 computing devices may be the storage controller of a data storage media (e.g., the controller for a hard disk drive) such that data delivered to/from the data storage media is always encrypted so as to limit the ability of an attacker to ever have access to unencrypted data. Embodiments may be provided as a computer program product which may include a computer-readable, or machine-readable, medium having stored thereon instructions which may be used to program/operate a computer (or other electronic devices) or computer system to perform a process or processes in accordance with the various embodiments. The computer-readable medium may include, but is not limited to, hard disk drives, floppy diskettes, optical disks, Compact Disc Read-Only Memories (CD-ROMs), Digital Versatile Disc ROMS (DVD-ROMs), Universal Serial Bus (USB) memory sticks, magneto-optical disks, ROMs, random access memories (RAMs), Erasable Programmable ROMs (EPROMs), Electrically Erasable Programmable ROMs (EEPROMs), magnetic optical cards, flash memory, or other types of media/machine-readable medium suitable for storing electronic instructions. The computer program instructions may reside and operate on a single computer/electronic device or various portions may be spread over multiple computers/devices that comprise a computer system. Moreover, embodiments may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., a modem or network connection, including both wired/cabled and wireless connections).
The processes 810-816 of source(s) computing device 802 are performed at least once in order to create the at least one cryptotext multivector that is to be stored at and searched by the intermediary computing system 804. At process 810, the source(s) 802 distributes the numeric message data (M) into message multivector (
The distributing/packing method defines, among many things, the Geometric Algebra operations permissible for EDCE and/or EDCHE embodiments. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. Such multivectors having all equal coefficients have no inverse and the geometric product of such multivectors having all equal coefficients with another multivector has no inverse. For example, the Rationalize operation on multivectors yields zero when all multivector coefficients are equal. As discussed in more detail above, the decryption methodology for EDCE and EDCHE systems utilize the inverse of the cryptotext multivector being decrypted and of the security key(s) multivector to perform the decryption. Therefore, the cryptotext multivector being decrypted should not have all equal value coefficients. One means to ensure that the cryptotext multivector being decrypted does not have all equal value coefficients is to have the packing/coefficient distribution method ensure that not all coefficients are equal to each other (i.e., at least one coefficient should be different than the other coefficients) when creating the shared security multivector(s) and the data message multivector(s). For an embodiment of the EDCE that simply transfers the data message (such as a search embodiment that does not perform any mathematical operations that change the value of the encrypted data representation), this will ensure that the cryptotext multivector to be decrypted will not have all equivalent coefficients.
For embodiments that intend to retain homomorphic properties for encrypted data messages such as an embodiment of an EDCHE system, there is an additional restriction that the “packed” multivector that represents the original plaintext numeric message have a mathematical relationship (i.e., the homomorphic preserving mathematical relationship) to the original plaintext numeric message. In abstract algebra, the term homomorphism refers to a structure-preserving map between two algebraic structures, such as groups, rings, or vector spaces. An algebra homomorphism between two algebras is one that preserves the algebra structure. In order to preserve the algebra structure between arithmetic and Geometric Algebra operations, the method by which numbers are “packed” into multivector elements must remain a representation of the original number. One such relationship for packing the coefficients of the multivector that preserves homomorphic properties is to ensure that the coefficients of the multivector representation of the plaintext numeric message follow a mathematical data organization between the value of the plaintext numeric message and at least one of the values of the coefficients of the multivector representation of the plaintext numeric message where the mathematical operations incorporating the one or more values of the multivector coefficients have a result equal to the original plaintext numeric message value. The mathematical relationship may include: addition of at least one coefficient of the multivector coefficients, subtraction of at least one coefficient of the multivector coefficients, addition of a constant value, subtraction of a constant value, multiplication of at least one coefficient of the multivector coefficients by a constant value, and division of at least one coefficient of the multivector coefficients by a constant value. The location of the various mathematical operations relative to the particular locations of the coefficients in the multivector representation should also be consistently applied to all source numeric data messages converted to a multivector as well as for result multivectors converted to a result numeric data value in a particular encryption/decryption pathway.
The restriction to retain homomorphic properties is only applicable to the distribution (i.e., “packing”) of the message multivector (
At process 814, the source(s) 802 encrypts a cryptotext multivector (
At process 816, the source(s) 802 sends the cryptotext multivector (
At process 818, the intermediary computing system 804 receives the at least one cryptotext multivector (
At process 822, the search request computing device 806 distributes the plaintext numeric search request data (SR) that is to be searched for on the intermediary computing system 804 into search request message multivector (
At process 828, the intermediary computing system 804 receives the search request for the rationalize (R(
At process 936, the destination computing device 926 receives the search result sent by the intermediary computing system 924 and when it is a FOUND search result, the search result includes the encrypted value (
For more detail on general Geometric Algebra concepts, an additional discussion of an overview of general Geometric Algebra concepts may be found in “Appendix A: Geometric Algebra Overview” of the parent patent application Ser. No. 15/667,325, filed Aug. 2, 2017, entitled “Methods and Systems for Enhanced Data-Centric Encryption Systems Using Geometric Algebra,” which has been specifically incorporated herein by reference for all that it discloses and teaches. For a more exhaustive reference see [REFERENCE1].
The foregoing description of the invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed, and other modifications and variations may be possible in light of the above teachings. The above described embodiments were chosen and described in order to best explain the principles of the invention and its practical application to thereby enable others skilled in the art to best utilize the invention in various embodiments and various modifications as are suited to the particular use contemplated. It is intended that the appended claims be construed to include other alternative embodiments of the invention except insofar as limited by the prior art.
This application is a continuation-in-part of U.S. patent application Ser. No. 15/946,631, filed Apr. 5, 2018, entitled “Methods and Systems for Enhanced Data-Centric Scalar Multiplicative Homomorphic Encryption Systems Using Geometric Algebra,” which is a continuation-in-part of U.S. patent application Ser. No. 15/884,047, filed Jan. 30, 2018, entitled “Methods and Systems for Enhanced Data-Centric Encryption Additive Homomorphic Systems Using Geometric Algebra,” which is a continuation-in-part of U.S. patent application Ser. No. 15/667,325, filed Aug. 2, 2017, entitled “Methods and Systems for Enhanced Data-Centric Encryption Systems Using Geometric Algebra,” which is based upon and claims the benefit of U.S. provisional applications Ser. No. 62/370,183, filed Aug. 2, 2016, entitled “Methods and Systems for Enhanced Data-Centric Encryption Systems Using Geometric Algebra;” Ser. No. 62/452,246, filed Jan. 30, 2017, entitled “Methods and Systems for Enhanced Data-Centric Encryption Additive Homomorphic Systems Using Geometric Algebra;” and Ser. No. 62/483,227, filed Apr. 7, 2017, entitled “Methods and Systems for Enhanced Data-Centric Scalar Multiplicative Homomorphic Encryption Systems Using Geometric Algebra,” and which U.S. patent application Ser. No. 15/884,047 is also based upon and claims the benefit of U.S. provisional applications Ser. No. 62/572,955, filed Oct. 16, 2017, entitled “Methods and System for Enhanced Data-Centric Homomorphic Encryption Searching Using Geometric Algebra;” and Ser. No. 62/572,970, filed Oct. 16, 2017, entitled “Methods and System for Enhanced Data-Centric Homomorphic Encryption Sorting Using Geometric Algebra,” and this application is also based upon and claims the benefit of U.S. provisional application Ser. No. 62/713,234, filed Aug. 1, 2018, entitled “Methods and Systems for Hashing Cryptographic Systems Using Geometric Algebra;” and Ser. No. 62/719,488, filed Aug. 17, 2018, entitled “Methods and Systems for an Enhanced Data-Centric Encryption Dynamic Packing Scheme,” all of which are specifically incorporated herein by reference for all that they disclose and teach.
| Number | Date | Country | |
|---|---|---|---|
| 62370183 | Aug 2016 | US | |
| 62452246 | Jan 2017 | US | |
| 62483227 | Apr 2017 | US | |
| 62572955 | Oct 2017 | US | |
| 62572970 | Oct 2017 | US | |
| 62713234 | Aug 2018 | US | |
| 62719488 | Aug 2018 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15946631 | Apr 2018 | US |
| Child | 16162068 | US | |
| Parent | 15884047 | Jan 2018 | US |
| Child | 15946631 | US | |
| Parent | 15667325 | Aug 2017 | US |
| Child | 15884047 | US |
