Patent Application
20200084024
The present invention relates to methods and apparatus for encrypting and decrypting messages transmitted over a public communication network.
In general, in the descriptions that follow, I will italicize the first occurrence of each special term of art that should be familiar to those skilled in the art of integrated circuits (“ICs”) and systems. In addition, when I first introduce a term that I believe to be new or that I will use in a context that I believe to be new, I will bold the term and provide the definition that I intend to apply to that term. In addition, throughout this description, I will sometimes use the terms assert and negate when referring to the rendering of a signal, signal flag, status bit, or similar apparatus into its logically true or logically false state, respectively, and the term toggle to indicate the logical inversion of a signal from one logical state to the other. Alternatively, I may refer to the mutually exclusive boolean states as logic_0 and logic_1. Of course, as is well known, consistent system operation can be obtained by reversing the logic sense of all such signals, such that signals described herein as logically true become logically false and vice versa. Furthermore, it is of no relevance in such systems which specific voltage levels are selected to represent each of the logic states.
Hereinafter, when I refer to a facility I mean a circuit or an associated set of circuits adapted to perform a particular function regardless of the physical layout of an embodiment thereof. Thus, the electronic elements comprising a given facility may be instantiated in the form of a hard macro adapted to be placed as a physically contiguous module, or in the form of a soft macro the elements of which may be distributed in any appropriate way that meets speed path requirements. In general, electronic systems comprise many different types of facilities, each adapted to perform specific functions in accordance with the intended capabilities of each system. Depending on the intended system application, the several facilities comprising the hardware platform may be integrated onto a single IC, or distributed across multiple ICs. Depending on cost and other known considerations, the electronic components, including the facility-instantiating IC(s), may be embodied in one or more single- or multi-chip packages. However, unless I expressly state to the contrary, I consider the form of instantiation of any facility that practices my invention as being purely a matter of design choice.
Shown in
Shown in
In the past, various attempts have been made to protect messages from eavesdropping or modification by unauthorized persons while in transit over a public communication network. In the field of cryptography, many encryption protocols have been proposed to solve this problem. One such system, known as secure shell (“ssh”), has come into very widespread use for traffic transmitted over the Internet. One other popular approach, known as public key cryptography, has proven especially useful when implemented in the context of a public key infrastructure (“PKI”). However, while generally considered satisfactory for some types of traffic, both ssh and PKI impose substantial computational loads on the end points, as well as significant non-data-related network traffic. More importantly, both of these techniques suffer from inherent cryptographic weaknesses.
As has been known for many years by cryptographers, the only encryption technique that cannot be cracked is the so-called one-time pad (“OTP”). In accordance with the traditional form of this technique, each encryption key in the OTP is constructed so as to be at least as long as a message to be encrypted. The OTP is then pre-shared via a trusted exchange mechanism between a sender and a recipient. In the encryption process, the sender encrypts each bit or character of a plaintext message by combining it with the corresponding bit or character from a particular page of the OTP; upon being received, the recipient decrypts each bit or character of the received cyphertext by reversing the combination process using the respective page of the OTP. The most problematic aspect of the OTP technique is the difficulty of securely pre-sharing the OTP. This process is described in detail in a number of well-known publications, including, inter alia, The Code Book, by Simon Singh, Anchor Books (2000), express incorporation of the entirety of which is hereby made by reference.
In the field of cryptography, the OTP is considered to be an early implementation of what are now referred to as ephemeral keys. In general, a cryptographic key is referred to as ephemeral if it is generated for each execution of a key establishment process. Various mechanisms have been proposed for controlling the consumption sequence of these keys. For the purposes of the following description, I hereby define “consumption sequence” to mean the sequence in which the keys comprising the OTP are first used to encrypt/decrypt a message packet, and, thereafter, consumed, i.e., deleted, on a packet-by-packet basis, by the sender and recipient from the respective local copies of the OTP, whereby what was the “second” key in the OTP before consumption of the current “first” key automatically becomes the next “first” key. One example in the prior art is known as ratcheting. One embodiment of racheting is discussed in the eDocument, “Advanced cryptographic ratcheting”, that I downloaded 1 Jan. 2018 from https://signal. org/blog/advanced-ratcheting/. Another ratcheting algorithm is disclosed in a Wiki-Document that may be found at https://en.wikipedia.org/wiki/Double_Ratchet_Algorithm. Yet another prior art key management protocol is discussed in “Off-the-Record Messaging Protocol version 3”, that I downloaded on 1 Jan. 2018 from https://otr.cypherpunks.ca/Protocol-v3-4.0.0.html. I have submitted herewith a copy of each of these prior art eDocuments, and hereby expressly incorporate each herein, in its entirety, by reference. However, I am aware of no prior art consumption sequencing methodology that is not inherently computationally complex.
Thus, I submit, the essential missing piece of this puzzle is a simple, but secure, method for exchanging ephemeral keys, and, thereafter, for securely coordinating the consumption sequence of the keys by the sender and recipient. I submit that what is needed is a one time pad cryptography method and apparatus that is more secure, efficient and effective than the known cryptographic art.
In accordance with one embodiment of my invention, I provide a one time pad (OTP) cryptography method adapted for use in a public communication system comprising: a public communication network; a first communication facility adapted to be selectively coupled to the public communication network; and a second communication facility adapted to be selectively coupled to the public communication network. In one embodiment, my method comprises the steps of: first, in a selected one of the first and second communication facilities, developing a OTP comprising at least a first key; and then using a secure channel instantiated on the public communication network to pre-share the OTP with the first and second communication facilities; second, in the first communication facility: using the first key to encrypt a first packet of a first message comprising a plurality of packets; and then transmitting the encrypted first packet via a non-secure channel instantiated on the public communication network; third, in the second communication facility: receiving the encrypted first packet via the non-secure channel; and then using the first key to decrypt the encrypted first packet; and, fourth, in the first and second communication facilities, consuming the first key.
In accordance with one other embodiment of my invention, I provide a one time pad (OTP) cryptography method adapted for use in a system comprising: a public communication network; a first computational facility selectively coupled to the communication network; and a second computational facility selectively coupled to the communication network. In this embodiment, my method comprises: an OTP initialization phase comprising the steps of: in a selected one of the first and second computational facilities, generating an OTP comprising a first random key and a second random key; opening a secure communication channel between the selected computational facility and the non-selected computational facility via the public communication network; selectively transmitting the OTP from the selected computational facility to the non-selected computational facility via the secure communication channel; and closing the secure communication channel; and an OTP consumption phase comprising the steps of: opening a non-secure communication channel between the first and second computational facilities via the public communication network; in the first and second computational facility, selecting the first random key from the OTP; in the first computational facility, using the selected first random key to encrypt a first packet of a first message in the first computational facility, transmitting the encrypted first packet to the second computational facility; in the second computational facility, receiving the encrypted first packet from the first computational facility; in the second computational facility, using the selected first random key to decrypt the received encrypted first packet; in the first and second computational facilities, consuming the first random key from the OTP whereby the second random key is now the first random key in the OTP; if the transmitted packet is not the last packet of the first message, repeating a selected subset of the above steps; and, otherwise, closing the non-secure communication channel.
In accordance with yet another embodiment of my invention, a communication system may be configured to practice my methods.
In accordance with still another embodiment of my invention, a non-transitory computer readable medium may include executable instructions which, when executed in a processing system, causes the processing system to perform the steps of my one time pad encryption methods.
My invention may be more fully understood by a description of certain preferred embodiments in conjunction with the attached drawings in which:
In the drawings, similar elements will be similarly numbered whenever possible. However, this practice is simply for convenience of reference and to avoid unnecessary proliferation of numbers, and is not intended to imply or suggest that my invention requires identity in either function or structure in the several embodiments.
From time to time, by way of example, I will provide code snippets to illustrate processor-implementable techniques adapted to perform certain aspects of my methods. Unless otherwise noted, these snippets will be composed in the well-known PHP Hypertext Preprocessing (“PHP”) language. In accordance with the PHP language standard:
lines of PHP code are enclosed between an open group, “<?php”, and a close group, “?>”;
variable names start with a dollar sign, “$”; and
comments are separated from code by the double-slash, “//”.
In accordance with my preferred programming standards, the data types of the several variables will be denoted by the first alphabetic character following the $ sign as follows:
a=>array;
b=>boolean;
f=>floating point;
i=>integer;
o=>object;
r=>resource; and
s=>string.
In some of my example snippets, accesses will be made by Server 12 to DB 14, which I have chosen to implement using the popular, open source MySQL database server. In each of these queries, the syntax and semantics will conform to the published MySQL language standard.
In the embodiment of
Shown in
In this OTP-generation snippet, I have made calls to two different functions contained within a PHP class named “Encryption”. By way of example, the protected class function “_publicKeyExists” may be implemented as follows:
wherein the “(int)” expressly constrains to an integer the returned random number. Further, by way of example, the public class function “addKeyPair” may be implemented as follows:
In support of the functions described above, I have created the keys table in the DB 14 associated with Server 12 according to the following MySQL table definition:
wherein:
the DEFAULT CHARSET I have selected is utf8.
In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:
wherein:
In this OTP-retrieval snippet, I have made a call to one additional new function contained within my Encryption class. By way of example, the public class function “getPublicKeys” may be implemented as follows:
After negotiating an ssh session, Server 12 transmits to Client 16 the OTP. Thus, at the end of this Initialization Phase, both Server 12 and Client 16 share a common OTP.
Shown in
My Implicit Sequencing Process may be re-executed at any time following boot. In particular, when the number of remaining key_pairs in the local OTP falls below a selected threshold, Server 12 can re-execute the Initialization Phase to generate a new OTP for ssh transmission to Client 16 shortly before, or contemporaneous with, the mutual exhaustion of the previous OTP. Thus, just as in a traditional paper OTP process, each key_pair comprising my electronic OTP is used once and only once.
Shown in
In this OTP-generation snippet, I have made a call to the _publicKeyExists function, described above, and a call to a new function contained within my Encryption class. By way of example, the public class function “deletePublicKey” may be implemented as follows:
Thus, during the Initialization Phase of my Direct Sequencing Process, Server 12 directs Client 16 to use the ZP associated in the OTP with the transmitted index for encrypting the first packet of the next transmitted message.
Shown in
My Direct Sequencing Process may be re-executed at any time following boot. In particular, when the number of remaining key_pairs in the local OTP falls below a selected threshold, Server 12 can re-execute the Initialization Phase to generate a new OTP for ssh transmission to Client 16 shortly before, or contemporaneous with, the mutual exhaustion of the previous OTP. Again, just as in a traditional paper OTP process, each key_pair comprising my electronic OTP is used once and only once.
As is known, asymmetric cryptography, of which the public key technology is one example, is substantially more computationally complex than symmetric cryptography. However, it has been proved that asymmetric cryptography is more resistant to cracking than symmetric cryptography. As a result, asymmetric cryptography techniques are often used to create a secure channel for transmitting symmetric cryptographic keys, with the balance of the message thereafter being encrypted using symmetric techniques. Since ssh uses public key cryptographic techniques during ssh sessions, I consider it safe to populate my OTPs with symmetric keys, thereby realizing the benefit of significantly reduced computational complexity in both of Client 16 and Server 12. Except for this difference, the flows of such embodiments will be substantially the same as those discussed above. For example, let us assume that Z now comprises 1024 symmetric keys generated using the following PHP code snippet:
In this OTP-generation snippet, I have made calls to two new functions contained within my Encryption class. By way of example, the protected class function “_KeyExists” may be implemented as follows:
Further, by way of example, the public class function “addKey” may be implemented as follows:
In support of the functions described above, I have created the symmetric keys table in DB 14 associated with Server 12 according to the following My SQL table definition:
wherein:
In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:
In this OTP-retrieval snippet, I have made a call to one additional new function contained within my Encryption class. By way of example, the public class function “getKeys” may be implemented as follows:
In this symmetric key example, the sequencing of indices is the same as in my asymmetric example. However, the public class function “deleteIndex” should be implemented as follows:
Shown in
In this OTP-generation snippet, I have made calls to two new functions contained within my Encryption class. By way of example, the protected class function “_indexExists” may be implemented as follows:
Further, by way of example, the public class function “addIndex” may be implemented as follows:
In support of the functions described above, I have created the index table in DB 14 associated with Server 12 according to the following MySQL table definition:
In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:
In this OTP-retrieval snippet, I have made a call to one additional new function contained within my Encryption class. By way of example, the public class function “getIndexes” may be implemented as follows:
In this example, the public class function “deleteIndex” should be implemented as follows:
Thus, during the Initialization Phase, Server 12 pre-shares with Client 16 both the keys table, KP, and the index-based OTP.
Shown in
My Indexed Sequencing Process may be re-executed at any time following boot. In particular, when the number of remaining indexes in the local OTP falls below a selected threshold, Server 12 can re-execute the Initialization Phase to generate a new OTP for ssh transmission to Client 16 shortly before, or contemporaneous with, the mutual exhaustion of the previous OTP. Again, just as in a traditional paper OTP process, each index comprising my electronic OTP is used once and only once.
Shown in
This first key, let's call it Key1, is then transmitted by Server 12 to Client 16. In this embodiment, both Server 12 and Client 16 are configured to use this key to encrypt/decrypt the first packet of the next message. Now, as I have illustrated in
In
As I have illustrated in my indirect system in
Consider one interesting embodiment wherein the OTP is generated dynamically rather than statically as in the several configurations I have discussed above. Let us assume, by way of example, that Client 16 is configured to control both OTP generation and sharing, and consumption sequencing. In the Initialization Phase of this embodiment, Client 16 will generate only a single, first key, Key1, and then securely share it with Server 12 using either ssh or an earlier-established OTP-based channel. As per usual, upon opening the non-secure, public Comm channel, Client 16 will consume Key1 to encrypt the first packet. However, before doing so, Client 16 generates a second key, Key2, and adds it to the packet at a pre-agreed location within the packet frame. Upon receipt and decryption using Key1, Server 12 is able to recover Key2 for use with the next packet. When the last packet, N, of a particular message has been successfully transmitted, the last pre-shared key, KeyN, will be retained by both Servers 12 and Client 16 for use with the first packet of the next message. Thus, in this way, the OTP is both generated and consumed on-the-fly, i.e., dynamically.
It is also possible in such an embodiment, during the Initialization Phase, to generate and securely pre-share an initial first-in-first-out stack comprising, say, K, keys. Then, as each packet is processed during the Consumption Phase, the key at the top of the stack will be popped off the stack, i.e., consumed, and the dynamically generated key will be pushed onto the bottom of the stack. I characterize this embodiment as a K-lookahead configuration, in that each dynamically generated key is associated with the Kth next packet.
In general, my OTP cryptography methods share the following characteristics:
Some important features of my Sequencing Processes include:
Although I have described my invention in the context of particular embodiments, one of ordinary skill in this art will readily realize that many modifications may be made in such embodiments to adapt either to specific implementations. Thus it is apparent that I have provided several embodiments of one time pad methods that are both effective and efficient. Further, I submit that my methods and apparatus provide performance generally superior to the best prior art techniques.
In the appended claims, I intend the term computational facility to comprise any computer-based or processor-based processing facility or programmable electronic processing system that is either configured or configurable to perform the several functions I have discussed above in the context of my Server 12, Client 16, Server 26 and Client 30. I also intend that the terms “encrypt” and “decrypt” include any encryption methodology now known or hereafter developed that satisfies the criteria I have enumerated above with respect to my several sequencing processes. As will be clear to those skilled in this art, all of my sequencing processes can readily be instantiated in special-purpose electronic circuits, i.e., hardware or firmware or a combination of both, or in a programmed sequence of computer executable instructions, i.e., software, stored on a non-transient computer readable medium for execution on a general-purpose processor, or any functional combination thereof.
