System and method for secure end-to-end electronic communications using entropy mutation tables

Abstract

Various implementations described herein include methods and systems for using a variable privacy table to protect electronic communications. A first electronic device obtains a first version of a privacy table and applies a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table. The first electronic device obtains a first message for transmission to a second electronic device that (i) has a copy of the first version of the privacy table and (ii) has access to the predetermined hashing algorithm. The first electronic device generates a primary key based on the second version of the privacy table. The first electronic device encrypts the first message using the primary key to form an encrypted first message and transmits the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device.

Description

[Technical Field]

[0001] Priority and Related Applications

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 175,548, filed April 15, 2021, entitled "System and Method for Secure End-To-End Electronic Communication Using a Privately Shared Table of Entropy," which is a continuation-in-part of U.S. Patent Application No. 17 / 382,282, filed July 21, 2021, entitled "System and Method for Secure End-To-End Electronic Communication Using a Privately Shared Table of Entropy," which is a continuation-in-part of U.S. Patent Application No. 17 / 385,817, filed July 26, 2021, entitled "System and Method for Secure End-To-End Electronic Communication Using a Privately Shared Table of Entropy," which is a continuation-in-part of U.S. Patent Application No. 17 / 988,710, filed November 16, 2022, entitled "System and Method for Secure End-To-End Electronic Communication Using a Mutating Table of Entropy." and "Table of Entropy," each of which is incorporated herein by reference in its entirety.

[0002]

[0002] This application is related to U.S. patent application Ser. No. 16 / 823,286, filed March 18, 2020, entitled "Electromechanical Apparatus, System, and Method for Generating True Random Numbers," the entire contents of which are incorporated herein by reference.

[0003] Technical Data Field

[0003] This application relates generally to secure communications, including but not limited to secure communications using mutation tables of entropy containing random numbers. [Background technology]

[0004] background

[0004] Random number generation is a critical component of computer and Internet security, enabling encrypted end-to-end communications. Problems with security systems that utilize pseudorandom number generators (e.g., seeded computational algorithms or deterministic logic) are well known. For example, the entire random sequence generated by a pseudorandom number generator can be reproduced if the seed value is known, allowing an unauthorized user to defeat the security of the system. Summary of the Invention [Problem to be solved by the invention]

[0005] overview

[0005] Therefore, there is a need for a secure communication method and system that can efficiently and securely transmit information between devices (eg, electronic devices) within the system.

[0006] One way to ensure the integrity and security of a computerized network is to utilize keys created from truly randomly generated numbers (e.g., truly random numbers). Embodiments herein address the problem of providing a secure network by utilizing a privately shared entropy table (e.g., a privacy table) to encrypt and decrypt data transmitted between devices in the secure communications network. The entropy table contains actual (e.g., truly) random numbers. Additionally, the entropy table can be mutated (e.g., with a current digest) to create new values ​​for each entry in the table (e.g., triggered based on a number of uses or a specific period of time). A morph match (e.g., a predetermined hashing algorithm, keyed hash, and / or other cipher) can be distributed to each user of the entropy table (e.g., separately from the distribution of the table) so that each user device can mutate the table in the same way. In some embodiments, the morph match includes one or more ciphers (e.g., an encryption cipher matching a block size of elements).

[0007] In some situations, the use of morph matches improves security and privacy by accounting for the potential theft of entropy tables or the entropy table's current digest. For example, this allows users of entropy tables to migrate to new entropy tables if a security concern arises. In some embodiments, to resynchronize after a sender morphs an entropy table, other users attempt to decrypt messages from the sender, and if the decryption fails, they morph the table using morph matches and attempt to decrypt again. In some embodiments, a version number is stored with each entropy table and transmitted with the message to improve performance of synchronizing entropy tables.

[0008]

[0008] Morphing privacy tables also prevents reverse engineering of encryption keys. For example, consider a scenario where there are hundreds of drones used in a conflict situation. During the conflict, some of the drones may be disabled and captured by a opposing force. The opposing force may potentially reverse engineer the drones and discover the privacy table. In this scenario, the opposing force may potentially only be able to use the privacy table to decrypt / encrypt messages for a specific drone (because each drone has a separate privacy table). Furthermore, the privacy table for a specific drone is likely to be insufficient because the drone owner is likely to morph the privacy table before it can be used for communication by the opposing force.

[0009] In some embodiments, each entropy table is stored with each application that uses it. In some embodiments, a container is used to store one or more entropy tables and one or more morphs of each table (e.g., to reduce real-time processing requirements and improve decryption times). In some embodiments, the container is protected by a key, such as a fingerprint, token, or time-based one-time password (TOTP).

[0010]

[0010] In some embodiments, the random numbers are generated using an electromechanical device that can fit into a traditional data center. In some embodiments, the generated random numbers can be used to provide Entropy-As-A-Service (EAAS). For example, the EAAS can provide random numbers to generate entropy tables that can be privately shared between devices in a secure communication network (e.g., a secure communication system) for secure communication and transmission of information (e.g., data). In some embodiments, the EAAS is provided by a security provider to a third party (e.g., a third-party service provider or third-party server hosting a network or service) to ensure secure data transmission between devices. [Means for solving the problem]

[0011] According to some embodiments, a method is performed on a first electronic device (e.g., a sender device) that (i) obtains a first version of a privacy table comprising N first bits, (ii) applies a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table having N second bits, (iii) obtains a first message for transmission to a second electronic device that (a) has a copy of the first version of the privacy table and (b) has access to the predetermined hashing algorithm, (iv) generates a primary key based on the second version of the privacy table, (v) encrypts the first message using the primary key to form an encrypted first message, and (vi) transmits the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device.

[0012] In some embodiments, a computing device includes one or more processors, a memory, and one or more programs stored in the memory. The programs are configured for execution by the one or more processors. The one or more programs include instructions for performing (or causing to be performed) any of the methods described herein.

[0013] In some embodiments, a non-transitory computer-readable storage medium stores one or more programs configured for execution by a computing device having one or more processors and a memory, the one or more programs including instructions for performing (or causing to be performed) any of the methods described herein.

[0014]

[0014] Thus, the methods and systems disclosed herein provide secure communications utilizing entropy mutation tables containing truly random numbers, which may complement or replace conventional methods for securing communications.

[0015]

[0015] The features and advantages described herein are not necessarily all-inclusive, and in particular, some additional features and advantages will be apparent to those skilled in the art in view of the drawings, specification, and claims provided in this disclosure. Moreover, the language used herein has been selected primarily for readability and instructional purposes, and not to delineate or limit the subject matter described herein.

[0016] BRIEF DESCRIPTION OF THE DRAWINGS

[0016] For a better understanding of the various embodiments described, please refer to the following description of the embodiments in conjunction with the following drawings, in which like reference numerals refer to corresponding parts throughout the figures and specification: [Brief explanation of the drawings]

[0017] [Figure 1]1 illustrates an example secure communication system, according to some embodiments. [Figure 2]

[0018] FIG. 1 is a block diagram of an example electronic device of a secure communication system, according to some embodiments. [Figure 3A]

[0019] 1 illustrates secure communication between two devices of a secure communication system, according to some embodiments. [Figure 3B] 1 illustrates secure communication between two devices of a secure communication system, according to some embodiments. [Figure 3C]

[0020] 10 illustrates generating a primary key based on a map and a privacy table, according to some embodiments. [Figure 4A]

[0021] 1 illustrates an example of an encrypted payload, according to some embodiments. [Figure 4B]

[0022] 1 provides an example of an encrypted live stream, according to some embodiments. [Figure 5]

[0023] An example secure communication system between a drone and a landing station is provided, according to some embodiments. [Figure 6A]

[0024] 1 illustrates secure communication between two devices of a secure communication system, according to some embodiments. [Figure 6B] 1 illustrates secure communication between two devices of a secure communication system, according to some embodiments. [Figure 7A]

[0025] 1 provides an example of an encrypted payload, according to some embodiments. [Figure 7B]

[0025] An example of an encrypted payload is provided, according to some embodiments. [Figure 7C]

[0026] 1 provides example morph matching, according to some embodiments. [Figure 8A]

[0027] 1 provides a flow diagram of a method for secure communication, according to some embodiments. [Figure 8B]

[0027] A flow diagram of a method for secure communication is provided, according to some embodiments. [Figure 8C]

[0027] A flow diagram of a method for secure communication is provided, according to some embodiments. [Figure 9]

[0028] 1 provides a flow diagram of a method for secure communication, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0018] Description of the embodiment

[0029] Reference will now be made to embodiments, examples of which are illustrated in the accompanying drawings. In the following description, numerous specific details are set forth to provide an understanding of the various embodiments described. However, those skilled in the art will appreciate that the various embodiments described may be practiced without these specific details. In other instances, well-known methods, procedures, components, circuits, and networks have not been described in detail as not to unnecessarily obscure aspects of the embodiments.

[0019]

[0030] Entropy (randomness) is critical for a strong cryptosystem. Entropy created using a true random number generator (RNG) provides stronger encryption (e.g., unguessable keys). One-time pads (OTPs) are a strong encryption technique but require a single-use, pre-shared key that is no smaller than the message being sent. The resulting ciphertext is essentially undecipherable as long as the following conditions are met: (i) the key must be at least as long as the plaintext, (ii) the key must be random, (iii) the key must never be reused, in whole or in part, and (iv) the key must be kept completely secret by both parties. However, secure key exchange is difficult, especially with OTPs. Because each key must be used only once, key provisioning is cumbersome and a potential security weakness.

[0020]

[0031] As described herein, a privacy table (e.g., a table of entropy) can be used to generate a key. One approach to creating a key using a privacy table includes (1) selecting a point in the privacy table, (2) specifying which bits to extract for the key (e.g., the key spans multiple cells in the table), (3) creating a key and a key map that describes for the receiver how to recreate the key, (4) encrypting a plaintext message with the key to generate ciphertext, and (5) sending the key map and ciphertext to the receiver. In this embodiment, the receiver recreates the key using the key map and its copy of the privacy table, and then decrypts the ciphertext using the recreated key.

[0021]

[0032] As one example, some autonomous vehicles (e.g., drones) and landing stations (sometimes referred to as docking or control stations) use barcodes (e.g., two-dimensional barcodes such as QR codes) to identify each other. However, a problem with static barcodes is that the codes can be copied and used in a fraudulent manner (e.g., to introduce fraudulent drones or landing stations into the system). Dynamic electronic barcodes (e.g., OTP barcodes) help protect against copying, especially if the dynamic barcodes are generated using truly random numbers.

[0022]

[0033] For example, when a drone and a landing station connect, each can display a QR code containing an encrypted authentication message on its (electronic paper) display. The QR code can be generated from a shared privacy table, as described in more detail below. Both the landing station and the drone can then decrypt their respective authentication messages and verify that the other is authorized. Furthermore, after each is authenticated, they can exchange additional secure messages using OTP. However, for example, if a drone fails to authenticate the docking station, it can be programmed to fly away and / or erase its memory (effectively disabling the drone). In situations with multiple drones, each additional drone can have its own privacy table and be provisioned with the docking station. In these situations, the docking station may store multiple privacy tables and have to try several to authenticate a particular drone.

[0023]

[0034] An example authentication message from the drone can include one or more of the drone's serial number, its current status, and the amount of data to be transferred. An example authentication message from the landing station can include one or more of the station's serial number, a radio password, and one or more commands.

[0024]

[0035] Turning now to the figures, Figure 1 is a block diagram of a secure communication system 100 (e.g., a secure communication network) according to some embodiments. Secure communication system 100 includes multiple devices (e.g., electronic devices such as devices 110, 120, 130, and 140) that can securely communicate with one another. Secure communication system 100 includes electronic device 110, electronic device 120, and secure log 112. In some embodiments, secure communication system 100 includes additional devices, such as electronic devices 130 and 140, that can communicate with other devices in secure communication system 100. In this example, electronic device 110 is shown as being capable of communicating with multiple devices (e.g., devices 120, 130, or 140).

[0025]

[0036] In some embodiments, data transmitted to and / or from electronic device 110 is stored in secure log 112. In some embodiments, secure log 112 is a blockchain ledger used to record all data sent and / or received at electronic device 110. In some embodiments, secure log 112 is a permissioned blockchain network. In some embodiments, secure log 112 is stored on a separate electronic device from electronic device 110. For example, secure log 112 may be stored on a computer system or a server system.

[0026]

[0037] Secure communication system 100 may include any number of devices and may be directed to any application field. For example, secure communication system 100 may include one or more IoT devices, such as a smartphone, a smart appliance (e.g., a smart refrigerator or smart thermostat), a smart fire alarm, a smart doorbell, a smart lock, a smart machine (e.g., a smart car, a smart bicycle, or a smart scooter), a smart wearable device (e.g., a smart fitness tracker or a smart watch), smart lighting (e.g., a smart light bulb or a smart plug), a smart assistant device, and a smart security system (e.g., a smart camera, a smart pet monitor, or a smart baby monitor). For example, a user with a smartphone may have applications that communicate with a smart refrigerator, a smart thermostat, one or more smart light bulbs, and a smart watch. Each of these smart devices (e.g., IoT devices) is capable of communicating with the smartphone via secure communication system 100 using the methods described herein.

[0027]

[0038] FIG. 2 is a block diagram of a computer system 200 according to some embodiments. In some embodiments, electronic device 110 in FIG. 1 is an example of computer system 200. Computer system 200 includes one or more processors 210 (e.g., CPUs, microprocessors, or processing units), a communication interface 212, memory 220, and one or more communication buses 214 (sometimes referred to as a chipset) for interconnecting these components. In some embodiments, computer system 200 includes or communicates with a random number generation system 216 configured to generate random numbers and provide the random numbers to computer system 200 (e.g., to devices in the computer system, such as electronic device 110). In some embodiments, random number generation system 216 includes a random number generation device and one or more modules for controlling the random number generation device and recording the generated random numbers. For example, the random number generation device may be a physical random number generation device, and the one or more modules may include an image processor for processing images from the physical random number generation device. An example of a random number generation device is disclosed in U.S. Patent Application No. 16 / 823,286, filed March 18, 2020, which is incorporated herein by reference in its entirety.

[0028]

[0039] In some embodiments, memory 220 in computer system 200 includes high-speed random-access memory such as DRAM, SRAM, DDR SRAM, or other random-access solid-state memory devices. In some embodiments, memory includes non-volatile memory such as one or more magnetic disk storage devices, one or more optical disk storage devices, one or more flash memory devices, or one or more other non-volatile solid-state storage devices. The memory, or alternatively the non-volatile memory therein, includes a non-transitory computer-readable storage medium. In some embodiments, the memory or the non-transitory computer-readable storage medium of the memory stores the following programs, modules, and data structures, or a subset or superset thereof: · Operational logic 222, which includes procedures for handling various basic system services and performing hardware-dependent tasks. A communications module 224 that cooperates with the communications interface 212 to couple to and / or communicate with remote devices and systems (e.g., the random number generation system 216, the database 240, and / or other wearable, IoT, or smart devices). A request processing module 226 that processes requests for random number generation. A privacy table module 228 that manages privacy tables (also called tables of entropy or entropy tables). In some embodiments, the privacy table module 228 generates, stores, transforms, and transmits tables. In some embodiments, the privacy table module 228 includes: A table generation module 229 that generates a privacy table (e.g., including random numbers) based on information received from the random number generation system 216. In some embodiments, the privacy table is generated using an entropy block that includes random numbers. A table morphing module 231 that transforms the privacy table according to a morph match (e.g., a predefined hashing algorithm). In some embodiments, the table morphing module 231 maintains and / or deletes privacy table versions according to a morph match (or user or system preference setting). A map generation module 230 that generates a map (eg, an encoding / decoding map) based on the privacy table. A primary key generation module 232 that generates a primary key based on the map and the privacy table. In some embodiments, generating the primary key includes applying a digest function to the string. An encryption module 234 that encrypts messages (e.g., data or text) to be transmitted. For example, the encryption module 234 may encrypt patient information before transmitting the patient information to an electronic device 120 that communicates with a device (e.g., electronic device 110) of the computer system 200. In some embodiments, the encryption module 234 encrypts the message using a primary key generated by the primary key generation module 232. A decryption module 236 that decrypts messages (e.g., data or text) received from other devices in communication with devices in computer system 200. For example, decryption module 236 may generate (e.g., recreate) an associated primary key based on the received information and use the primary key to decrypt the message. A database 240 storing: o Previously generated random numbers 242 (e.g., stored as a sequence of 8-bit bytes, 64-bit blocks, or 256-bit blocks). This is also called the entropy cache. In some embodiments, entropy in the privacy table is not reused. Data 244 sent and / or received by devices (such as electronic device 110) of computer system 200. In some embodiments, data 244 is transmitted to secure log 112. Blockchain information (e.g., ledger) 246 for privacy tables obtained (e.g., generated or received) via privacy table module 228.

[0029]

[0040] In some embodiments, computer system 200 is a computing device that executes an application (e.g., an entropy application) to process data (e.g., random numbers) from random number generation system 216. In some embodiments, computer system 200 sends an instruction to database 240 using communication interface 212 to retrieve random number 242 (e.g., from an entropy cache). In response to receiving the instruction, database 240 may return random number 242 via interface 212. In some embodiments, random numbers 242 stored in database 240 are associated with one or more random numbers generated by random number generation system 216.

[0030]

[0041] Computer system 200 may be implemented as any type of computing device, such as an integrated system-on-chip, a microcontroller, a console, a desktop or laptop computer, a server computer, a tablet, a smartphone, or other mobile device. Accordingly, computer system 200 includes components common to typical computing devices, such as a processor, random access memory, storage devices, network interfaces, I / O interfaces, etc. The processor may be or include one or more microprocessors or application-specific integrated circuits (ASICs). Memory may include RAM, ROM, DRAM, SRAM, and MRAM, and may include firmware, such as static data or fixed instructions, BIOS, system functions, configuration data, and other routines used during operation of the computing device and processor. Memory also provides storage for data and instructions associated with applications and data handled by the processor.

[0031]

[0042] A storage device provides non-volatile, large-capacity, or long-term storage of data or instructions in a computing device. A storage device may take the form of a magnetic or solid-state disk, tape, CD, DVD, or other reasonably large-capacity addressable or serial storage medium. Multiple storage devices may be provided or available to a computing device. Some of these storage devices may be external to the computing device, such as network storage or cloud-based storage. A network interface includes an interface to a network and can be implemented as either a wired or wireless interface. An I / O interface connects the processor to peripherals (not shown), such as sensors, displays, cameras, color sensors, microphones, keyboards, and / or USB devices.

[0032]

[0043] Attention now turns to an embodiment of the secure transmission of data between devices of the secure communication system 100.

[0033]

[0044] 3A-3C illustrate secure communication between two devices (e.g., electronic devices 302 and 304, two different devices) of secure communication system 100, according to some embodiments. Each of electronic devices 302 and 304 may be an example of electronic device 110, 120, 130, or 140, or an electronic device associated with secure log 112 shown in FIG. 1. For example, first electronic device 302 may correspond to first electronic device 110, and second electronic device 304 may correspond to second electronic device 120, or vice versa. In another example, first electronic device 302 may correspond to first electronic device 110, and second electronic device 304 may correspond to an electronic device that is part of a computer system or server system that stores secure log 112, or vice versa.

[0034]

[0045] If the secure communication system 100 includes a medical network, each of the electronic devices 302 and 304 may correspond to any of a patient device, a device of a remote monitoring system, a device associated with a database, or a device associated with a medical provider (e.g., a doctor, clinic, or hospital). If the secure communication system 100 includes a drone network, each of the electronic devices 302 and 304 may correspond to any of a drone, a landing station, a control station, or a device associated with a drone facility.

[0035]

[0046] The electronic device 302 stores a privacy table 310 (e.g., a table of entropy) consisting of random bits. The electronic device 302 transmits the privacy table 310 to the electronic device 304 over an encrypted channel (operation 1), and the electronic device 304 stores the transmitted privacy table 310. The electronic device 302 generates a map 312 (e.g., an encoding / decoding map 312) (operation 2) and generates a primary key 316 (e.g., a cryptographic key) based on the map 312 (e.g., values ​​in the map 312) and the random numbers (e.g., bits) stored in the privacy table 310 (operation 3a). In some embodiments, the electronic device 302 also generates a challenge string 314 based on the primary key 316 (operation 3b) (e.g., the challenge string 314 is derived from the primary key 316). In some embodiments, the challenge string 314 is transmitted from the electronic device 302 to the electronic device 304 separately from the map 312, the primary key 316, and the encrypted message (e.g., transmitted out-of-band) and used by the electronic device 304 to verify that the primary key 316 was correctly reproduced and that the transmitted information is authentic. In some embodiments, the electronic device 302 applies a digest function (e.g., SHA256) to the primary key 316 to generate the challenge string 314 (act 3b). For example, the primary key 316 is a digest, such as a SHA256 digest, of the challenge string 314.

[0036]

[0047] In some embodiments, map 312 includes information regarding how to use privacy table 310 to generate primary key 316 and / or challenge string 314. For example, values ​​in map 312 correspond to any of a starting position in the privacy table, an offset value, and a read direction. Additional details regarding map 312 are provided below with respect to FIGS. 4A and 4B . In some embodiments, map 312 is generated using a subset or part (but not all) of the random numbers (e.g., bits) stored in privacy table 310. In some embodiments, primary key 316 and challenge string 314 are generated using a subset or part (but not all) of the random numbers (e.g., bits) stored in privacy table 310. In some embodiments, map 312 does not include information (e.g., an identifier) ​​regarding which privacy table it is associated with (e.g., from which it is generated).

[0037]

[0048] The electronic device 302 encrypts (operation 4) a first message 320 (e.g., data) using the primary key 316 to form an encrypted first message 322. For example, the electronic device 302 may use a symmetric cipher, such as AES-256 (which is a symmetric cipher that encrypts in blocks of 256 bits), to encrypt the first message 320. The electronic device 302 generates (operation 5) an encrypted payload 324 (also referred to as ciphertext) that includes the map 312 and the encrypted first message 322. In some embodiments, the encrypted payload 324 includes the map 312 prepended to the encrypted first message 322. In some embodiments, such as when a symmetric cipher is used, the primary key 316 is a symmetric key (e.g., the same primary key can be used to encrypt a message to form an encrypted message and to decrypt the encrypted message to recover the original message). Examples of encrypted payload 324 are provided with respect to FIGS. 4A and 4B . Examples of symmetric ciphers include (without limitation): AES, Blowfish, RC4, Twofish, Serpent, Camellia, Salsa20, ChaCha20, CAST5, Kuznyechik, DES, 3DES, Skipjack, Safer, and IDEA. In some embodiments, the cipher used to encrypt a message is identified (e.g., selected) based on the period for which the information stored in the message is required to remain secure. For example, if the information stored in the encrypted message will expire (e.g., become irrelevant) within 30 seconds, a first symmetric cipher (e.g., RC4) may be used to encrypt the message. In contrast, if the information stored in the encrypted message is required to remain secure for a long period of time (e.g., months, years, or forever), a different symmetric cipher may be used to encrypt the message.

[0038]

[0049] Electronic device 302 transmits encrypted payload 324 (including map 312 and encrypted first message 322) to electronic device 304 (operation 6). Because the message is encrypted, the transmission does not need to be over an encrypted or secure channel. Encrypted payload 324 is transmitted (in operation 6) at a time different from the transmission time of privacy table 310 (in operation 1). For example, encrypted payload 324 is transmitted subsequent to the transmission of privacy table 310 (e.g., privacy table 310 is transmitted as part of a payload different from encrypted payload 324).

[0039]

[0050] Electronic device 304 receives encrypted payload 324 (including map 312 and encrypted first message 322) from electronic device 302 and reads (e.g., extracts or identifies) map 312 (e.g., encoding / decoding map) from encrypted payload 324 (operation 7). Electronic device 304 then uses information from map 312 and privacy table 310 to reconstruct challenge string 314 (e.g., to generate reconstructed challenge string 314′) and primary key 316 (e.g., to generate reconstructed primary key 316′) (operation 8). In some embodiments, challenge string 314 is derived from primary key 316 (and thus reconstructed challenge string 314′ can be derived from reconstructed primary key 316′). In some embodiments, reconstructed challenge string 314′ is the same (e.g., identical) as challenge string 314. The electronic device 304 uses the reproduced challenge string 314′ to verify the primary key 316 (operation 9) (e.g., to generate a reproduced primary key 316′) and uses the reproduced primary key 316′ to decrypt the encrypted first message 322 in the encrypted payload 324 (operation 10) to form a decrypted first message 326. The electronic device 302 then uses the reproduced primary key 316′ to initialize a decryption protocol (e.g., a decryption algorithm such as AES256) that corresponds to the encryption protocol used to encrypt the message and decrypts the encrypted first message 322 to form the decrypted first message 326.

[0040]

[0051] In some embodiments, the reproduced primary key 316′ is the same as (e.g., identical to) the primary key 316. In some embodiments, such as when the first message 320 is encrypted using a symmetric cipher (such as AES-256), the encrypted first message 322 can be decrypted using the reproduced primary key 316′ that is identical to the primary key 316 used to encrypt the first message 320 to form the encrypted first message 322.

[0041]

[0052] 3A (e.g., acts 2-10) is repeated for each new message sent from electronic device 302 to electronic device 304. As shown in FIG. 3B, for transmission of second message 340, electronic device 302 generates a new map 332 (e.g., encoding / decoding map 332) for second message 340 such that second message 340 is encrypted based on (e.g., with) a new primary key 336 that is different (e.g., distinct) from the primary key 316 used to encrypt first message 320 (e.g., the previously transmitted message). The process described in FIG. 3A (e.g., acts 1-10) is cipher-agnostic and can be implemented using any encryption protocol (and any decryption protocol).

[0042]

[0053] 3B illustrates a process for securely transmitting a second message 340, which is different from the first message 320, from the electronic device 302 to the electronic device 304. The electronic device 302 generates a new map 332 (e.g., encoding / decoding map 332) that is different (e.g., distinct) from the map 312 (operation 11). The electronic device 302 also generates a new primary key 336 (e.g., encryption key) based on the map 312 and random numbers (e.g., bits) stored in the privacy table 310 (operation 12a). In some embodiments, the electronic device 302 generates a new challenge string 334 from the primary key 336 (operation 12b). Because the new map 332 is different from the map 312, the new primary key 336 is different (e.g., distinct) from the primary key 316, and the new challenge string 334 is different (e.g., distinct) from the challenge string 314.

[0043]

[0054] The electronic device 302 encrypts (act 13) the second message 340 (e.g., data) using the primary key 336 to form an encrypted second message 342. The electronic device 302 generates (act 14) a new encrypted payload 344 that includes the new map 332 and the encrypted second message 342. In some embodiments, the new encrypted payload 344 includes the map 332 prepended (or appended) to the encrypted second message 342.

[0044]

[0055] Electronic device 302 transmits (e.g., over an encrypted channel) new encrypted payload 344 (including new map 332 and encrypted second message 342) to electronic device 304 (operation 15). New encrypted payload 344 is transmitted (in operation 15) at a time different from the time of transmission of privacy table 310 (in operation 1) and at a time different from the time of transmission of encrypted payload 324 (in operation 6).

[0045]

[0056] The electronic device 304 receives the new encrypted payload 344 (including the new map 332 and the encrypted second message 342) from the electronic device 302 and reads (e.g., extracts or identifies) the new map 332 from the new encrypted payload 344 (act 16). The electronic device 304 then uses the new map 332 and information from the privacy table 310 to reconstruct the new primary key 336 (act 17) (e.g., generate a reconstructed new primary key 336'). In embodiments in which the electronic device 304 receives the new challenge string 334, the electronic device 304 reconstructs the challenge string 334 (e.g., generate a reconstructed challenge string 334') using information from the new map 332. In some embodiments, the electronic device 304 verifies the new primary key 336 using the reconstructed challenge string 334' (act 18). The electronic device 304 decrypts the second encrypted message 342 in the new encrypted payload 344 using the recovered primary key 336 ′ (act 19 ) to form a decrypted second message 346 .

[0046]

[0057] In some embodiments, the electronic device updates the privacy table 310 with the new privacy table, which may be transmitted using the secure message transmission process described above with respect to Figures 3A and 3B.

[0047]

[0058] In some embodiments, a privacy table, such as privacy table 310, is generated by random number generation system 216. In some embodiments, the privacy table is generated by computer system 200 (e.g., by a device of computer system 200, such as electronic device 302) using random numbers generated by random number generation system 216. In some embodiments, generating the privacy table includes identifying the number of keys needed for a predetermined period of time and identifying the size of the privacy table based on the number of keys needed. In some embodiments, the predetermined period of time corresponds to a time interval (e.g., a predetermined time interval) for refilling the privacy table. The size of the new privacy table may be the same as the size of the old privacy table or may be different (e.g., the same for the same needs or different for different anticipated needs). In some embodiments, the privacy tables stored on devices (e.g., devices 302 and 304) of secure communication system 100 are updated (e.g., replenished) at predetermined intervals (e.g., after a predetermined period of time). In some embodiments, updating a privacy table includes updating (e.g., refilling) the entire privacy table (e.g., replacing all random numbers (e.g., bits) stored in the privacy table with new random numbers (e.g., new bits)). In some embodiments, updating a privacy table includes updating (e.g., refilling) a subset or some (but not all) of the random numbers (e.g., bits) in the privacy table. In some embodiments, only random numbers (e.g., bits) that have been used (e.g., read) are replaced (e.g., refilled), and other numbers stored in the privacy table that are not being used remain unchanged.

[0048]

[0059] 3C illustrates generating a primary key 316 based on a map (e.g., encoding / decoding map 312) and a privacy table (e.g., privacy table 310) according to some embodiments. Map 312 is generated based on random numbers (e.g., bits) stored in privacy table 310 (operation 2a). In some embodiments, generating map 312 includes identifying a starting position and a reading direction (e.g., spin) within privacy table 310. In some embodiments, the starting position is randomly selected (e.g., using a pseudo-random number generator). In some embodiments, the reading direction is randomly selected (e.g., using a pseudo-random number generator). Map 312 is generated by reading random numbers (e.g., bits) in privacy table 310 starting from the starting position and reading random numbers (e.g., bits) stored in privacy table 310 in the reading direction.

[0049]

[0060] A primary key 316 is generated (act 3a) based on values ​​in map 312 (e.g., random numbers comprising map 312) and random numbers (e.g., bits) stored in privacy table 310. In some embodiments, a challenge string 314 is generated based on (e.g., derived from) primary key 316 (act 3b). Primary key 316 is used to encrypt a message (act 4b). For example, to encrypt a message, electronic device 302 may initialize an encryption protocol (e.g., an encryption algorithm such as AES256) that uses primary key 316 to encrypt the message and form the encrypted message.

[0050]

[0061] In some embodiments, the process of securely transmitting an encrypted message 322 includes generating an initialization vector 350 (operation 4a) and encrypting the message 320 using the initialization vector 350 in conjunction with a primary key 316. For example, if the transmitted message 322 is part of a live stream that includes multiple consecutive transmissions of messages (or multiple consecutive transmissions of payloads 324), each message is encrypted using a unique primary key 316, which in some embodiments also includes a unique initialization vector 350. In some embodiments, the initialization vector 350 (if included) is automatically updated (e.g., a new initialization vector 350 is automatically created) for each new message 320 that is encrypted.

[0051]

[0062] In some embodiments, electronic device 302 shares a particular privacy table with no more than one device (e.g., privacy table 310 is shared with only electronic device 304). In such a case, if electronic device 302 needs to securely communicate with multiple different devices (e.g., with electronic device 304 and at least one other electronic device different from electronic device 304), electronic device 302 stores multiple privacy tables such that messages transmitted to different devices are encrypted based on (e.g., using) different privacy tables. For example, a primary key used to encrypt a message transmitted to electronic device 302 is generated based on the map and a first privacy table, and a primary key used to encrypt a message transmitted to another electronic device different from electronic device 302 (which may be the same message or a different message) is generated based on the map and a second privacy table different from the first privacy table. In some embodiments, electronic device 302 shares the same privacy table with two or more devices. For example, electronic device 302 may share the same privacy table with electronic device 304 and two other devices. In such a case, all of the devices that store the privacy tables (e.g., electronic device 302, electronic device 304, and the two other devices) may communicate securely with each other via the secure communication process described above with respect to Figures 3A-3C.

[0052]

[0063] Figure 4A shows an example of an encrypted payload 324, according to some embodiments. In Figure 4A, encrypted payload 324-A includes encrypted first message 322 and map 312. For example, encrypted payload 324-A is a concatenation of encrypted first message 322 and map 312. Values ​​(e.g., numbers) in map 312 are represented in Figure 4A by the letters "A" through "G." Map 312 is prepended to encrypted first message 322 of Figure 4A, according to some embodiments.

[0053]

[0064] In some embodiments, map 312 is used to generate challenge string 314 and thus includes multiple values ​​corresponding to instructions or directions on how to use the privacy table to generate (or reproduce) the challenge string. For example, map 312 includes one or more of the following: A random value (e.g., a number) corresponding to a starting point in the privacy table, represented by the letter "A". A value (e.g., a number) corresponding to the horizontal offset from the starting point in the privacy table, represented by the letter "B". A value (e.g., positive or negative) corresponding to the horizontal reading direction from the starting point in the privacy table. A value (e.g., a number) corresponding to the vertical offset from the starting point in the privacy table, represented by the letter "C". A value (e.g., positive or negative) corresponding to the vertical reading direction from the starting point in the privacy table. A value (e.g., a number) corresponding to the size (e.g., size permutation) of the privacy table in the horizontal direction, represented by the letter "D". A value (e.g., a number) corresponding to the size (e.g., size permutation) of the privacy table in the vertical direction, represented by the letter "E." A value (e.g., a number) corresponding to a starting point in the privacy table (e.g., in a permutation), represented by the letter "F." In some embodiments, the value corresponding to a starting point in the privacy table is limited by the size of the privacy table. In some embodiments, the value corresponding to a starting point in the privacy table is generated by a pseudo-random number generator. The length of the challenge string used to generate the primary key, represented by the letter "G." In some embodiments, the length of the challenge string is based on the size of the primary key (which may be, for example, 246 bits of 32 bytes in length).

[0054]

[0065] In some embodiments, the random value "A" is generated (e.g., provided) by a pseudo-random number generator. In some embodiments, the random value "A" is selected from a set of values ​​that is determined based on the size of the privacy table 310. For example, if the privacy table 310 is a two-dimensional matrix having a size of 100 x 50 (e.g., "D" = 100 and "E" = 50) and storing a total of 5,000 values, then 0≦A≦5,000.

[0055]

[0066] The privacy table 310 can contain any number of random numbers. In some embodiments, the privacy table 310 consists of as few as 256 bits. In some embodiments, the privacy table 310 contains 10,000 or more random bits. In some embodiments, the size of the privacy table 310 is specified based on the expected use of the privacy table. For example, if the privacy table 310 has an expected use of a few seconds (e.g., as part of a process for encrypting audio between two parties), a small size privacy table 310 is appropriate.

[0056]

[0067] For a privacy table 310 containing 10,000 bits, generating a map 312 may include any of the following: Obtaining a random value “A” using a pseudo-random number generator, where 1≦A≦10,000. In this example, A=2,544. Obtaining a random value "B" corresponding to a horizontal offset from a starting point in the privacy table, where 1≦B≦10,000. In some embodiments, "B" is obtained via a pseudo-random number generator. Obtaining a randomly determined direction corresponding to the horizontal reading direction (e.g., positive reading direction or negative reading direction). Obtaining a random value "C" corresponding to a vertical offset from a starting point in the privacy table, where 1≦C≦10,000. In some embodiments, "C" is obtained via a pseudo-random number generator. Obtaining a randomly determined direction corresponding to a perpendicular reading direction (e.g., a positive reading direction or a negative reading direction). Calculating a horizontal permutation value “D” corresponding to the size of the privacy table 310 in the horizontal direction. For example, the horizontal permutation value is determined (e.g., calculated) by sorting through all values ​​between 1 and the size of the privacy table in the horizontal direction. Calculating a vertical permutation value “E” corresponding to the size of the privacy table 310 in the vertical direction. For example, the vertical permutation value is determined (e.g., calculated) by permuting through all values ​​between 1 and the size of the privacy table in the vertical direction.

[0057]

[0068] 4B provides an example of a live stream 360, according to some embodiments. The live stream 360 includes multiple encrypted payloads 410 transmitted consecutively (e.g., sequentially) after one another. Each encrypted payload 410 of the multiple encrypted payloads includes a respective encrypted message 364 corresponding to a portion of the live stream 360 and a respective map 312 (represented by the letters "A" through "G") corresponding to a respective primary key 316 used for the respective encrypted message 364. In some embodiments, the encrypted payloads 410 include a respective initialization vector 350 (represented by "H") that is used in combination with the respective primary key 316 to form the respective encrypted message 364. This example illustrates the transmission of two encrypted messages 364-1 and 364-2 corresponding to the first two messages of the live stream 360. A transmission of a first payload 410-1 (e.g., encrypted payload) includes a first encrypted message 364-1 ("Encrypted Message 1") and a map 312-1 (e.g., encoding / decoding map) (e.g., "A1" through "G1," each representing a numerical value as described with respect to FIG. 4A) corresponding to the first encrypted message 364-1. In some embodiments, the first payload 410-1 includes an initialization vector 350-1 (e.g., "H1") corresponding to the first encrypted message 364-1. For example, the encrypted payload 410-1 (also referred to as ciphertext) is a concatenation of the encrypted message 364-1, the map 312-1, and any initialization vector 350-1. In some embodiments, the map 312-1 is prepended to the encrypted first message 364-1, as shown. In some embodiments, the optional initialization vector 350-1 is added to the end of the encrypted first message 364-1 (e.g., the optional initialization vector 350-1 is added to the end or after the encrypted message 364-1).

[0058]

[0069] A second payload 410-2 (e.g., an encrypted payload) immediately following the first payload 410-1 is transmitted (and ideally received) consecutively to the transmission (and reception) of the first payload 410-1. The transmission of the second payload 410-2 includes a second encrypted message 364-2 ("Encrypted Message 2") and a map 312-2 (e.g., an encoding / decoding map) corresponding to the second encrypted message 364-2 (e.g., "A2" through "G2," each representing a numerical value as described with respect to FIG. 4A). In some embodiments, the second payload 410-2 also includes an initialization vector 350-2 (e.g., "H2") corresponding to the second encrypted message 364-2. Additional messages 364 for the live stream 360 can continue to be transmitted (and received) in this manner until the end of the live stream 360.

[0059]

[0070] Thus, in some embodiments, the process of encrypting a message that is part of a live stream includes generating an initialization vector 350, generating a challenge string 314, and generating a primary key 316. When used to encrypt a message in a live stream, an example initialization vector 350 is "58, 148, 100, 27, 59, 184, 8, 236, 189, 24, 21, 6, 113, 162, 244, 26, 59, 72, 222, 95, 188, 247, 143, 118, 97, 168, 187, 147, 24, 153, 96, 130," and the challenge string An example of a column 312 is "FFFBFCCFEFFADAFFFFFBFFEFFFCEFFFF" and an example of a primary key 316 is "186, 3, 235, 211, 177, 202, 35, 167, 225, 195, 16, 151, 164, 71, 93, 47, 2, 114, 233, 26, 143, 119, 31, 103, 185, 88, 203, 62, 3, 43, 175, 85".

[0060]

[0071] FIG. 5 illustrates an example secure communication system 100 between a drone and a landing station, according to some embodiments. The secure communication system 100 in FIG. 5 includes a drone 502 (e.g., electronic device 302) and a landing station 508 (e.g., electronic device 304). The drone 502 includes a drone sensor 506 (e.g., a camera or optical sensor) and a drone electronic barcode 504 (e.g., a two-dimensional barcode such as a QR code). The landing station 508 includes a station sensor 510 (e.g., a camera or optical sensor) and a station electronic barcode 512. According to some embodiments, each of the sensors 506 and 510 is configured to identify and scan the respective barcodes 504 and 512. In some embodiments, each electronic barcode 504 and 512 is configured to display an encrypted payload (e.g., encrypted payload 324). In some embodiments, the encrypted payload presented via the drone electronic barcode 504 includes an identifier for the drone 502. In some embodiments, the encrypted payload presented via station electronic barcode 512 includes an identifier for landing station 508. In some embodiments, the encrypted payload presented via electronic barcodes 504 and 512 is encrypted using a shared privacy table (e.g., as discussed in more detail below with respect to Figures 6A and 6B).

[0061]

[0072] 6A and 6B illustrate secure communication between two devices (e.g., electronic devices 302 and 304, two different devices) of secure communication system 100, according to some embodiments. Figure 6A illustrates example operations occurring at first electronic device 302, and Figure 6B illustrates corresponding example operations occurring at second electronic device 304.

[0062]

[0073] As shown in FIG. 6A , the first electronic device 302 stores a privacy table 310 (e.g., a first version of the privacy table) comprised of random bits and associated morph matches 602. According to some embodiments, the morph match 602 includes instructions for morphing the privacy table 310. In some embodiments, the morph match 602 includes a predetermined hashing algorithm (e.g., a secure hash algorithm or a message digest algorithm). In some embodiments, the morph match 602 includes information or instructions regarding how often to morph the privacy table 310 (e.g., based on elapsed time or number of messages sent). In some embodiments, the morph match 602 includes one or more parameters that can be set by a user to adjust how the privacy table is morphed. For example, a user can request a morphing of the privacy table and enter a parameter value to set the type of hashing algorithm used to morph the privacy table.

[0063]

[0074] In some embodiments, the first electronic device 302 stores a first version 603 for the privacy table 310 (e.g., the first version 603 indicates that the privacy table 310 is the first version of the privacy table generated). In some embodiments, the first version 603 is an indication of the number of times the privacy table has been transformed (e.g., a value that is initialized to 0 or 1). In some embodiments, the first version 603 is included with the privacy table 310 (e.g., the privacy table includes a value in addition to a random bit that indicates its version). In some embodiments, the first version 603 is stored in the blockchain ledger for the privacy table 310 (e.g., in the secure log 112). In some embodiments, the first version 603 is not stored (or included) in the electronic device 302, and the privacy table 310 does not have an indicator of its version. In embodiments that do not use the first version 603, the receiver (e.g., the second electronic device 304) mutates the privacy table until it can recreate the primary key (e.g., by trial and error using different versions of the privacy table until a match is found).

[0064]

[0075] The first electronic device 302 transmits the morph matches 602 over an encrypted channel to the second electronic device 304 (operation 1). The second electronic device 304 separately transmits the privacy table 310 over an encrypted channel to the second electronic device 304 (operation 2). In some embodiments, the first electronic device 302 transmits the morph matches 602 and the privacy table 310 to the second electronic device 304 in the same transmission.

[0065]

[0076] The first electronic device 302 generates (operation 3) a map 312 (e.g., an encoding / decoding map) and a primary key 316 (e.g., an encryption key) based on the map 312 (e.g., values ​​in the map 312) and random numbers (e.g., bits) stored in the privacy table 310. In some embodiments, the primary key 316 is a digest, such as a SHA256 digest, of the challenge string (e.g., as described above with respect to FIG. 3A).

[0066]

[0077] In some embodiments, map 312 includes information regarding how to use privacy table 310 to generate primary key 316. For example, values ​​in map 312 may correspond to any of a starting position in the privacy table, an offset value, and a read direction. Additional details regarding map 312 are provided above with respect to FIGS. 4A and 4B . In some embodiments, map 312 is generated using a subset or less than all of the random numbers (e.g., bits) stored in privacy table 310. In some embodiments, primary key 316 is generated using a subset or less than all of the random numbers (e.g., bits) stored in privacy table 310. In some embodiments, map 312 does not include information (e.g., an identifier) ​​regarding which privacy table it is associated with (e.g., from which it is generated).

[0067]

[0078] The electronic device 302 encrypts (operation 4) the first message 320 (e.g., data) using the primary key 316 to form an encrypted message 322. For example, the electronic device 302 may use a symmetric cipher, such as AES-256 (which is a symmetric cipher that encrypts in 256-bit blocks), to encrypt the message 320. The first electronic device 302 generates (operation 5) an encrypted payload 324 (also referred to as ciphertext) that includes the map 312 and the encrypted message 322, and, in some embodiments, a first version 603. In some embodiments, the encrypted payload 324 includes the map 312 (and first version 603) prepended or appended to the encrypted message 322. In some embodiments, such as when a symmetric cipher is used, the primary key 316 is a symmetric key. Examples of the encrypted payload 324 are provided with respect to FIGS. 7A and 7B . In some embodiments, the cipher used to encrypt the message is identified (e.g., selected) based on the morph match 602. In some embodiments, the cipher used to encrypt a message is identified (eg, selected) based on the period of time that the information stored in the message is required to remain secure.

[0068]

[0079] The first electronic device 302 transmits the encrypted payload 324 to the electronic device 304 (operation 6). Because the message is encrypted, the transmission need not be over an encrypted or secure channel. For example, in the context of a drone and landing station system, the encrypted payload 324 may be converted into a QR code that is visually displayed on the second electronic device 304. As shown in FIG. 6B , the encrypted payload 324 is transmitted (in operation 6) at a time different from the transmission times of the morph matches 602 (in operation 1) and the privacy table 310 (in operation 2). In some embodiments, the morph matches 602 and the privacy table 310 are transmitted over a first channel (e.g., an encrypted Wi-Fi channel), and the encrypted payload 324 is transmitted over a second channel (e.g., an unencrypted optical channel) that is different from the first channel.

[0069]

[0080] After transmitting the encrypted payload 324, the first electronic device 302 transforms the privacy table 310 based on the morph match 602 (operation 7) to generate a second privacy table 604 (e.g., a second version of the privacy table). In some embodiments, the transformation operation is performed in response to a user request. In some embodiments, the first electronic device 302 transforms the privacy table at the request of a user of the first electronic device 302. In some embodiments, the first electronic device 302 transforms the privacy table based on one or more of the following: the amount of time that has elapsed since the privacy table 310 was generated (or received by the first electronic device 302), the number of messages encrypted / transmitted using the privacy table 310, or one or more settings (e.g., user settings). In some embodiments, the privacy table 310 is transformed using a hashing algorithm defined in the morph match 602. In some embodiments, only a portion of the privacy table 310 is transformed (e.g., the portion of the privacy table 310 that corresponds to the map 312). In some embodiments, the first electronic device 302 stores a second version 607 for the second privacy table 604 (e.g., the second version 607 indicates that the second privacy table 604 is a second version of the generated privacy table). In some embodiments, the second version 607 includes information about the type of transformation that occurred to generate the second privacy table 604. For example, the morph match 602 includes parameters for a user to specify when performing a transformation operation, and the second version 607 includes information about the values ​​set by the user for those parameters. In some embodiments, the second version 607 is not stored (included) in the first electronic device 302, and the second privacy table 604 does not have an indicator of its version.

[0070]

[0081] In some embodiments, after transforming the privacy table 310 to create the second privacy table 604, the privacy table 310 is deleted (or marked for deletion) by the electronic device 302. In some embodiments, the privacy table 310 is maintained by the first electronic device 302 (e.g., to be used for messages received from the second electronic device 304 created by the privacy table 310 stored on the second electronic device 304). In some embodiments, the first electronic device 302 stores the first version of the privacy table 310 and the second version of the second privacy table 604 as blocks in a blockchain ledger (e.g., the privacy table 310 as a genesis block). In some embodiments, the blockchain ledger includes version information 603 and 607. In some embodiments, the blockchain ledger is stored in the secure log 112. In some embodiments, the blockchain ledger is stored in the database 240 (e.g., as blockchain information 246).

[0071]

[0082] In some embodiments, the process described above (e.g., acts 3-6) is repeated for each new message transmitted from the first electronic device 302 to the second electronic device 304, and a morphing operation (act 7) is performed during at least some of the message transmissions.

[0072]

[0083] The first electronic device 302 generates (operation 8) a map 606 (e.g., an encoding / decoding map) and a primary key 608 (e.g., an encryption key) based on the map 606 (e.g., values ​​in the map 606) and random numbers (e.g., bits) stored in the privacy table 604. In some embodiments, the second map 606 is different from the first map 312 (e.g., identifies a different location in the privacy table). In some embodiments, the second map 606 identifies the same location as the first map 312, but the resulting second primary key 608 is different from the first primary key 316 due to the morphing of the tables (in operation 7).

[0073]

[0084] The first electronic device 302 encrypts (act 9) a second message 610 (e.g., data) using the new primary key 608 to form an encrypted message 612. The first electronic device 302 generates (act 10) a new encrypted payload 614 that includes the new map 606 and the encrypted message 612. In some embodiments, the new encrypted payload 614 includes the map 606 (and, in some embodiments, the second version 607) prepended or appended to the encrypted message 612.

[0074]

[0085] The first electronic device 302 transmits (e.g., via an optical barcode) the new encrypted payload 614 (including the new map 606 and the encrypted message 612) to the second electronic device 304 (operation 11). The new encrypted payload 614 is transmitted (in operation 11) at a time different from the transmission time of the first encrypted payload 324 (in operation 6). In some embodiments, the first electronic device 302 waits for a response (e.g., confirmation of receipt of the payload 614 and / or confirmation of decryption of the payload 614) from the second electronic device 304. In some embodiments, following failure of the second electronic device 304 to respond (e.g., within a preset time), the first electronic device 302 returns the second privacy table 604 to the privacy table 310 (e.g., to prevent a mismatch if the second electronic device 304 does not receive the payload 614 with parameters for modifying the privacy table).

[0075]

[0086] 6B, the second electronic device 304 receives (act 12) and stores the morph matches 602 transmitted (in act 1) from the first electronic device 302. The second electronic device 304 also receives (act 13) and stores the privacy table 310 transmitted (in act 2) from the first electronic device 302. As previously described, the morph matches 602 and the privacy table 310 may be transmitted over an encrypted channel (e.g., different from the channel used to transmit the encrypted payload).

[0076]

[0087] The second electronic device 304 receives (act 14) the first encrypted payload 324 (including the map 312, the encrypted message 322, and, in some embodiments, the first version 603) transmitted from the first electronic device 302 (in act 6), reads (e.g., extracts or identifies) the map 312 from the encrypted payload 324 (act 15a), and, in some embodiments, reads the first version 603 (act 15b). In embodiments in which the encrypted message includes the first version 603, the second electronic device 304 verifies (act 16) the version of its privacy table (e.g., the privacy table 310) against the first version 603 to determine whether to modify the privacy table.

[0077]

[0088] The second electronic device 304 uses information from the map 312 and the privacy table 310 to reconstruct the primary key 316 (act 17) (e.g., generate a reconstructed primary key 316'). In some embodiments, the second electronic device 304 generates a challenge string and verifies the reconstructed primary key 316' using the reconstructed challenge string. The second electronic device 304 decrypts the encrypted message 322 from the encrypted payload 324 using the reconstructed primary key 316' (act 18) to form a decrypted first message 326.

[0078]

[0089] In some embodiments, the reproduced primary key 316′ is the same as (e.g., identical to) the primary key 316. In some embodiments, such as when the first message 320 is encrypted using a symmetric cipher (such as AES-256), the encrypted message 322 can be decrypted using the reproduced primary key 316′ that is identical to the primary key 316 used to encrypt the first message 320 to form the encrypted message 322.

[0079]

[0090] At a later point in time, the second electronic device 304 receives (act 19) the encrypted payload 614 (including the map 606, the encrypted message 612, and, in some embodiments, the second version 607) transmitted from the first electronic device 302 (act 11), reads (e.g., extracts or identifies) the map 606 from the encrypted payload 614 (act 20a), and, in some embodiments, reads the second version 607 (act 20b).

[0080]

[0091] In embodiments in which the encrypted message includes second version 607, second electronic device 304 validates its version of its privacy table (e.g., privacy table 310) against second version 607 (operation 21) to determine whether to transform privacy table 310. In these embodiments, second electronic device 304 determines that privacy table 310 is not the correct version and transforms privacy table 310 using morph match 602 to generate a reproduced privacy table 604′ (operation 22). In some embodiments, second version 607 includes information about how to transform privacy table 310 (e.g., including values ​​for one or more parameters in morph match 602). In some embodiments, second version 607 includes information about the number of times to transform privacy table 310. For example, second version 607 indicates that encrypted payload 614 was encrypted with version 2 of the privacy table, and therefore, privacy table 310 should be transformed once.

[0081]

[0092] In embodiments in which the encrypted message does not include the second version 607, the second electronic device 304 generates a primary key using the privacy table 310 and performs verification of the generated primary key. For example, the second electronic device 304 generates a primary key using information from the map 606 and the privacy table 310. However, the primary key generated from the map 606 and the privacy table 310 is invalid (and does not decrypt the encrypted message). In some embodiments, the second electronic device 304 determines that the primary key is invalid (e.g., the challenge strings do not match and therefore the primary key is invalid) by comparing the challenge string from the first electronic device 302 with the challenge string generated by the primary key. In some embodiments, the second electronic device 304 determines that the primary key is invalid based on failing to decrypt the encrypted message. In response to identifying the primary key generated from the map 606 and the privacy table 310 as invalid, the second electronic device 304 morphs the privacy table 310 using morph match 602 to generate a recreated privacy table 604' (operation 22). In some embodiments, the second electronic device 304 repeats the verification described above to identify whether the primary key generated from the recreated privacy table 604' is valid.

[0082]

[0093] The second electronic device 304 uses information from the map 606 and the privacy table 604′ to reconstruct the primary key 608 (act 23) (e.g., generate a reconstructed primary key 608′). The second electronic device 304 uses the reconstructed primary key 608′ to decrypt the encrypted message 612 from the encrypted payload 614 (act 24) to form a decrypted second message 626.

[0083]

[0094] In some embodiments, the process described above (e.g., acts 19-24) is repeated for each new message sent from electronic device 302 (or other device having shared privacy table 310) to electronic device 304.

[0084]

[0095] 7A and 7B show example encrypted payloads, according to some embodiments. In FIG. 7A, encrypted payload 702 (e.g., corresponding to encrypted payload 324) includes encrypted message 322, map 312, and version information 706. For example, encrypted payload 702 is a concatenation of encrypted message 322, map 312, and version information 706. Map 312 is described in detail above with respect to FIG. 4A. In some embodiments, as shown in FIG. 7A, version information 706 includes a version number of a privacy table corresponding to map 312. In some embodiments, version information 706 is included in map 312 (e.g., map 312 includes a value indicating the version of the corresponding privacy table).

[0085]

[0096] 7B, encrypted payload 750 includes version information 752. In some embodiments, version information 752 includes one or more of a version number of the corresponding privacy table and morphing information for generating a version of the privacy table. In some embodiments, version information 752 includes: a value (e.g., a number) corresponding to the version of the privacy table for which the map 312 was generated, represented by the letter "H"; A value (e.g., a number) corresponding to the type of hash algorithm used for morphing, represented by the letter "I", and A value (e.g., a number) corresponding to a portion of the transformed privacy table, represented by the letter "J", Contains one or more of the following:

[0086]

[0097] In some embodiments, the values ​​"I" and "J" correspond to input from a user of electronic device 302 (eg, user-selected values ​​for parameters in morph match 602).

[0087]

[0098] FIG. 7C illustrates a morph match 758, according to some embodiments. In some embodiments, morph match 602 is an instance of morph match 758. Morph match 758 includes multiple morphing algorithms 760-1 through 760-10 and one or more parameters 762. In some embodiments, multiple morphing algorithms 760 are selected from an algorithm pool 766. In some embodiments, multiple morphing algorithms 760 include one or more different types of algorithms. In some embodiments, a morphing algorithm includes one or more hashing algorithms (e.g., secure hash algorithms), one or more message digest algorithms, and / or one or more ciphers. In some embodiments, multiple morphing algorithms 760 include one or more algorithms of the same type with different parameters. In some embodiments, parameters 762 include one or more parameters for transforming an associated privacy table (e.g., privacy table 310). For example, parameters 762 include information and / or instructions regarding how often to update privacy table 310 (eg, based on elapsed time or number of messages sent).

[0088]

[0099] In some embodiments, performing a morphing operation on the privacy table includes selecting a morphing algorithm from a plurality of morphing algorithms 760. In some embodiments, the morphing algorithm is selected based on user input. In some embodiments, the morphing algorithm is selected randomly (e.g., pseudo-randomly). In some embodiments, an identifier for the selected morphing algorithm is transmitted to the remote device (e.g., from electronic device 302 to electronic device 304). In some embodiments, the identifier is transmitted to the remote device as metadata for a secure message (e.g., along with a version number for the privacy table (e.g., version 603)). In some embodiments, the morphing algorithm identifier (and optionally the version number) is transmitted separately from the secure message (e.g., in a separate communication and / or via a separate communication channel).

[0089]

[0100] In some embodiments, the plurality of morphing algorithms 760 are refreshable from the algorithm pool 766. For example, after a certain number of morphs, a new set of morphing algorithms is obtained from the algorithm pool 766. As another example, a user may request a refresh of the plurality of morphing algorithms, resulting in a new set of algorithms being obtained from the algorithm pool 766.

[0090]

[0101] 8A-8C provide a flow diagram of a method 800 for secure communication (e.g., between devices of secure communication system 100) according to some embodiments. Method 800 is performed at a first electronic device (e.g., electronic device 302). The first electronic device may correspond to any of the electronic devices shown in FIG. 1 (e.g., electronic devices 110, 120, 130, or 140, or a device associated with secure log 112) or any of the devices shown in FIG. 5 (e.g., drone 502 or landing station 508). One example of secure communication between electronic devices of secure communication system 100 is provided with respect to FIGS. 6A and 6B.

[0091]

[0102] The first electronic device obtains 802 a first version of a privacy table. The privacy table includes N first bits, where N is a positive integer greater than 32. In some embodiments, the first electronic device receives the first version of the privacy table from a random number generation system (e.g., random number generation system 216). In some embodiments, the first electronic device generates the first version of the privacy table (e.g., using table generation module 229).

[0092]

[0103] The first electronic device applies a predetermined hashing algorithm to the first version of the privacy table (e.g., via table morphing module 231) to generate a second version of the privacy table having N second bits (804). In some embodiments, the second version of the privacy table has more or fewer than N bits. In some embodiments, the predetermined hashing algorithm is (at least a part of) a morph match (e.g., morph match 602). In some embodiments, the predetermined hashing algorithm (in morph match) is obtained by the first version of the privacy table (e.g., generated by the first version of the privacy table or obtained from a random number generation system by the first version of the privacy table). In some embodiments, the predetermined hashing algorithm is generated according to information from the second electronic device (e.g., electronic device 304). For example, users of the first and second electronic devices may together define (agree on) a morph match.

[0093]

[0104] In some embodiments, the hashing algorithm includes one or more hash functions (806). In some embodiments, the hashing algorithm includes two or more hash functions (e.g., applying one or more of them for each morph of the privacy table). In some embodiments, the hashing algorithm selects which hash function to apply based on input from a user of the first electronic device (e.g., the user specifies which hash function to apply for a given morph of the privacy table).

[0094]

[0105] In some embodiments, the first electronic device sequentially hashes portions of the first version of the privacy table in a predetermined order to generate a second version of the privacy table (808). In some embodiments, the predetermined order is specified in the morph match. In some embodiments, the portions of the first version of the privacy table are smaller than the entire privacy table. For example, the hashing algorithm is applied to only a subset of the privacy table according to the morph match. In some embodiments, the hashing algorithm is applied to only the portion of the privacy table previously used to generate the key (e.g., the portion corresponding to map 312).

[0095]

[0106] In some embodiments, a second version of the privacy table is generated 810 according to a preset number of messages that have been encrypted based on the first version of the privacy table. For example, a morph match for the privacy table may specify that each version of the privacy table be used for only 1, 5, or 10 messages. In some embodiments, the second version is generated according to a preset amount of the privacy table that has been used (e.g., if 25%, 50%, or 75% of the privacy table has been used to generate the key).

[0096]

[0107] In some embodiments, the second version of the privacy table is generated in response to a request from a user of the first electronic device 812. For example, the user of the first electronic device may request a new version of the privacy table due to security concerns or in accordance with a security policy for communications with the second electronic device.

[0097]

[0108] In some embodiments, the first electronic device obtains 814 a blockchain of the privacy table (e.g., from secure log 112 or blockchain information 246). The blockchain includes a genesis block for the first version of the privacy table. In accordance with generating a second version of the privacy table, the first electronic device generates 814 a second block and inserts the second block into the blockchain. In some embodiments, each version of the privacy table corresponds to a block in the blockchain.

[0098]

[0109] In some embodiments, the first electronic device (i) receives from the second electronic device a version identifier for the second encrypted message and the privacy table, where the version identifier indicates that the second encrypted message was generated using the first version of the privacy table. The first electronic device then (ii) decrypts the second encrypted message using information from the genesis block of the blockchain (818). For example, if the second message is based on the first version of the privacy table, the first electronic device retrieves the first version of the privacy table from a blockchain database (or generates the first version of the privacy table based on information from the blockchain).

[0099]

[0110] The first electronic device obtains (820) a first message for transmission to a second electronic device that (i) has a copy of the first version of the privacy table and (ii) has access to a predetermined hashing algorithm. For example, the first electronic device obtains the first message from a user of the first electronic device (e.g., via communication interface 212). In some embodiments, the first message is obtained from a messaging application running on the first electronic device. In some embodiments, the first electronic device generates the first message in response to an incoming communication or event. For example, the first electronic device generates the first message in response to a request to identify itself to a remote device.

[0100]

[0111] The first electronic device generates 822 a primary key based on the second version of the privacy table (e.g., using primary key generation module 232). In some embodiments, the primary key is generated based on a subset (map) of the privacy table values.

[0101]

[0112] In some embodiments, the first electronic device generates 824 a map based on the second version of the privacy table (e.g., via map generation module 230), where (i) the map includes a set of parameter values ​​that specify instructions for generating a primary key from the second version of the privacy table, and (ii) the primary key is generated according to the instructions in the map. The first electronic device then transmits 824 the map to the second electronic device. For example, the map is transmitted to the second electronic device along with an encrypted message (e.g., the map and the encrypted message are transmitted as encrypted payload 324).

[0102]

[0113] In some embodiments, generating a map based on a privacy table includes selecting a location in the privacy table, selecting a reading direction (e.g., spin), generating a map based on values ​​(e.g., bits or random numbers) stored in the privacy table starting from the selected location, and reading the values ​​stored in the privacy table according to the selected reading direction. In some embodiments, the location (e.g., starting location) in the privacy table is selected randomly. In some embodiments, the reading direction is selected randomly. In some embodiments, the location in the privacy table is selected based on a value provided via a pseudorandom number generator. In some embodiments, the reading direction is selected based on a value provided via the pseudorandom number generator. For example, the pseudorandom number generator may provide a pseudorandom number such as "-129" corresponding to a starting location of 129 in the privacy table and a negative reading direction (e.g., starting at location 129 and reading values ​​in the privacy table backwards (e.g., reading from right to left)). In another embodiment, the pseudo-random number generator may provide a pseudo-random number such as "+8", which corresponds to a starting position of 8 in the privacy table and a positive reading direction (e.g., starting at position 8 and reading the values ​​in the privacy table in a forward direction (e.g., reading from left to right)).

[0103]

[0114] In some embodiments, generating a map based on a privacy table includes generating the map using a subset or some (but not all) of the random numbers (e.g., bits) stored in the privacy table 310. In some embodiments, the map does not include information (such as an identifier) ​​about which privacy table it is associated with or from which it was generated. In some embodiments, the map comprises random numbers from the privacy table. In some embodiments, the map includes a random value corresponding to a starting point in the privacy table, a value corresponding to a horizontal offset from the starting point in the privacy table, a value corresponding to a horizontal reading direction from the starting point in the privacy table, a value corresponding to a vertical offset from the starting point in the privacy table, a value corresponding to a vertical reading direction from the starting point in the privacy table, a value corresponding to a size of the privacy table in the horizontal direction (e.g., a size permutation), a value corresponding to a size of the privacy table in the vertical direction (e.g., a size permutation), a value corresponding to a starting point in the permutation, and / or the length of a challenge string used to generate the primary key. In some embodiments, the length of the challenge string is derived from a value corresponding to a permutation of the size of the privacy table in the horizontal direction and a value corresponding to a permutation of the size of the privacy table in the vertical direction.

[0104]

[0115] In some embodiments, generating the primary key based on the map and the privacy table includes generating a challenge string based on the map (e.g., based on a value in the map, based on a random number in the map), and applying a digest function to the challenge string to form the primary key. In some embodiments, the primary key is a digest, such as a SHA256 digest, of the challenge string (e.g., as described above with respect to FIG. 3A).

[0105]

[0116] The first electronic device encrypts (826) the first message using the primary key (e.g., via encryption module 234) to form an encrypted first message (e.g., encrypted message 322). For example, to encrypt the message, the first electronic device may initialize an encryption protocol (e.g., an encryption algorithm such as AES256) to encrypt the first message using the primary key to form the encrypted first message.

[0106]

[0117] The first electronic device transmits (828) the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device (e.g., via communications module 224). In some embodiments, the first electronic device presents the encrypted first message to the second electronic device. For example, the first electronic device presents the encrypted first message as a barcode for the second electronic device to scan. In some embodiments, the first electronic device transmits the encrypted first message over an unencrypted (insecure) channel.

[0107]

[0118] In some embodiments, the second electronic device (i) applies a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table (830) (e.g., operation 22 in FIG. 6B), (ii) recovers the primary key from the second version of the privacy table according to the map (830) (e.g., operation 23 in FIG. 6B), and (iii) decrypts the encrypted first message (830) using the recovered primary key (e.g., operation 24 in FIG. 6B). In some embodiments, the second electronic device generates the second version of the privacy table based on information from the morph match (e.g., morph match 602).

[0108]

[0119] In some embodiments, the first electronic device applies the predetermined hashing algorithm to the second version of the privacy table to generate a third version of the privacy table having N third bits (832). In some embodiments, the first electronic device applies the predetermined hashing algorithm in a different manner compared to the second version to generate the third version. For example, the first electronic device applies a different hash function of the predetermined hashing algorithm, applies the predetermined hashing algorithm with different values ​​for the algorithm's parameters, and / or applies the algorithm to different portions of the privacy table.

[0109]

[0120] In some embodiments, after transmitting the encrypted first message, the first electronic device (i) applies a predetermined hashing algorithm to the second version of the privacy table to generate a third version of the privacy table having N third bits (834), (ii) obtains a second message for transmission to the second electronic device (834), (iii) generates a second primary key based on the third version of the privacy table (834), (iv) encrypts the second message using the second primary key to form an encrypted second message (834), and (v) transmits the encrypted second message and a version identifier for the third version of the privacy table to the second electronic device (834).

[0110]

[0121] 9 provides a flow diagram of a method 900 for secure communication (e.g., between devices of secure communication system 100) according to some embodiments. Method 900 is performed at a first electronic device (e.g., electronic device 302). The first electronic device may correspond to any of the electronic devices shown in FIG. 1 (e.g., electronic devices 110, 120, 130, or 140, or a device associated with secure log 112) or any of the devices shown in FIG. 5 (e.g., drone 502 or landing station 508).

[0111]

[0122] The first electronic device obtains (902) a first privacy table. In some embodiments, the first privacy table is obtained from a random number generation system (e.g., random number generation system 216). In some embodiments, the first privacy table is generated from a true random number generator (904). In some embodiments, the first privacy table is generated using a table generation module (e.g., table generation module 229). In some embodiments, the first privacy table is transmitted from the random number generation system (e.g., from random number generation system 216) to the first electronic device, another electronic device, or a random number storage system.

[0112]

[0123] The first electronic device transmits the first privacy table to the second electronic device (906). In some embodiments, the first privacy table is transmitted to the second electronic device over an encrypted channel. In some embodiments, an encrypted version of the first privacy table is transmitted to the second electronic device (908). In some embodiments, the first privacy table is encrypted using an encryption module (e.g., encryption module 234).

[0113]

[0124] The first electronic device obtains (910) a second privacy table. In some embodiments, the second privacy table is obtained from a random number generation system (e.g., random number generation system 216). In some embodiments, the second privacy table is generated (912) from the first privacy table. For example, the second privacy table is a morph of the first privacy table (e.g., generated using table morphing module 231).

[0114]

[0125] The first electronic device encrypts the second privacy table using the first privacy table (914). In some embodiments, the first electronic device generates a key from the first privacy table (e.g., using primary key generation module 232). In some embodiments, the first electronic device encrypts the second privacy table using the key generated from the first privacy table. In some embodiments, the second privacy table is encrypted using an encryption module (e.g., encryption module 234).

[0115]

[0126] The first electronic device transmits the encrypted second privacy table to the second electronic device 916. In some embodiments, the second privacy table is transmitted to the second electronic device over an encrypted channel.

[0116]

[0127] The first electronic device receives a digest of the second privacy table from the second electronic device (918). For example, the second electronic device generates the digest in response to receiving / decrypting the second privacy table.

[0117]

[0128] In some embodiments, the second electronic device decrypts the second privacy table using a decryption module (e.g., decryption module 236). In some embodiments, the second electronic device decrypts the second privacy table using a map of the first privacy table (e.g., a map received from the first electronic device). In some embodiments, after decoding the second privacy table, the second electronic device generates a digest of the second privacy table and transmits the digest to the first electronic device.

[0118]

[0129] The first electronic device verifies the second privacy table in accordance with receiving the digest (920). In some embodiments, the first electronic device verifies that the digest received from the second electronic device matches the digest generated by the first electronic device (e.g., generated from the second privacy table). In some embodiments, verifying the second privacy table includes authorizing use of the second privacy table for encrypting future communications with the second electronic device. In some embodiments, verifying the second privacy table includes replacing the first privacy table with the second privacy table. In some embodiments, verifying the second privacy table includes using the second privacy table for future encryptions associated with the second electronic device (e.g., future encrypted messages between the first and second electronic devices). In some embodiments, in accordance with verifying the second privacy table, the first electronic device sends a confirmation to the second electronic device (e.g., notifying the second electronic device that the second privacy table may be used).

[0119]

[0130] Attention is now directed to some example embodiments of the methods, devices, systems, and computer-readable storage media described above.

[0120]

[0131] (A1) In one aspect, some embodiments include a method (e.g., method 800) for securing communications between electronic devices. In some embodiments, the method is performed on a first electronic device (e.g., computer system 200) having memory 220 and one or more processors 210. The method includes (i) obtaining a first version of a privacy table (e.g., from random number generation system 216), the privacy table comprising N first bits, where N is a positive integer greater than 32; (ii) applying a predetermined hashing algorithm (e.g., via table morphing module 231) to the first version of the privacy table to generate a second version of the privacy table having N second bits; and (iii) transmitting a second electronic device (e.g., a second electronic device) having (a) a copy of the first version of the privacy table and (b) access to the predetermined hashing algorithm. (iv) generating a primary key (e.g., via primary key generation module 232) based on the second version of the privacy table; (v) encrypting the first message using the primary key to form an encrypted first message (e.g., via encryption module 236); and (vi) transmitting the encrypted first message and a version identifier of the second version of the privacy table to the second electronic device (e.g., via communication module 224). In some embodiments, N is 128 or greater.

[0121]

[0132] (A2) In some embodiments of A1, (a) generating the primary key includes (i) generating a map (e.g., via map generation module 230) based on the second version of the privacy table, where the map includes a set of parameter values ​​that specify instructions for generating the primary key from the second version of the privacy table (e.g., as described above with respect to FIG. 4A ), and (ii) generating the primary key according to the instructions in the map; and (b) the method further includes transmitting the map to the second electronic device (e.g., via communications module 224). In some embodiments, the map is transmitted to the second electronic device along with the encrypted first message.

[0122]

[0133] (A3) In some embodiments of A2, the second electronic device decrypts the first message by (i) applying a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table (e.g., via table morphing module 231), (ii) reconstructing a primary key from the second version of the privacy table according to the map (e.g., via primary key generation module 232), and (iii) decrypting the encrypted first message using the reconstructed primary key (e.g., via decryption module 236).

[0123]

[0134] (A4) In some embodiments of any of A1-A3, the hashing algorithm includes applying one or more hash functions (e.g., a SHA or MD5 algorithm). In some embodiments, the hashing algorithm is at least part of the morph match (e.g., morph match 602). In some embodiments, the hashing algorithm has one or more parameters that can be set by a user of the first electronic device.

[0124]

[0135] (A5) In some embodiments of any of A1-A4, the method further includes applying a predetermined hashing algorithm to the second version of the privacy table (e.g., via table morphing module 231) to generate a third version of the privacy table having N third bits. In some embodiments, different hash functions are used for the second and third versions. In some embodiments, the third version of the privacy table is added to the blockchain ledger as a new block.

[0125]

[0136] (A6) In some embodiments of any of A1-A5, applying the predetermined hashing algorithm to the first version of the privacy table includes sequentially hashing portions of the first version of the privacy table in a predetermined order, for example, starting from a first position (e.g., the beginning, middle, or end) and rotating through the fields or portions of the privacy table.

[0126]

[0137] (A7) In some embodiments of any of A1-A6, (i) the predetermined hashing algorithm includes one or more numerical parameters, (ii) applying the predetermined hashing algorithm includes generating and using a corresponding parameter value for each of the one or more numerical parameters, and (iii) the method further includes transmitting the parameter value to the second electronic device along with a version identifier of the second version of the privacy table (e.g., as described above with respect to FIG. 7B).

[0127]

[0138] (A8) In some embodiments of any of A1-A7, the method further includes transmitting the first version of the privacy table to the second electronic device over an encrypted channel. In some embodiments, the privacy table is transmitted over a different channel than the encrypted message.

[0128]

[0139] (A9) In some embodiments of any of A1-A8, the second version of the privacy table is generated according to a preset amount of time that has elapsed since the creation of the first version of the privacy table. For example, the morph match for the privacy table specifies that a new version of the privacy table should be generated weekly, monthly, or yearly.

[0129]

[0140] (A10) In some embodiments of any of A1-A9, the second version of the privacy table is generated according to a preset number of messages that have been encrypted using the first version of the privacy table. For example, a morph match for the privacy table may specify that a new version of the privacy table should be generated after 1, 5, or 10 messages have been transmitted (or received). In some embodiments, the second version of the privacy table is generated based on both the amount of time that has elapsed since the creation of the first version and the number of messages that are encrypted.

[0130]

[0141] (A11) In some embodiments of any of A1-A10, the second version of the privacy table is generated in response to a request from a user of the first electronic device. For example, the user of the first electronic device is presented with a user interface (e.g., for a corresponding messaging application) having affordances for generating a new version of the privacy table.

[0131]

[0142] (A12) In some embodiments of any of A1-A11, the method further includes, after transmitting the encrypted first message, (i) applying a predetermined hashing algorithm to the second version of the privacy table to generate a third version of the privacy table having N third bits; (ii) obtaining a second message for transmission to the second electronic device; (iii) generating a second primary key based on the third version of the privacy table; (iv) encrypting the second message using the second primary key to form an encrypted second message; and (v) transmitting the encrypted second message and a version identifier for the third version of the privacy table to the second electronic device (e.g., as described above with respect to acts 7-11 in FIG. 6A ).

[0132]

[0143] (A13) In some embodiments of any of A1-A12, the method further includes (i) obtaining a blockchain for the privacy table (e.g., from secure log 112), where the blockchain includes a genesis block for the first version of the privacy table; and (ii) generating a second block according to generating the second version of the privacy table and inserting the second block into the blockchain.

[0133]

[0144] (A14) In some embodiments of A13, the method further includes: (i) after generating the second version of the privacy table, receiving from the second electronic device a second encrypted message and a version identifier for the privacy table, where the version identifier indicates that the second encrypted message was generated using the first version of the privacy table; and (ii) decrypting the second encrypted message using information from the genesis block of the blockchain. For example, to obtain a previous version of the privacy table, the first electronic device retrieves the previous version (or information to reconstruct the previous version) from the blockchain.

[0134]

[0145] (B1) In another aspect, some embodiments include a method (e.g., method 900) for securing communications between electronic devices. In some embodiments, the method is executed on a first electronic device (e.g., computer system 200) having memory 220 and one or more processors 210. The method includes (i) obtaining a first privacy table, (ii) transmitting the first privacy table to a second electronic device, (iii) obtaining a second privacy table, (iv) encrypting the second privacy table with information from the first privacy table, and (v) transmitting the encrypted second privacy table to the second electronic device. In some embodiments, the second privacy table is obtained from a random number generation system (e.g., random number generation system 216).

[0135]

[0146] (B2) In some embodiments of B1, the second privacy table is generated on the first electronic device. In some embodiments, the second privacy table is generated by transforming a first privacy table stored on the first electronic device.

[0136]

[0147] (B3) In some embodiments of B1 or B2, the method further includes receiving and decrypting, at the second electronic device, the encrypted second privacy table.

[0137]

[0148] (B4) In some embodiments of B3, the method further includes generating, at the second electronic device, a digest of the second privacy table and transmitting the digest to the first electronic device.

[0138]

[0149] (B5) In some embodiments of B4, the method further includes receiving, at the first electronic device, the digest, and verifying, at the second electronic device, the decryption of the second privacy table using the digest. In some embodiments, the first electronic device compares the received digest with a digest generated from the second privacy table stored on the first electronic device.

[0139]

[0150] (B6) In some embodiments of any of B1 to B5, the second privacy table is encrypted using a key generated from the first privacy table.

[0140]

[0151] (B7) In some embodiments of any of B1-B6, the first electronic device transmits the map to the second electronic device to assist the second electronic device in decrypting the encrypted second privacy table.

[0141]

[0152] In another aspect, some embodiments include a computing system including one or more processors and a memory coupled to the one or more processors, the memory storing one or more programs configured to be executed by the one or more processors, the one or more programs including instructions for performing any of the methods described herein (e.g., methods 800, 900, A1-A14, and / or B1-B7 above).

[0142]

[0153] In yet another aspect, some embodiments include a non-transitory computer-readable storage medium storing one or more programs configured for execution by one or more processors of a computing system, the one or more programs including instructions for performing any of the methods described herein (e.g., methods 800, 900, A1-A14, and / or B1-B7 above).

[0143]

[0154] The terminology used in the description of the various illustrated embodiments herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used in the description of the various illustrated embodiments and in the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly dictates otherwise. The term "and / or," as used herein, will also be understood to refer to and encompass any and all possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises," and / or "comprising," when used in this specification, specify the presence of stated features, steps, operations, elements, and / or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, components, and / or groups thereof.

[0144]

[0155] As used herein, the term "if" means "when" or "upon" or "in response to determining" or "in response to detecting" or "in accordance with a determination that," depending on the context. Similarly, the phrase "if it is determined" or "if [a stated condition or event] is detected" means "upon determining" or "in response to determining" or "upon detecting [the stated condition or event]" or "in response to detecting [the stated condition or event]" or "in accordance with a determination that [a stated condition or event] is detected," depending on the context.

[0145]

[0156] It will also be understood that, although the terms first and second are used herein in some instances to describe various elements, these elements should not be limited by these terms, and are used only to distinguish one element from another.

[0146]

[0157] While some of the various figures depict a number of logical steps in a particular order, steps that are not order-dependent may be rearranged, and other steps may be combined or separated. While some rearrangements or other groupings are specifically mentioned, others will be apparent to those skilled in the art, and thus the rearrangements and groupings presented herein are not an exhaustive list of alternatives. Furthermore, it should be recognized that the steps may be implemented in hardware, firmware, software, or any combination thereof.

[0147]

[0158] The foregoing description has been set forth with reference to specific embodiments for purposes of explanation. However, the discussion of the above examples is not intended to be exhaustive or to limit the scope of the present invention to the precise form disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments have been chosen and described to best explain key principles and practical applications, thereby enabling those skilled in the art to best utilize various embodiments and to make various modifications as appropriate for the particular uses contemplated.

Claims

1. 1. A method performed on a first electronic device, comprising: obtaining a first version of a privacy table, the privacy table comprising N first bits, where N is a positive integer greater than 32; applying a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table having N second bits; (i) obtaining a first message for transmission to a second electronic device having a copy of the first version of the privacy table and (ii) having access to the predetermined hashing algorithm; generating a primary key based on the second version of the privacy table; encrypting the first message using the primary key to form an encrypted first message; transmitting the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device. method.

2. generating the primary key generating a map based on the second version of the privacy table, the map including a set of parameter values ​​specifying instructions for generating the primary key from the second version of the privacy table; generating the primary key according to the instructions in the map; The method further includes transmitting the map to the second electronic device. The method of claim 1.

3. The second electronic device is applying the predetermined hashing algorithm to the first version of the privacy table to generate the second version of the privacy table; Reconstructing the primary key from the second version of the privacy table according to the map; decrypting the encrypted first message using the recovered primary key; and The method of claim 2.

4. The method of claim 1 , wherein applying the predetermined hashing algorithm comprises applying one or more hash functions.

5. 2. The method of claim 1, further comprising applying the predetermined hashing algorithm to the second version of the privacy table to generate a third version of the privacy table having N third bits.

6. 2. The method of claim 1, wherein applying the predetermined hashing algorithm to the first version of the privacy table comprises sequentially hashing portions of the first version of the privacy table in a predetermined order.

7. the predetermined hashing algorithm includes one or more numerical parameters; applying the predetermined hashing algorithm includes generating and using a corresponding parameter value for each of the one or more numerical parameters; The method further includes transmitting the parameter value along with the version identifier for the second version of the privacy table to the second electronic device. The method of claim 1.

8. The method of claim 1 , further comprising transmitting the first version of the privacy table to the second electronic device over an encrypted channel.

9. The method of claim 1 , wherein the second version of the privacy table is generated according to a preset amount of time that has elapsed since the creation of the first version of the privacy table.

10. The method of claim 1 , wherein the second version of the privacy table is generated according to a preset number of messages that are encrypted with the first version of the privacy table.

11. The method of claim 1 , wherein the second version of the privacy table is generated in response to a request from a user of the first electronic device.

12. Furthermore, after transmitting the encrypted first message, applying the predetermined hashing algorithm to the second version of the privacy table to generate a third version of the privacy table having N third bits; obtaining a second message for transmission to the second electronic device; generating a second primary key based on the third version of the privacy table; encrypting the second message using the second primary key to form an encrypted second message; transmitting the encrypted second message and a version identifier for the third version of the privacy table to the second electronic device. The method of claim 1.

13. Furthermore, obtaining a blockchain for the privacy table, the blockchain including a genesis block for the first version of the privacy table; and generating a second block in accordance with generating the second version of the privacy table and inserting the second block into the blockchain. The method of claim 1.

14. Furthermore, receiving, after generating the second version of the privacy table, a second encrypted message and a version identifier for the privacy table from the second electronic device, the version identifier indicating that the second encrypted message was generated using the first version of the privacy table; decrypting the second encrypted message using information from the genesis block of the blockchain; The method of claim 13.

15. 1. A computing device comprising: one or more processors; a memory coupled to the one or more processors, the memory storing one or more programs configured to be executed by the one or more processors, the one or more programs comprising: obtaining a first version of a privacy table, the privacy table comprising N first bits, where N is a positive integer greater than 32; applying a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table having N second bits; (i) obtaining a first message for transmission to a second electronic device having a copy of the first version of the privacy table and (ii) having access to the predetermined hashing algorithm; generating a primary key based on the second version of the privacy table; encrypting the first message using the primary key to form an encrypted first message; transmitting the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device. Computing devices.

16. The instructions for generating the primary key include: generating a map based on the second version of the privacy table, the map including a set of parameter values ​​specifying instructions for generating the primary key from the second version of the privacy table; generating the primary key according to the instructions in the map; the one or more programs further comprising instructions for transmitting the map to the second electronic device.

16. The computing device of claim 15.

17. 16. The computing device of claim 15, wherein the instructions for applying the predetermined hashing algorithm to the first version of the privacy table comprise instructions for sequentially hashing portions of the first version of the privacy table in a predetermined order.

18. The computing device of claim 15 , wherein the second version of the privacy table is generated according to a preset amount of time that has elapsed since creation of the first version of the privacy table.

19. The one or more programs may further include: obtaining a blockchain for the privacy table, the blockchain including a genesis block for the first version of the privacy table; and generating a second block in accordance with generating the second version of the privacy table and inserting the second block into the blockchain.

16. The computing device of claim 15.

20. A non-transitory computer-readable storage medium storing one or more programs configured for execution by a computer system having one or more processors and a memory, the one or more programs comprising: obtaining a first version of a privacy table, the privacy table comprising N first bits, where N is a positive integer greater than 32; applying a predetermined hashing algorithm to the first version of the privacy table to generate a second version of the privacy table having N second bits; (i) obtaining a first message for transmission to a second electronic device having a copy of the first version of the privacy table and (ii) having access to the predetermined hashing algorithm; generating a primary key based on the second version of the privacy table; encrypting the first message using the primary key to form an encrypted first message; transmitting the encrypted first message and a version identifier for the second version of the privacy table to the second electronic device. A non-transitory computer-readable storage medium.

Images