One Time Pad Cryptography Method and Apparatus

Abstract

A communication system comprising a server device and a client device connected via a public network. The server generates a one time pad (OTP) comprising a plurality of mutually random keys, and pre-shares the OTP with the client via a secure communication channel instantiated on the public network. Thereafter, each time the client transmits a packet of a message, the client encrypts that packet with the top key in the client's local copy of the OTP; and, upon receipt, the server decrypts the encrypted packet using the same top key in the server's local copy of the OTP. Both the client and server then delete the now-used key from the OTP, thereby creating a new top key in both local copies of the OTP. This key consumption process continues until all packets have been securely transmitted.

Claims

1. A one time pad (OTP) cryptography method adapted for use in a public communication system comprising: [1.0.1] a public communication network; [1.0.2] a first communication facility adapted to be selectively coupled to the public communication network; and [1.0.2] a second communication facility adapted to be selectively coupled to the public communication network; and the method comprising the steps of: [1.1] in a selected one of the first and second communication facilities, developing a OTP comprising at least a first key; [1.2] using a secure channel instantiated on the public communication network to pre-share the OTP with the first and second communication facilities; [1.3] in the first communication facility: [1.3.1] using the first key to encrypt a first packet of a first message comprising a plurality of packets; and [1.3.2] transmitting the encrypted first packet via a non-secure channel instantiated on the public communication network; [1.4] in the second communication facility: [1.4.1] receiving the encrypted first packet via the non-secure channel; and [1.4.2] using the first key to decrypt the encrypted first packet; and [1.5] in the first and second communication facilities, consuming the first key.

2. The method of claim 1: wherein the OTP is further characterized as comprising first and second keys; and wherein, upon consuming the first key in the OTP, the second key becomes the first key; further comprising the steps of: [1.6] in the first communication facility: [1.6.1] encrypting a next packet of the first message using the first key; and [1.6.2] transmitting the encrypted next packet via the non-secure channel instantiated on the public communication network; [1.7] in the second communication facility: [1.7.1] receiving the encrypted next packet via the non-secure channel; and [1.7.2] decrypting the encrypted next packet using the first key; and [1.8] in the first and second communication facilities, consuming the first key.

3. The method of claim 2: wherein the OTP is further characterized as comprising a plurality, n, of keys; further comprising the step of: [1.9] repeating steps [1.6] through [1.8] for each of n packets of the first message.

4. In a system comprising: [4.0.1] a public communication network; [4.0.2] a first computational facility selectively coupled to the communication network; and [4.0.2] a second computational facility selectively coupled to the communication network; and a one time pad (OTP) cryptography method comprising: [4.1] an OTP initialization phase comprising the steps of: [4.1.1] in a selected one of the first and second computational facilities, generating an OTP comprising a first random key and a second random key; [4.1.2] opening a secure communication channel between the selected computational facility and the non-selected computational facility via the public communication network; [4.1.3] selectively transmitting the OTP from the selected computational facility to the non-selected computational facility via the secure communication channel; and [4.1.4] closing the secure communication channel; and [4.2] an OTP consumption phase comprising the steps of: [4.2.1] opening a non-secure communication channel between the first and second computational facilities via the public communication network; [4.2.2] in the first and second computational facility, selecting the first random key from the OTP; [4.2.3] in the first computational facility, using the selected first random key to encrypt a first packet of a first message [4.2.4] in the first computational facility, transmitting the encrypted first packet to the second computational facility; [4.2.5] in the second computational facility, receiving the encrypted first packet from the first computational facility; [4.2.6] in the second computational facility, using the selected first random key to decrypt the received encrypted first packet; [4.2.7] 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; [4.2.8] if the transmitted packet is not the last packet of the first message, repeating steps [4.2.2] through [4.2.7]; and, otherwise, [4.2.9] closing the non-secure communication channel.

5. A communication system configured to practice the method of any preceding claim.

6. A non-transitory computer readable medium including executable instructions which, when executed in a processing system, causes the processing system to perform the steps of a method according to any one of claims 1 to 4.

Description

BRIEF DESCRIPTION OF THE SEVERAL VIEWS OF THE DRAWINGS

[0014] My invention may be more fully understood by a description of certain preferred embodiments in conjunction with the attached drawings in which:

[0015] FIG. 1 illustrates, in block diagram form, a communication system adapted to practice my invention;

[0016] FIG. 2 illustrates, in block diagram form, a typical server facility adapted to practice my invention;

[0017] FIG. 3, comprising FIG. 3A and FIG. 3B, illustrates, in parallel flow diagram form, one embodiment of my Implicit Sequencing Process;

[0018] FIG. 4, comprising FIG. 4A and FIG. 4B, illustrates, in parallel flow diagram form, one embodiment of my Direct Sequencing Process;

[0019] FIG. 5, comprising FIG. 5A and FIG. 5B, illustrates, in parallel flow diagram form, one embodiment of my Indexed Sequencing Process; and

[0020] FIG. 6, comprising FIG. 6A and FIG. 6B, illustrates, in parallel flow diagram form, one embodiment of my Express Sequencing Process; and

[0021] FIG. 7 illustrates, in block diagram form, another communication system adapted to practice my invention.

[0022] 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.

DETAILED DESCRIPTION OF THE INVENTION

[0023] 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:

[0024] lines of PHP code are enclosed between an open group, <?php, and a close group, ?>;

[0025] variable names start with a dollar sign, $; and

[0026] 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:

[0027] a=>array;

[0028] b=>boolean;

[0029] f=>floating point;

[0030] i=>integer;

[0031] o=>object;

[0032] r=>resource; and

[0033] 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.

[0034] In the embodiment of FIG. 1, I have illustrated what I characterize as a direct communication system adapted to provide end-to-end encryption of all packets containing confidential data transmitted to Server 12 by Client 16. In particular, I characterize this approach as an Implicit Sequencing Process in that, in this approach: the OTP comprises actual keys; and the order of keys in the OTP implicitly controls the consumption sequence of those keys.

[0035] Shown in FIG. 3A is one embodiment of the Initialization Phase of my Implicit Sequencing Process, to be first executed during system boot. First, Server 12 generates an OTP, comprising an enumerated plurality, Z, of public-private key_pairs, each key_pair comprising a public key, Z.sup.P and a private key, Z.sub.P. For example, let us assume that Z comprises 1024 key_pairs generated using the following PHP code snippet:

TABLE-US-00001 <?php // Generate a new keys table $aConfig = array // openssl pkey parameters ( digest_alg => sha512, private_key_bits => 2048, private_key_type => OPENSSL_KEYTYPE_RSA ); $iMaxKeys = 1024; // total number of key_pairs in Z $iKeys = 0; // initialize key counter do { $rKeyPair = openssl_pkey_new($aConfig); // generate key_pair $aPublicKey = openssl_pkey_get_details($rKeyPair); // get public key details $sPublicKey = $aPublicKey[key]; // get public key openssl_pkey_export($rKeyPair, $sPrivateKey); // get private key if (!Encryption::_publicKeyExists($sPublicKey)) // accept if unique { Encryption::addKeyPair($sPublicKey, $sPrivateKey) // add key_pair ++$iKeys; // increment key counter } } while ($iKeys < $iMaxKeys); ?>

[0036] 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:

TABLE-US-00002 <?php // Check to see if sPublicKey already exists in the keys table protected static function _publicKeyExists($sPublicKey = ) { if (!$sPublicKey) { logError(_publicKeyExists 1: got no sPublicKey); return false; } $sql = SELECT COUNT(*) FROM DB.keys WHERE key_public = \.$sPublicKey.\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(_publicKeyExists 2: access to DB failed); return false; } $iCnt = (int) $oMySQL>fetchOne($oTmp); return $iCnt; } // end function _publicKeyExists ?>

[0037] 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:

TABLE-US-00003 <?php // Add a new key_pair to the akeys table public static function addKeyPair($sPublicKey = , $sPrivateKey = ) { if (!$sPublicKey) { logError(addKeyPair 1: got no sPublicKey); return false; } if (!$sPrivateKey ) { logError(addKeyPair 2: got no sPrivateKey ); return false; } $sql = INSERT INTO DB.akeys ( akey_public, akey_private, akey_created_dt ) VALUES ( \.$sPublicKey.\, \.$sPublicKey.\, (NOW( )) ); $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(addKeyPair 3: access to DB failed); return false; } return true; } // end function addKeyPair ?>

[0038] 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:

TABLE-US-00004 CREATE TABLE akeys ( akey_index int(10) unsigned NOT NULL AUTO_INCREMENT, akey_public text NOT NULL, akey_private text NOT NULL, akey_created_dt datetime NOT NULL, PRIMARY KEY (akey_index) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[0039] wherein: [0040] the field akey-id comprises the index of each key_pair; [0041] the field akey-public comprises the public key field; [0042] the field akey-private comprises the private key field; [0043] the field akey_df comprises the datetime the key_pair was created; [0044] the InnoDB is the particular MySQL ENGINE I have selected; and

[0045] the DEFAULT CHARSET I have selected is utf8.

[0046] In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:

TABLE-US-00005 <?php // Get the OTP from the DB $sZ = ; // start the public key string $aZ = Encryption::getPublicKeys( ); // retrieve the public keys foreach($aZ as $aCodes) { $sZ .= :.$aCodes[akey_public]; // append to public key string } ?>

[0047] wherein: [0048] the periods . invoke the PHP string concatenate function; and [0049] the :. sequence inserts a colon : between each string element.

[0050] 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:

TABLE-US-00006 <?php // Get only the public keys from the keys table public static function getPublicKeys( ) { $sql = SELECT akey_index, akey_public FROM DB.akeys ORDER BY akey_index; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(getPublicKeys 1: access to DB failed); return false; } if ($oTmp>num_rows < 1) { logError(getPublicKeys 2: got no data); return false; } while ($aKey = $oMySQL>fetchRow($oTmp, FETCHMODE_ASSOC)) { $iKeyId = $aKey[akey_index]; $aKeys[$iKeyId] = $aKey[akey_public]; } return $aKeys; } // end function getPublicKeys ?>

[0051] 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.

[0052] Shown in FIG. 3B is one embodiment of the Consumption Phase of my Implicit Sequencing Process, to be performed each time Client 16 desires to transmit a packet to Server 12. After opening a public, i.e., un-secure, communication (Comm) channel between Client 16 and Server 12, both Client 16 and Server 12 select the first/next key, sequentially, in the OTP, wherein the key selected by Client 16 is a public key, Z.sup.P, and the key selected by Server 12 is the respective private key, Z.sub.P. Client 16 then uses the selected Z.sup.P to encrypt the first/next packet in the message protocol for transmission to Server 12. Upon receipt, Server 12 uses the selected Z.sub.P to decrypt the received packet. Both Client 16 and Server 12 then consume the now-used key_pair, i.e., each deletes the respective keys from the local copies of the OTP. This process loops until the last packet of the message has been transmitted, whereupon the comm channel is closed. Note that this communication channel need be neither secure nor trusted, since all packets transiting the channel will be encrypted.

[0053] 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.

[0054] Shown in FIG. 4A is one embodiment of the Initialization Phase of my Direct Sequencing Process, to be first executed during system boot. Just as in the Initialization Phase of my Implicit Sequencing Process, Server 12 generates an OTP, comprising an enumerated plurality, Z, of public-private key_pairs, each pair comprising a public key, Z.sup.P and a private key, Z.sub.P. For this example, let us assume that Z is generated by Server 12 and transmitted to Client 16 using the code snippets discussed above. However, in this embodiment, after transmitting the OTP, Server 12 randomly selects the index one of the key_pairs in the OTP using the following PHP code snippet:

TABLE-US-00007 <?php // Randomly select a new index $iMaxIndicies = 1024; // total number of indicies in OTP $bOK = false; do { $iIndex = (int) mt_rand (1, $iMaxIndicies )]; // generate a new index if (Encryption::_publicKeyExists($iIndex )) // accept if still in OTP { Encryption::deletePublicKey($iIndex ) // delete akey at iIndex $bOK = true; // exit do loop } } while (!$bOK) ?>

[0055] 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:

TABLE-US-00008 <?php // Delete the key_pair at iIndex from the akeys table protected static function deletePublicKey($iIndex = 0) { if (!$iIndex ) { logError(deleteIndex 1: got no iIndex ); return false; } $sql = DELETE FROM DB.akeys WHERE akey_index = \.$iIndex.\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(deleteIndex 2: access to DB failed); return false; } return true; } // end function deletePublicKey ?>
Thus, during the Initialization Phase of my Direct Sequencing Process, Server 12 directs Client 16 to use the Z.sup.P associated in the OTP with the transmitted index for encrypting the first packet of the next transmitted message.

[0056] Shown in FIG. 4B is one embodiment of the Consumption Phase of my Direct Sequencing Process, to be performed each time Client 16 desires to transmit a packet to Server 12. As can be seen by comparing the flow illustrated in FIG. 4B to the flow in FIG. 3B, the Consumption Phase of my Direct Sequencing Process differs from the Consumption Phase of my Implicit Sequencing Process primarily in the mechanism I use to control the selection of the next sequential key_pair in the respective OTPs. In this flow, after Client 16 and Server 12 consume the just-used key_pair, Server 12 will randomly select (using the same code snippets described above) the index of the key_pair in the OTP to be used to encrypt/decrypt the next packet. Note that, if the last packet of the current message has just been transmitted, the key_pair having this index will be used to encrypt/decrypt the first packet of the next message to be transmitted.

[0057] 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.

[0058] 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:

TABLE-US-00009 <?php // Generate a new symmetric keys table $iMaxKeys = 1024; // total number of key_pairs in Z $iKeys = 0; // initialize key counter do { $sKey = openssl_random_pseudo_bytes(256); // generate random 256 bytes if (!Encryption::_KeyExists($sKey)) // accept if unique { Encryption::addKey($sKey, $sKey) // add key ++$iKeys; // increment key counter } } while ($iKeys < $iMaxKeys); ?>

[0059] 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:

TABLE-US-00010 <?php // Check to see if sKey already exists in the symmetric keys table protected static function _KeyExists($sKey = ) { if (!$sKey) { logError(_KeyExists 1: got no sKey); return false; } $sql = SELECT COUNT(*) FROM DB.skeys WHERE skey_key = \.$sKey.\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(_KeyExists 2: access to DB failed); return false; } $iCnt = (int) $oMySQL>fetchOne($oTmp); return $iCnt; } // end function_KeyExists ?>
Further, by way of example, the public class function addKey may be implemented as follows:

TABLE-US-00011 <?php // Add a new key_pair to the symmetric keys table public static function addKey($sKey = ) { if (!$sKey) { logError(addKey 1: got no sKey); return false; } $sql = INSERT INTO DB.skeys ( skey_key, skey_created_dt ) VALUES ( \.$sKey.\, (NOW( )) ); $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(addKey 2: access to DB failed); return false; } return true; } // end function addKey ?>

[0060] 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:

TABLE-US-00012 CREATE TABLE skeys ( skey_id int(10) unsigned NOT NULL AUTO_INCREMENT, skey_key text NOT NULL, skey_created_dt datetime NOT NULL, PRIMARY KEY (skey_index) ) ENGINE=InnoDB DEFAULT CHARSET=utf8;

[0061] wherein: [0062] the field skey-id comprises the index of each key; [0063] the field skey-key comprises the key text field; [0064] the field key_dt comprises the datetime the key was created; [0065] the InnoDB is the particular MySQL ENGINE I have selected; and [0066] the DEFAULT CHARSET I have selected is utf8.

[0067] In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:

TABLE-US-00013 <?php // Get the OTP from the DB $sZ = ; // start the symmetric key string $aZ = Encryption::getKeys( ); // retrieve the symmetric keys foreach($aZ as $aCodes) { $sZ .= :.$aCodes[skey_key]; // append to symmetric key string } ?>

[0068] 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:

TABLE-US-00014 <?php // Get only the symmetric keys from the keys table public static function getKeys( ) { $sql = SELECT skey_index, skey_key FROM DB.skeys ORDER BY skey_index; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(getKeys 1: access to DB failed); return false; } if ($oTmp>num_rows < 1) { logError(getKeys 2: got no data); return false; } while ($aKey = $oMySQL>fetchRow($oTmp, FETCHMODE_ASSOC)) { $iKeyId = $aKey[skey_index]; $aKeys[$iKeyId] = $aKey[skey_public]; } return $aKeys; } // end function getKeys ?>
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:

TABLE-US-00015 <?php // Delete the key at iIndex from the symmetric keys table protected static function deleteIndex($iIndex = 0) { if (!$iIndex ) { logError(deleteIndex 1: got no iIndex ); return false; } $sql = DELETE FROM DB.skeys WHERE skey_index = \.$iIndex.\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(deleteIndex 2: access to DB failed); return false; } return true; } // end function deleteIndex ?>

[0069] Shown in FIG. 5A is one embodiment of the Initialization Phase of my Indexed Sequencing Process, to be first executed during system boot. In the Initialization Phase of my Indexed Sequencing Process, Server 12 generates a keys table, K, comprising an enumerated plurality, P, of symmetric keys, K.sub.p. For this example, let us assume that K is generated by Server 12 and transmitted to Client 16 using the code snippets discussed above. However, in this embodiment, Server 12 generates the OTP such that it comprises a plurality, N, of unique indicies, I, into K, using, for example, the following:

TABLE-US-00016 <?php // Generate a new index table $iMaxIndexs = 512; // total number of indexs in I $iIndexs = 0; // initialize index counter do { $iIndex = (int) mt_rand (1, $iMaxIndicies )]; // generate a new index if (!Encryption::_indexExists($iIndex )) // accept if not already in OTP { Encryption::addIndex($iIndex) // add index ++$iIndexs ; // increment index counter } } while ($iIndexs < $iMaxIndexs ); ?>

[0070] 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:

TABLE-US-00017 <?php // Check to see if iIndex already exists in the index table protected static function _indexExists($iIndex = 0) { if (!$iIndex ) { logError(_indexExists 1: got no iIndex ); return false; } $sql = SELECT COUNT(*) FROM DB.index WHERE index_index = \.$iIndex .\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(_indexExists 2: access to DB failed); return false; } $iCnt = (int) $oMySQL>fetchOne($oTmp); return $iCnt; } // end function _indexExists ?>
Further, by way of example, the public class function addIndex may be implemented as follows:

TABLE-US-00018 <?php // Add a new index to the index table public static function addIndex($iIndex = 0) { if (!$iIndex ) { logError(addIndex 1: got no iIndex ); return false; } $sql = INSERT INTO DB.index ( index_index ) VALUES ( \.$iIndex .\ ); $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(addIndex 2: access to DB failed); return false; } return true; } // end function addIndex ?>

[0071] 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:

TABLE-US-00019 CREATE TABLE index ( index_id int(10) unsigned NOT NULL AUTO_INCREMENT, index_index int(10) NOT NULL PRIMARY KEY (index_id), KEY index_index (index_index) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; [0072] wherein: [0073] the field index-id comprises the index of each index; [0074] the field index-index comprises the index field; [0075] the InnoDB is the particular MySQL ENGINE I have selected; and [0076] the DEFAULT CHARSET I have selected is utf8. [0077] Note that I did not include a datetime field since I consider indexes to be transitory, i.e., time insensitive, but this is certainly a matter of choice. Note also that I instructed the MySQL server to create a second index based on the index_index field, thereby to speed up the deleteIndex function, described below.

[0078] In anticipation of opening the first ssl session with Client 16, Server 12 can retrieve from DB 14 the OTP as follows:

TABLE-US-00020 <?php // Get the OTP from the DB $sI = ; // start the index string $aI = Encryption::getIndexes( ); // retrieve the indexes foreach($aI as $aIndexes) { $sI .= :.$aIndexes[index_index]; // append to index string } ?>

[0079] 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:

TABLE-US-00021 <?php // Get all of the indexes from the index table public static function getIndexes( ) { $sql = SELECT index_id, index_index FROM DB.index ORDER BY index_id; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(getIndexes 1: access to DB failed); return false; } if ($oTmp>num_rows < 1) { logError(getIndexes 2: got no data); return false; } while ($aIndex = $oMySQL>fetchRow($oTmp, FETCHMODE_ASSOC)) { $iIndexId = $aIndex [index_id]; $aIndexes[$iIndexId] = $aIndex [index_index]; } return $aIndexes; } // end function getIndexes ?>
In this example, the public class function deleteIndex should be implemented as follows:

TABLE-US-00022 <?php // Delete the key at iIndex from the index table protected static function deleteIndex($iIndex = 0) { if (!$iIndex ) { logError(deleteIndex 1: got no iIndex ); return false; } $sql = DELETE FROM DB.index WHERE index_index = \.$iIndex.\; $oTmp = $oMySQL>query($sql); if (is_array($oTmp)) { logError(deleteIndex 2: access to DB failed); return false; } return true; } // end function deleteIndex ?>
Thus, during the Initialization Phase, Server 12 pre-shares with Client 16 both the keys table, K.sub.P, and the index-based OTP.

[0080] Shown in FIG. 5B is one embodiment of the Consumption Phase of my Indexed Sequencing Process, to be performed each time Client 16 desires to transmit a packet to Server 12. As can be seen, in the Consumption Phase of my Indexed Sequencing Process, I use the first index, I.sub.n, in the OTP to control the selection of the key K.sub.n in key table K. Both Client 16 and Server 12 then consume the now-used index from the local copies of the OTP.

[0081] 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.

[0082] Shown in FIG. 6A is one embodiment of the Initialization Phase of my Explicit Sequencing Process, to be first executed during system boot. Similar to the Initialization Phase of my Implicit Sequencing Process, Server 12 generates an OTP, comprising an enumerated plurality, Z, of either asymmetric key_pairs, Z.sup.P and Z.sub.P, or symmetric keys, Z.sub.S. However, in this embodiment, Server 12 does not transmit the full OTP to Client 16. Instead, Server 12 randomly selects the index one of the keys, Key.sub.N, in the OTP using the following PHP code snippet:

TABLE-US-00023 <?php // Randomly select a new symmetric key $iMaxIndicies = 1024; // total number of indicies in OTP $bOK = false; do { $iIndex = mt_rand (1, $iMaxIndicies )]; // generate a new index if (Encryption::_indexExists($iIndex )) // accept if still in OTP { Encryption::deleteIndex($iIndex ) // delete index $bOK = true; // exit do loop } } while (!$bOK) ?>

[0083] This first key, let's call it Key.sub.1, 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 FIG. 6B, upon successfully decrypting a first received packet using Key.sub.1, Server 12 will randomly select the next key, Key.sub.2, and transmit it to Client 16. By way of example, let us assume that the Comm channel complies with the well known Transmission Control Protocol/Internet Protocol (TCP/IP) protocol suite. In accordance with this Protocol, the TCP header can be configured, inter alia, to convey to Client 16 an Acknowledgement (ACK) signal from Server 12. In addition, such an ACK signal may be configured to include an Options field of variable width. It is here that I propose to insert the next key, Key.sub.N. In particular, I will configure Server 12 to encrypt each Key.sub.N+i using the immediately preceding Key.sub.N. Further, I will configure Client 16 to use the current key, Key.sub.N, to recover the next key, Key.sub.N+1, from each sequential ACK transaction. Thus, as can be seen, my Explicit Sequencing Process provides end-to-end secure transmission not only of data packets but also of the explicit sequence of keys, both using the basic principle of the OTP protocol.

[0084] In FIG. 7, I have illustrated what I characterize as an Indirect Communication System (ICS) 24. In particular, I have configured this embodiment to support any generic App Server 26, having a local DB 28, and App Client 30, having a local DB 32. By way of example, I have configured my ICS 24 easily to support, inter alia, email service, web browsing, or any other application that relies, in whole or in part, on message traffic transiting a public communication network, such as the Internet. In the illustrated embodiment, I have configured my ICS 24 to practice my Implicit Sequencing Process, as I have described above. However, in my ICS 24, I have interposed an anonymous File Transfer Protocol (FTP) Server 34 between Server 26 and Client 30. Since all electronic data (eData) transiting the public Comm channel is fully encrypted using the pre-agreed sequence of public keys, Z.sup.P, all such traffic is fully secured in accordance with the OTP principle. Of course, I could just as easily configure my ICS 24 to use symmetric keys rather than asymmetric key-pairs, as I have explained above. Further, I could also configure the FTP Server 34 to support bi-directional traffic, thereby providing a secure channel whereby Server 26 and Client 30 can be configured to practice either my Direct Sequencing Process or my Explicit Sequencing Process, both as explained above. For example, in the case of Explicit Sequencing, the receiving Server 26 or Client 30 could return to the transmitting Client 30 or Server 26, respectively, the next key/index via a reverse FTP transaction. In one further embodiment, I could configure my FTP Server 34 to instantiate any of my Sequencing processes, and thereby to control, via the ssh channel, the encryption/decryption processes performed within Servers 26 and Client 30.

[0085] As I have illustrated in my indirect system in FIG. 7, it is possible to configure any of my Sequencing Processes such that the Initialization Phase thereof is instantiated in any of Server 12/Client 16 or Server 26/Client 30. In a general form of my Consumption Phases, control of sequencing, if not implicit, can be instantiated in any of the several facilities comprising the end-to-end pathway. Indeed, the facility that controls sequencing can be different from the facility that selectively generates and pre-shares the OTP. Further, this sequencing control facility itself need not be in the direct data transfer path, so long as it is in the transaction control path.

[0086] 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, Key.sub.1, 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 Key.sub.1 to encrypt the first packet. However, before doing so, Client 16 generates a second key, Key.sub.2, and adds it to the packet at a pre-agreed location within the packet frame. Upon receipt and decryption using Key.sub.1, Server 12 is able to recover Key.sub.2 for use with the next packet. When the last packet, N, of a particular message has been successfully transmitted, the last pre-shared key, Key.sub.N, 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.

[0087] 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.

[0088] In general, my OTP cryptography methods share the following characteristics: [0089] 1. During the reiterative Initialization Phase, a key set comprising one or more good keys is generated and securely pre-shared with all interested facilities. [0090] 2. During the reiterative Consumption Phase, the elements comprising the OTP are consumed in accordance with a predetermined, secure sequencing mechanism. [0091] 3. OTP consumption is on a packet-by-packet basis, i.e., each separate, discrete transmission transaction on the non-secure channel instantiated on the public communication network is protected using a different key than all other packets comprising a single message.

[0092] Some important features of my Sequencing Processes include: [0093] 1. Each key in a particular key set is selected in accordance with accepted cryptographic practices. [0094] 2. Pre-sharing can employ any secure channel, including ssh and an existing OTP-protected channel. [0095] 3. Sequencing control can be implicit, direct, explicit, indexed or indirect, or, in some effective combination thereof [0096] 4. Sequencing control can be substantially independent of transmission control.

[0097] 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.

[0098] 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.