System and method for authenticated, threaded, canonical IV, auto-keying (ATNA) cipher mode - Patents.com

Abstract

A method for implementing a block cipher is disclosed that includes generating an initialization vector counter. The method includes generating a key tree based on the initialization vector counter, the key tree including one or more contemporaneous states, each of which represents a timing period where the timing period of each subsequent contemporaneous state is nested within the previous contemporaneous state. The key tree further includes a key determined for each of the one or more contemporaneous states, each of which is determined based on the counter. The message further includes encrypting a data block to be transmitted using the key. A recipient can decrypt the one or more blocks only if the one or more blocks are received within the period of each of the one or more contemporaneous states.

Description

[Technical field]

[0001] (CROSS REFERENCE TO RELATED APPLICATIONS) This application is a national stage application of International Application No. PCT / US2023 / 012250, entitled "SYSTEMS AND METHODS FOR AUTHENTICATED, THREADED, CANONICAL IV, AUTO-KEYING (ATNA) CRYPTOGRAPHY MODES," filed on February 3, 2023, and claims the benefit of U.S. Provisional Patent Application No. 63 / 306223, entitled "SYSTEMS AND METHODS FOR AUTHENTICATED, THREADED, CANONICAL IV, AUTO-KEYING (ATNA) CRYPTOGRAPHY MODES," filed on February 3, 2022.

[0002] TECHNICAL FIELD This disclosure relates to the field of encryption to facilitate secure transfer of data between electronic devices or secure storage of data on a device or medium. [Background technology]

[0003] Block ciphers are widely used to secure data. A block cipher divides data into a fixed number of bits, which represents the block size. The most widely used block cipher, the AES standard block cipher, encrypts data in blocks of 128 bits or 16 bytes. The AES cipher uses a key to encrypt data. Symmetric ciphers such as AES use the same key to encrypt and then decrypt data.

[0004] Due to the relatively small block size of 128 bits, most amounts of data need to be encrypted in multiple blocks. For security, each block can have a different key. There are many ways to generate multiple keys. One method, called chaining, involves exchanging an initialization vector between a first entity and a second entity. The first and second entities calculate a first key for the first block based on the initialization vector. A second key for the second block of data is determined based on the first key. In this way, every key is based on the previous key, and the first key is determined from the initialization vector.

[0005] A drawback of chaining is that for large data sets, many keys must be determined starting from the initialization vector. For example, if a data transfer is initiated in the middle of a data set, many keys may need to be calculated to determine the key to start the transfer with.

[0006] Authentication is performed using a Message Authentication Code (MAC). The MAC is placed at the beginning (preamble) or end (prologue) of the data payload. The MAC is shared between the first and second entities during the initial exchange. The MAC can then be verified to authenticate the identity of the sender or first entity that encrypted the data. However, MACs are limited in that they only authenticate the identity of the first entity. They do not provide any information about the encrypted data, such as whether the data was authorized to be sent.

[0007] There is a need in the art for better block ciphers that remedy the deficiencies of chaining and MAC, and improve the overall system and method of block ciphers. Summary of the Invention

[0008] A system and method for implementing a block cipher mode is disclosed. A method for implementing a block cipher among a first (encrypting) entity, a second entity, or a group of entities includes generating, by the first entity, the second entity, or any group member, an initialization vector counter. The method includes generating, by the first entity, the second entity, or a group entity, a key tree based on the initialization vector counter, the key tree including one or more contemporaneous states, each of the one or more contemporaneous states representing a timing period where a timing period of each subsequent contemporaneous state is nested within a previous contemporaneous state. The key tree further includes a key determined for each of the one or more contemporaneous states, each of the one or more contemporaneous states being determined based on the counter. The message further includes encrypting, by one of the entities, one or more blocks of data to be transmitted to the second entity, the other group, or a subset of the group entities using the key, the other entity being able to decrypt the one or more blocks only if the one or more blocks are received during a timing period or a contemporaneous joint counter state period of each of the one or more contemporaneous states. The method may further include generating, by the encryption entity, an integrity tag including a fast drop tag and a key confirmation message authentication code (KCM). The fast drop tag may include data based on each of the concurrency states such that another entity may determine each of the concurrency states based on the fast drop tag. The other entity may include multiple cores, where the fast drop tag further includes a core designation that designates a core to process the data block. The core designation may be capable of designating two or more cores to process data from a single data packet. The encryption may include an AES encryption algorithm. The method may further include sequentially testing the keys for a timing period of each of the one or more concurrency states by sorting the keys and removing duplicate keys based on the sorting. The KCM may be configured to verify both the integrity key and the encryption key.The method may further include generating a per-message service ID that is verifiable for the initialization vector counter. The integrity tag may include one or more padding bits that are not transmitted to other entities. Each subsequent time or coherence counter state is an integral subdivision of the previous time or coherence counter state. The initialization vector counter may be determined based on a request time or coherence counter state from the initiator and a response time from the responder.

[0009] Another general aspect is a system for implementing a block cipher between a first entity and a second entity, group, or subset of a group. The system includes a processor coupled to a memory for the first entity. The processor is configured to generate an initialization vector counter in response to a connection with the other entity. The processor is further configured to generate a key based on the initialization vector counter. The key includes one or more contemporaneous states, each of the one or more contemporaneous states representing a timing period in which a timing period of each subsequent contemporaneous state is nested within a previous contemporaneous state. The key includes a key determined for each of the one or more contemporaneous states, each of the one or more contemporaneous states being determined based on a counter maximum value. The processor is further configured to encrypt one or more data blocks transmitted to the other entity using the key, such that the other entity can decrypt the one or more blocks only if the one or more blocks are received during a contemporaneous or contemporaneous grace period of the first entity. The processor may be further configured to generate an integrity tag including a fast drop tag and a message authentication code. The fast drop tag may include data based on each of the contemporaneous states, such that the second entity is able to determine each of the contemporaneous states based on the fast drop tag. The integrity tag may include a core designation that designates a core to process the data block. The core designation may be able to designate two or more cores to process data from a single data packet. The processor may be configured to encrypt using an AES encryption algorithm. The integrity tag may include one or more padding bits that are not transmitted to the second entity. Each subsequent timing period state may be an integral subdivision of the previous timing period state. The initialization vector counter may be determined based on a request time from the initiator and a response time from the responder.

[0010] An exemplary embodiment is a computer-readable storage medium having stored therein data representative of software executable by a processor. The software includes instructions that, when executed, cause the processor to generate an initialization vector counter in response to a connection with a second entity and generate a key based on the initialization vector counter. The key includes one or more contemporaneous states, each of the one or more contemporaneous states representing a timing period in which a timing period of each subsequent contemporaneous state is nested within a previous contemporaneous state, and a key determined for each of the one or more (t) contemporaneous states determined based on the counter. The software instructions further cause the processor to encrypt one or more data blocks to be transmitted to a computer network, the computer network being capable of decrypting the one or more blocks only if the one or more blocks are received during a timing period of each of the one or more contemporaneous states. A fast drop tag may include data based on each of the contemporaneous states, the computer network may determine each of the contemporaneous states based on the fast drop tag, and the integrity tag includes one or more padding bits that are not transmitted to the second entity. [Brief description of the drawings]

[0011] [Figure 1] 1 is a schematic diagram of a system and method for implementing authenticated, threaded, normalized IV, and auto-keying (ATNA) encryption.

[0012] [Diagram 2] 1 is a schematic diagram illustrating one embodiment of a method for implementing a contemporaneous system with ATNA encryption;

[0013] [Diagram 3] FIG. 11 is a flow diagram illustrating one embodiment of a DRBG subsequencer for entity resynchronization with ATNA encryption.

[0014] [Figure 4] FIG. 2 is a schematic diagram illustrating one embodiment for implementing contemporaneous state in ATNA encryption.

[0015] [Diagram 5] 1 is a schematic diagram illustrating a method for implementing a set of KDFs.

[0016] [Figure 6] FIG. 1 is a schematic diagram illustrating an embodiment of distributing encryption among multiple machines.

[0017] [Figure 7] FIG. 1 is a schematic diagram illustrating an embodiment of distributing decoding among multiple machines.

[0018] [Figure 8] FIG. 2 is a flow diagram of data encryption in an embodiment of ATNA encryption.

[0019] [Figure 9A] FIG. 2 is a flow diagram of data decryption in an embodiment of ATNA encryption.

[0020] [Figure 9B] FIG. 11 is another flow diagram of decrypting data in an embodiment of the ATNA encryption.

[0021] [Figure 10] FIG. 2 is a flow diagram of data encryption and decryption in an embodiment of ATNA encryption.

[0022] [Figure 11A] FIG. 13 is a flow diagram of constructing an integrity tag in an embodiment of ATNA encryption.

[0023] [Figure 11B] FIG. 11 is another flow diagram of constructing an integrity tag in an embodiment of ATNA encryption.

[0024] [Figure 12]FIG. 1 is a flow diagram of constructing an integrity tag in ATNA encryption.

[0025] [Figure 13] FIG. 2 is a schematic diagram of an embodiment implementation of integrity tags in ATNA encryption.

[0026] [Figure 14] FIG. 2 is another schematic diagram of an embodiment implementation of integrity tags in ATNA encryption.

[0027] [Figure 15] FIG. 2 is another schematic diagram of an embodiment implementation of integrity tags in ATNA encryption.

[0028] [Figure 16] FIG. 1 is a schematic diagram of a hardware configuration for implementing ATNA encryption.

[0029] [Figure 17] FIG. 1 is a schematic diagram of a computer system capable of implementing either encryption or decryption of an ATNA cipher.

[0030] [Figure 18] FIG. 1 is a diagram of the sequential tests designed for the ATNA cipher.

[0031] [Figure 19] FIG. 1 is a schematic diagram of a Key Confirmation MAC (KCM).

[0032] [Figure 20] FIG. 1 is a schematic diagram showing the formation of a counter block by an SVCID. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0033] The disclosed subject matter is a block cipher mode for providing integrity and encryption (i.e., encryption / decryption) services and network security. The disclosed block cipher mode can be implemented using a variety of encryptions including AES encryption, which operates by encrypting / decrypting data in 16-byte (128) blocks. However, the disclosed block cipher is agnostic to the type of encryption algorithm used to encrypt the data. In an exemplary embodiment, the data can be encrypted using the DES algorithm.

[0034] The disclosed subject matter includes various innovations that improve upon current encryption systems. The disclosed block cipher includes a concurrency state that, when implemented, limits the keys used during the concurrency. Multiple concurrency states may operate simultaneously. A key is rejected unless it is used during the timing period defined by each of the concurrency states. In an exemplary embodiment, concurrency states may be nested within one another. The method defines a new form of authenticated encryption, "Coeval Authenticated Encryption" (CAE). This takes two forms: timing period based concurrency (Coeval), where states propagate forward based on a configured period, and counter based concurrency (Coeval), where states propagate forward based on reaching a maximum counter value.

[0035] In an exemplary embodiment, each synchronizing state includes a time or counter period that can be determined based on an exchange between the first entity and the second entity or other entities. In various embodiments, the synchronizing state is determined by an initialization time that is based on an exchange between the first entity and the other entity. For example, the initialization time can be based on the time that the first entity sends a connection request and the time that the other entity sends a connection response. A key for all synchronizing states can be determined by the initialization time. Thus, the timing period for each of the synchronizing states is also determined based on the initialization time.

[0036] In an exemplary embodiment, an approved deterministic random bit generator (DRBG) is used to determine the integrity of the contemporaneous period and the encrypted bit stream. Thus, for a particular contemporaneous period, the contemporaneous state can be calculated directly without calculating all periods leading up to a particular timing period. For example, the tenth period of the contemporaneous state can be calculated directly without first calculating the first through ninth timing periods.

[0037] Multiple concurrent contemporaneous states may each be determined by distinct key derivation functions (KDFs) anchored to a common synchronization point, i.e., a time or counter Interpolated Key Resynchronization (IKR) point. Thus, the KDF may determine the keys and contemporaneous periods of the contemporaneous states based on the DRBG and the initialization time.

[0038] Another innovation of the disclosed subject matter is an improved message authentication code (MAC). The authorized MAC (sometimes referred to as "STNMAC") indicates the cores designated to process a portion of the data. In an exemplary embodiment, STNMAC determines the number of cores based on the payload size of the data to be encrypted or decrypted.

[0039] Another innovation of the disclosed subject matter is a fast drop tag (FDT) that can be included in the integrity tag. The fast drop tag allows the data payload to be quickly examined for various concurrency conditions before it is fully decoded. Thus, transmissions without the correct concurrency conditions are quickly dropped with minimal processing, which is critical to preventing destructive bot-style attacks. The fast drop tag can include various other information to facilitate flow control in an ATNA-protected network. In an exemplary embodiment, the fast drop tag can define ingress and / or egress parameters. For example, ingress / egress compliance can be enforced if all entities are allowed to connect to the network. For example, an entity may be restricted from sending certain data that is dropped by the fast drop tag on egress compliance.

[0040] Another innovation in the disclosed subject matter is virtual halo padding, where padding bits are generated on either side of an authenticated data tag that can be used in the integrity calculation but cannot be transmitted.

[0041] FIG. 1 is a schematic diagram 100 of a system and method for implementing Authenticated, Threaded, Canonicalized IV, and Auto-Keying (ATNA) encryption. ATNA encryption can be used to securely encrypt and transmit data. ATNA encryption brings several innovations to modern encryption. For example, ATNA encryption does not include a traditional initialization vector (IV) for computing a key for a connection. Instead, an embodiment of ATNA encryption can be instantiated with an initial key 102 or a post-quantum cryptography key (PQC). The initial key 102 is exchanged between the entity and the connection.

[0042] The initial key 102 can be used to generate multiple keys for the ATNA cipher using a deterministic random bit generator (DRBG) 104. The keys generated by the DRBG 104 are sometimes referred to herein as co-evolutionary quantum initialization vectors or co-evolutionary quantum keys (CQIVs and / or CQKs). IVCTR DRGB104 is an approved security function that includes three methods: hash, keyed-hash message authentication code (HMAC), and counter (CTR) using the currently approved AES cipher. In various embodiments, DRGB104 can use the counter to deterministically generate random keys, with up to 2 44 It can return any value of

[0043] The values ​​of D0-K1 and D0-K2 refer to the initial bits of the DRBG stream. These are sometimes called the first and second read singletons or DRBG anchors 106. Initialization Time (IT IKR ) 108 is XORed with the D0-K1 value and then processed by a key derivation function to determine a DRBG rolling window period (DW) 110. The DW 110 is a set of incremental timing periods, each of which is referred to as a DRBG quantum (DQ) 114. The DW 110 set is an integer division of a base period called a resynchronization period 111. Padding bits 112 used for encryption and decryption may be generated for each DW 110 set. The padding bits are sometimes referred to herein as APBDWS and EPBDWS. APBDWS are padding bits applied to authentication data, sometimes referred to as ACD data. EPBDWS are padding bits applied to unencrypted data, and are used when the length of the unencrypted data is less than the cipher block size.

[0044] Each DQ 114 may be associated with an integrity key 116 that is calculated by the DW-KDF, sometimes referred to as the Tortoise KDF. The subscript IVCTR used in the figures indicates that these are values ​​determined by the DRBG counter. The integrity key 116 may be referred to herein as TIV, TK, which stands for tortoise key derivation function. Each DQ 114 and its associated integrity key 116 is associated with a period over which the integrity key operates.

[0045] In the exemplary embodiment shown in FIG. 1, the ATNA cipher includes two additional key derivation functions nested in sequence within the DQ. The first key derivation function is the auto-key KDF or AK-KDF 122, also called the hare KDF. The auto-key KDF determines a time or counter period that is an integer division of the DQ timing period. From the concurrency state determined by the auto-key KDF, the coeval counter KDF 128, also called the cheetah KDF, determines a timing period that is an integer division of the auto-key timing period. Each of the sequentially nested KDFs, the turtle KDF, the hare KDF, and the cheetah KDF, has associated therewith separate rolling keys.

[0046] The disclosed subject matter can be configured to work with any number of KDFs. In the exemplary embodiment shown in Figure 1, the AK-KDF 122 takes as input a coeval quantum key 118 and an XOR of an integrity key 116 and two tuples DRBG quantum time (referred to as ITDQ^(Time): tuple DRBG quantum time, and starting core number (SCN), (SCN, ITDQ^(Time) 120).

[0047] The AK-KDF 122 determines the time interval for an autokey quantum (AQ) 123. Each AQ 123 outputs a key AQK 126 and an auto-key quantum initialization vector (AQIV) 127. A coeval counter KDF 128 takes as input the XOR of the autokey quantum initialization vector 127, the coeval quantum initialization vector (CQIV) 119, and the initialization time 124 of the AQ 123. The coeval counter KDF 128 generates a coeval counter-block period (CCK) 134, which is the time interval for processing a block of code. In an exemplary embodiment, the CCK 134 is set to a constant 1 second, which should be able to process 1 million packets per second. Each block is processed using the CCK, a starting thread ID (STID), which may include the number of threads, cores, and processors. Additionally, each block is processed using a service ID (SVC-ID) 130 that is unique to each message and a BLOCKID (BLKID) that is unique to each block.

[0048] FIG. 2 is a schematic diagram 200 illustrating one embodiment of a method for implementing a coeval system in ATNA cryptography. In the embodiment illustrated in FIG. 2, ATNA cryptography begins with coeval initialization 205, where two or more entities connect to exchange data. Next, the two or more entities create a synchronization 210, whereby they exchange information to generate an initialization key. In an exemplary embodiment, the initialization key is determined based on the time the request is sent and the time the request is accepted, referred to herein as the initialization time. Synchronization 210 may be performed with a variety of exchange protocols, such as Crystals Kyber or Diffie-Hellman.

[0049] The DRBG 215 processes the initialization time to generate a number of key derivation functions, each of which generates a key with a defined period (interval). In step 220, the DW-KDF is initialized based on a time signal sent by the DW timer 225. The DW-KDF generates a set of dw-time periods in which the time periods generated by the other two key derivation functions are nested. In the exemplary embodiment shown in FIG. 2, the DW-KDF registers the output in the coeval cipher registry 230. The coeval cipher registry 230 provides data from the DW-KDF to an auto-key quantum KDF (AK-KDF), which is initialized in step 240. Similarly, the AK-KDF registers data including the key and the period in the coeval cipher registry 230. The time periods generated by the AK-KDF are the integral of the time periods generated by the DW-KDF.

[0050] The coeval counter KDF is generated in step 245 and receives input from the coeval cryptographic registry 230 and the coeval timer FD 235. The time period generated by the coeval counter KDF is the integral of the time period generated by the AK-KDF.

[0051] FIG. 3 is a flow diagram 300 illustrating an embodiment of a DRBG sub-sequencer for entity resynchronization in ATNA encryption. An entity may need to be resynchronized to complete a transfer. FIG. 3 illustrates four options for entity resynchronization, which correspond to four distinct DRBG types. In an exemplary embodiment, ATNA encryption is initiated in step 305, which causes a request to receive DRBG 310. If SIMPLE type is selected in step 315 (Type=SIMPLE), the system iterates through all DRBG counts that comply with the SP800 90A standard. However, if the DRBG count is large, the SIMPLE type may not be practical.

[0052] Therefore, the sub-sequencer is 44 , and the system (re)synchronizes at sub-interpolations to these interpolations, providing time-based or counter-depth-based service guarantees to achieve connection synchrony or resynchrony. (Note that with the latest design updates, Concurrent Key Trees are more flexible in providing these service guarantees and do not need to mention specific time frames.)

[0053] Additionally, if the DRBG KDF is selected (340, Type=KDF), a subsequencer KDF may be implemented to generate an interpolated seed value in step 345. In step 355, the system may determine whether to rotate the type (Rotate Type). For example, if an interpolation seed file was generated, the system may rotate the type to SEED-FILE (Type=SEED-FILE), whereby the system rotates the data (Rotate Data) in step 365.

[0054] 4 is a schematic diagram 400 illustrating one embodiment for implementing a coeval state in an ATNA cipher. The diagram 400, plotted on an approximately logarithmic scale, shows the relative timing periods or quanta used by the ATNA cipher. The value of IVCTRMAX 405 represents the total time it takes the ATNA cipher to complete a project. It is equal to the byte-mode Hexa-Tera DRBG Quantum (BHTDQ) or Bitmode Hexa-Gig DRBG Quantum (BHGDQ) 410, which is equal to the initialization vector counter multiplied by the DRBG quanta period (seconds).

[0055] The ATNA cipher generates nested periods that are integer divisions of larger periods. For example, the interpolated KDF resynchronization period 415 is made up of an integer number of periods equal to the size of IVCTRMAX 405. Each interpolated KDF resynchronization period 415 is equal to an interpolated KDF resynchronization quantum (IKRQ or IKRC) 420. The interpolated KDF resynchronization periods 415 are generated by the PR n where n is the count of the interpolated KDF resynchronization periods 415, i.e., PR1, PR2, ..., PR max is equal to.

[0056] One level down from the Interpolated KDF Resync Period 415 are the DRBG Rolling windows 425. The DRBG Rolling windows 425 define a period that is an integral of the Interpolated KDF Resync Period 415. The complete set of DRBG Rolling windows 425 is equal to the time of the Interpolated KDF Resync Period 415. Each DRBG Rolling window 425 is a DW n where n is equal to a counter of the DRBG rolling window 425. For example, the first DRBG rolling window 425 is represented by DW1, the second by DW2, etc. The DRBG rolling window 425 is sometimes referred to herein as a DQ, an IVCTR period, a DRBG quantum period, and a multiple of DQ 430.

[0057] Autokey Quantum Periods (AQ) 435 are integral divisions of the DQP. Each AQ period 435 is n where n represents the quantum period count. The entire set of AQ periods is equal to one DQP window, which is also equal to the Autokey Quantum Period second or AKC count 440.

[0058] Finally, at the lowest level, there is the coeval counter-block period 445. max Each concurrency counter block period in the set up to is equal to one AQ time. In an exemplary embodiment, the ATNA cipher sets each concurrency counter block period 445 to a constant 1 second. Each concurrency counter block period is sometimes denoted as CCK.

[0059] Figure 5 is a schematic diagram 500 illustrating how a set of KDFs are implemented. As shown in Figure 4, ATNA encryption generates nested time intervals that run simultaneously. Diagram 500 of Figure 5 illustrates one embodiment of a timing method in which various key derivation functions are implemented. As disclosed above, ATNA encryption sometimes refers to various key derivation functions as a tortoise, a hare, and a cheetah. The tortoise, hare, and cheetah key derivation functions generate time intervals and a key for each time interval.

[0060] ATNA encryption discloses a system where a key is linked to a time window. Furthermore, multiple time windows exist simultaneously, with each time window having a key associated with it. ATNA encryption generates time windows as needed. When a time window ends, the next one begins as a counter. The DRBG service 505 generates the longest time window, within which other time windows are nested. Each period of the DRBG service 505 is called a DRBG quantum period or DQP.

[0061] As shown by the dotted line along the DRBG service 505, the DRBG service 505 generates an integrity element for each DQP. The Interpolated KDF Resync service 515 initiates the Tortoise KDF with a timescale that is an integer division of the time of each DQP. The Tortoise KDF derives padding bits labeled as EPBDWS and APBDWS during the first iteration DW / DQ KDF. EPBDWS stands for Encryption Padding Bits at DRBG Windows, where the padding bits are applied to unencrypted data. APBDWS stands for ACD Padding Bits at DRBG Windows, where the padding bits are applied to authenticated data. The EPBDWS padding bits are derived at the beginning of each DRBG rolling window period. The EPBDWS padding bits are constant during the synchronicity period.

[0062] The DRBG rolling window service 525 has a period of DQP 535 and implements the Hare KDF. The DRBG rolling window service 525 derives a 2-tuple (TK, TIV) key and IV. The Hare KDF uses the 2-tuple (TK, TIV) key and IV for Fast Drop Tag (FDT) processing. When using AES-256, the TIV is 16 bytes and the TK is 32 bytes. The FDT is a representation of this state and a directed map search for this state.

[0063] As shown in the figure, the DRBG service 505, the interpolated KDF resync service 515, the DRBG rolling window service 525, and the DQP generate the integrity and padding elements. The services below the dividing line 540 are responsible for implementing the encryption, decryption, and forward counter elements.

[0064] The auto-key quantum period (AQP) 545 is an integral subdivision of the DQP 535 and initiates the cheetah KDF. The cheetah KDF derives an auto-key quantum key (AQK) and an auto-key initialization vector (AQIV). The cheetah KDF further implements each contemporaneous counter block period CCK, which is an integral subdivision of each AQP. Each CCK implements encryption and / or decryption of a block and implements a counter for advancing each block ID.

[0065] 6 is a schematic diagram 600 illustrating an embodiment for distributing encryption among multiple machines. In various embodiments, the ATNA cipher may be configured to encrypt a data set using multiple hardware machines or processing cores. In an exemplary embodiment, high-level multi-processing encryption begins by performing the following tasks 602: 1. Get coeval keys. 2. Get Spirogyra Forwarding Counter (SFC). 3. Create level-1 Fast Drop Tag (FDT).

[0066] The ability to encrypt and decrypt in parallel allows the ATNA cipher to complete large data sets quickly. To achieve this, the ATNA cipher generates a predefined assignment to a set of physical core IDs. As used herein, a physical core ID may refer to a physical processor coupled to a memory.

[0067] Once task 602 is complete, physical cores can be assigned. ATNA crypto uses a system called the logical forwarding route system (LFRS) 604 to abstract the topology into a set of logical IDs across the topology. The logical forwarding route system starts by creating an LFRS map, which lists the IDs of hardware / physical cores that may perform cryptographic tasks.

[0068] After the number of physical cores is known, tasks are assigned to specific physical core IDs. The organization of the physical cores themselves is referred to herein as the topology. ATNA cryptography can support any number of topologies. In an exemplary embodiment, two topologies are approved for use: The hypercube topology allows for the simplest 1-bit flip routing system. Currently, the hypercube topology is the preferred interconnect. There is also a crossed cubed topology, an adaptation of the hypercube topology, which allows for fewer routing steps.

[0069] The topology defined by the Logical Forwarding Route System (LFRS) map allows for sequential distribution and collection of encryption units. An encryption unit is a collection of data, such as a block, to be encrypted. The topology also allows for parallel computation. The encryption units are assigned to a full set of hardware cores. Once the encryption units are assigned, they are distributed to the cores according to the LFRS map. In various embodiments, the encryption units are assigned to the nodes of the topology based on a banker's algorithm.

[0070] A Spirogyra Forwarding Counter (SFC) signs an ID to the cryptographic unit, facilitating allocation of the cryptographic unit to multiple cores based on the topology determined by the LFRS map. The Spirogyra Forwarding Counter ID may be included in the STID field of the cryptographic unit. A Fast Drop Tag (FDT) may be created and include the STID and IVCTR representing the coeval state IV and key derived by the coeval key derivation function for integrity and cryptographic (i.e., encryption and decryption) services.

[0071] Once the allocation and distribution is set in the LFRS, an encryption unit may be assigned to one or more cores. Various overlapping boxes 606 show a "divide and conquer" system in which an encryption unit is divided and processed by multiple cores simultaneously. Each of the cores may determine in a first phase whether a thread requires padding or alignment. In a second phase, the core performs the encryption. And in a third phase, the core may calculate the integrity.

[0072] The ATNA encryption includes an integrity tag based on STNMAC, which stands for STN message authentication code. The STNMAC for each block or packet includes a number based on the number of cores. The encrypted blocks and packets of the encryption unit are collected (608) and may have a reverse distribution route to maintain integrity.

[0073] Final integrity 610 exists when the integrity value is fully folded at the initiating node. AQIV and CCK key confirmation using the IKCPKT is applied to each packet. A length is determined for the authenticated bits based on the alignment and length fields, collectively referred to as the "align" and "acdlen" fields. An integrity key confirmation (IKC) is attached to each packet or data block. A fast drop tag is also attached to each packet or data block. The encrypted data is punted after applying length deterministics, applying the IKC, and attaching the fast drop tag.

[0074] FIG. 7 is a schematic diagram 700 illustrating an embodiment for distributing decryption to multiple machines. Encryption and decryption tasks may be distributed to multiple cores. FIG. 6 illustrates an embodiment for allocating encryption tasks to multiple machines, and FIG. 7 illustrates an embodiment for allocating parallel decryption tasks to multiple machines. Just as encryption units are distributed to multiple cores to encrypt a data set, encryption units may also be distributed to different sets of cores to decrypt a data set. ATNA encryption automatically allocates encryption units to cores based on an algorithm such as the banker's algorithm, maximizing the use of all cores on both the encryption and decryption sides.

[0075] In step 702, the system that decrypts the data set can determine current coeval keys. The current coeval keys are calculated based on a first entity that encrypts the data set and a second entity that decrypts the data set. ATNA encryption supports M to N operations. For example, a first entity can encrypt a data set on M processors and a second entity can decrypt the data set on N processors. Next, the leading 64-bits of the message are decrypted because the first 64-bits of the Fast Drop tag replace the leading 64-bits of the message.

[0076] In step 704, the logical forward routing system (LFRS) can distribute the encryption based on the known number of cores and the length of the data. Step 706 shows that the decryption task is assigned to multiple cores. Each core pads the data block if it is not full. Integrity is determined for each block and each core. Each core then verifies the integrity of each block and checks the coeval keys on each block. If any of these checks fail, the block is dropped.

[0077] In step 710, the first 64 bits of the Fast Drop tag have been swapped with the first 64 bits of the message so that speculative decryption may be performed before the entire message is received. In step 712, the ATNA cipher may coalesce the data and pass it through for consumption.

[0078] FIG. 8 is a flow diagram 800 for encryption of data in an embodiment of an ATNA cipher. Flow diagram 800 shows an overview of an embodiment of an encryption process. The process begins at step 802 where a first entity and a second entity connect. Both the first entity and the second entity exchange input, which may be an initialization time. In an exemplary embodiment, the initialization time may be based on a request time made by the first entity and a response time made by the second entity. Various contemporaneous states may be determined based on information exchanged by the first entity and the second entity. Additionally, a seed for the DRBG algorithm is based on the initial time or other information exchanged by the first entity and the second entity. At step 804, the time, initialization vector, and keys are all determined based on the initial time. At step 806, padding is added to the data representing the time, initialization vector, and / or keys to compensate for any mismatch in the length of the data.

[0079] In step 808, the plaintext blocks are encrypted and a message authentication code (MAC) is generated. In step 814, an integrity tag determined from the initialization time, initialization vector, and determined keys is appended to the unencrypted data set. For example, the calculated integrity tag is appended to the unencrypted packet 812. The combined packet and integrity tag are then encrypted in step 816 before being sent to the second entity.

[0080] As data is processed, time passes and the integrity tag also changes because it is based on contemporaneity. For example, a contemporaneity state is limited to a certain period of time and progresses to the next state (the contemporaneity state) after the previous period. Therefore, ATNA encryption can be protected against time-limited attacks.

[0081] 9A is a flow diagram 900 for decrypting data in one embodiment of the ATNA cipher. Based on input, which may be an initialization time, the second entity determines coevals, seeds, and various preconfigured parameters. Thus, in step 902, the second entity accepts a connection with the first entity or resynchronizes a connection with the first entity and uses the data exchange and connection to determine coevals and DRBG seeds.

[0082] In step 904, the second entity verifies the integrity tag from the first entity. The integrity tag can include various keys and concurrency in its calculation. Because both the first and second entities calculate the integrity tag independently of each other, the second entity can verify the integrity of the information coming from the first entity. Also, because the concurrency is based on time period, the calculation of the integrity tag varies depending on the time or concurrency counter maximum.

[0083] In step 906, one or more cores of the second entity may decrypt the encrypted packets coming from the first entity. Once decryption is performed, the decrypted data has the padding removed, and the decrypted and unpadded data block is appended to the remainder of the data set and stored.

[0084] 9B is another flow diagram 950 for decryption of data in one embodiment of the ATNA cipher. Flow diagram 950 shows a process by which data may be decrypted and another embodiment of the ATNA cipher. In step 952, which is the same as step 902 above (FIG. 9A), the ATNA cipher is initialized by the connection where secret data is exchanged. In one embodiment, the secret data is an initialization time.

[0085] In step 954, one or more cores of the second entity verify the integrity and decrypt the data packet. In step 956, the various contemporaneous keys are verified and padding is removed from the data block. Flow diagram 950 differs from flow diagram 900 in that decryption is performed before key verification. Flow diagram 900 has the advantage that a packet can potentially be dropped based on key verification and integrity before the packet is decrypted.

[0086] 10 is a flow diagram 1000 for encrypting and decrypting data in one embodiment of the ATNA cipher from a high level. At a high level, a set of parameters 1002 are used to generate one or more key derivation functions 1004. Each of the one or more key derivation functions 1004 generates a different time period, each time period having a corresponding key 1005.

[0087] The key 1005 is used to encrypt data from a data resource 1008 and generate a number of data packets 1009. In various embodiments, additional parameters 1020 may be calculated and processed into an integrity tag that is appended to the data set and transmitted to a second entity, which can verify the data based on the integrity tag.

[0088] The same subset of parameters 1002 is used by the second entity to generate one or more key derivation functions 1006. In various embodiments, the integrity tag is processed 1012 along with the keys generated by the key derivation functions 1006 before being passed to one or more key derivation functions 1014 to generate one or more keys and coeval states 1016. The encrypted data is then processed and decrypted into unencrypted data 1019 that may be stored and used as a resource 1010 by the second entity.

[0089] 11A is a flow diagram 1100 for constructing an integrity tag in one embodiment of an ATNA cipher. The integrity tag allows a second entity to verify more than just the identity of the sender. This allows the entity to verify various parameters of the data as well. The ATNA cipher is configured to transmit a payload from a first entity to a second entity. The payload, represented by 1102 and 1104, is used to determine a message authentication code 1110. The first 64 bits of the payload 1102 may be separated from the remainder of the payload 1104.

[0090] The first 64 bits of the payload 1102 are XORed with the first 64 bits of the fast drop tag 1112 (FDT) and relocated to the end of the rest of the payload 1116. The first 64 bits of the fast drop tag 1114 are placed before the rest of the payload 1116. The first 64 bits of the payload (64-Bit EFDT) XORed with the first 64 bits of the fast drop tag 1112 are placed at the end 1118 of the rest of the payload 1116. Next is the 64-bit masked remainder of the fast drop tag (64-Bit Masked-FDT) 1120, followed by the message authentication code 1122 generated in 1110.

[0091] 11B is another flow diagram 1125 for constructing an integrity tag in an ATNA encryption embodiment. Flow diagram 1125 illustrates the process for generating an integrity tag more simply. The first 64-bits (64-Bit FDT) 1134 of the fast drop tag are placed at the beginning of the integrity tag, followed by the rest of payload (1132). This is followed by an extended fast drop tag (1130), which is the result of XORing the first 64-bits (64-Bit FDT) 1127 of the fast drop tag with the first 64-bits (1102) of the payload.

[0092] Following the extended fast drop tag 1130 is the remainder of the fast drop tag, which includes a 64-bit masked fast drop tag 1128. A message authentication code 1126 is placed at the end of the integrity tag.

[0093] FIG. 12 is a flow diagram 1200 for constructing an integrity tag in ATNA encryption. Similar to FIG. 11A-11B, FIG. 12 shows another embodiment for constructing an integrity tag that can be used to verify both the sender and the integrity of data. In the flow diagram 1200, a payload consisting of authenticating data 1202 and payload 1204 is used to generate a message authentication code 1208. The message of the message authentication code 1208 is then processed with a fast drop tag (FDT) 1206 along with the authentication data padding, initialization vector, and service ID 1212 to generate an integrity tag 1210. The fast drop tag 1206 allows the receiver or sender to quickly discard packets based on various levels of dropping. The first level of dropping is based on an initialization vector counter field based on concurrency state. The second level of dropping is based on a starting thread ID field and the fast drop tag. The third level of dropping is based on the padding bits field in the fast drop tag. These various fields may be added to the fast drop tag at the end of the process where the integrity tag 1210 is generated.

[0094] An integrity tag 1222 is placed at the end of the transmission. The first 64 bits of authentication data 1202, sometimes referred to as the ACD payload, are transposed with the first 64 bits of the fast drop tag 1214. The remaining portion of the authentication data 1216 is placed after the first 64 bits of the fast drop tag 1214. Then, an encrypted data block, also referred to as the encrypted data payload 1218, is placed after the authentication data payload (1216).

[0095] In an exemplary embodiment, the first 64 bits of the authentication data are XORed 1220 with the first 64 bits of a Fast Drop tag placed at the end of the encrypted data payload. An integrity tag 1222 is then placed at the end of the transmission.

[0096] In an exemplary embodiment without the extension of the authentication data, the last 64 bits of the fast drop tag are placed at the end 1226 of the encrypted data payload, followed by the integrity tag 1224, as described above, placed last. Looking at the expanded view 1232 of the integrity tag, we see that it begins with an expanded 64 bit tag 1238, followed by the first 64 bits of the fast drop tag 1236, followed by the message authentication code 1234.

[0097] 13 is a schematic diagram 1300 for implementing an embodiment of an integrity tag in ATNA encryption. A data set transmission may include authentication data (ACD) 1304 and unencrypted data (UD) 1308. An alignment field 1302 is assigned to the authentication data (ACD) 1304 based on the length of the authentication data 1304, which may be an integral block size. The alignment field 1302 may then be used to determine the amount of padding to be generated for the block of authentication data 1304. Similarly, a second alignment field 1306 is used to determine the amount of padding for the unencrypted data 1308.

[0098] Looking at the authentication data (ACD) 1312, padding is generated on both sides of the authentication data 1312. A prelude pad 1310 is placed before the authentication data 1312, and a postamble pad 1314 is placed after the authentication data 1312. Because padding is placed both before and after the authentication data 1312, the padding may be referred to herein as halo padding. Halo padding may also be generated for the unencrypted data 1308, which may then be processed into the encrypted data 1318. Based on the second alignment field 1306, a preamble pad 1316 and a postamble pad 1320 are generated. The halo padding for the authentication data 1312 and the encrypted data 1318 may align the size of the authentication data 1312 and the encrypted data 1318 to an integral size of a block.

[0099] The padding bits for the authentication data are sometimes referred to as ACD padding bits at DRBG windows, or APBDWS. The padding bits for the encrypted data are sometimes referred to as encryption padding bits at DRBG windows, or EPBDWS. The APBDWS padding bits are sometimes referred to as virtual halo padding (VHP) because they may not be transmitted. Similarly, the EPBDWS is sometimes referred to as virtual halo padding because it does not need to be transmitted to the second entity. Even though the virtual halo padding is not transmitted, it may still be used in the integrity tag calculation.

[0100] When the data set is transmitted to the second entity, the data may be in a format beginning with a 64-bit lead 1322 corresponding to the first 64 bits of authentication data. This is followed by preamble padding bits 1324, followed by encrypted data (ED) 1326. In the embodiment shown in FIG. 13, the encrypted data is surrounded by padding bits, preamble padding bits 1324, and postamble padding bits 1328. The postamble padding bits 1328 are followed by an extended fast drop tag 1330, followed by the remainder of the fast drop tag 1332. The message authentication code is located at the end 1334.

[0101] The first 64 bits of the authentication data (1322) are XORed with the first 64 bits of the fast drop tag 1332 to produce a postamble 64-bit masked fast drop tag 1348. The first 64 bits of the fast drop tag (64-Bit FDT) are copied from the message authentication code 1350. The extended fast drop tag 1338 can be considered to be masked as well, due to the postamble 64-bit masked fast drop tag 1348.

[0102] Figure 14 is another schematic diagram 1400 for implementing an embodiment of an integrity tag in ATNA encryption. Diagram 1400 shows another embodiment that is a variation of the embodiment shown in Figure 13. Here, a 64-bit lead 1402 of authentication data 1404 is XORed with a fast drop tag (FDT) 1414 to generate a 64-bit masked fast drop tag 1430. The masked fast drop tag 1430 is placed after an extended fast drop tag (EFDT) 1428. The authentication data (ACD) 1404, encrypted data pad preamble 1406, encrypted data 1408, encrypted data pad postamble 1410, extended fast drop tag (EFDT) 1412, and message authentication code 1416 are left unchanged.

[0103] In various embodiments, the masked fast drop tag 1430 can control ingress and egress compliance via position bits derived from the 64-bit lead 1402. Ingress refers to data that is accepted and egress refers to data that is transmitted. For example, the masked fast drop tag can determine whether data can be transmitted by a first entity. Similarly, the masked fast drop tag determines whether data is accepted by a second entity. These features of the integrity tag add versatility beyond simply authenticating a user. For example, an authenticated user may be restricted from transmitting certain data, e.g., confidential data held by an entity. The same goes for the recipient of the data. In this way, the ingress and egress compliance features of the fast drop tag can restrict certain data transfers, even transfers where both parties are authenticated.

[0104] The last 64 bits 1414 of the Fast Drop Tag are transferred to the beginning of the Integrity Tag 1418. Placing this portion of the Fast Drop Tag 1414 at the beginning of the payload instead of at the end allows for speculative decoding, where some important prerequisites are known at the start of the decoding, allowing fast decoding to occur in parallel with the integrity.

[0105] Figure 15 is another schematic diagram 1500 for implementing an embodiment of an integrity tag in ATNA encryption that does not authenticate the data. Figure 15 shows another variation of an embodiment for generating an integrity tag. Other embodiments are shown in Figures 13 and 14. As shown in Figure 15, unencrypted data 1504 includes an alignment field 1502 that corresponds to the amount of padding required to align the size of the unencrypted data 1504 to an integer block length.

[0106] The ATNA cipher encrypts the data to generate encrypted data (ED) 1508. The ATNA cipher also generates halo padding consisting of a preamble pad 1506 and a postamble pad 1510. The preamble pad 1506 and postamble pad 1510 have lengths based on the alignment field 1502. The first 16 bits 1512 of the data set are XORed with a fast drop tag (FDT) 1522 to generate a 64-bit masked fast drop tag 1536. The encrypted data preamble pad 1514, encrypted data (ED) 1516, encrypted data postamble pad 1518, extended fast drop tag (EFDT) 1520, and message authentication code 1524 are the same as those shown in FIG. 14. The 64-bit masked fast drop tag 1536 is then copied onto the head of the integrity tag 1526 .

[0107] Therefore, there are many ways to insert a 64-bit fast-drop tag at the beginning of the integrity tag. As shown in Figure 15, speculative decryption can be performed even in the absence of authentication data.

[0108] 16 is a schematic diagram 1600 of a hardware configuration for implementing ATNA encryption. Various hardware configurations can be used to implement the disclosed ATNA encryption. One embodiment of the hardware configuration can include an ATNA AES complex 1602 consisting of a memory plus controller 1604 and an AES cell unit expansion 1606. The AES complex 1602 can be a computer system capable of encrypting and / or decrypting data.

[0109] The AES complex 1602 includes one or more ATNA cell units 1610 and a memory and interconnect controller 1616. Each of the one or more ATNA cell units 1610 may be comprised of a separate computing core processor capable of encryption and authentication. The memory and interconnect controller 1616 may be a hub and spoke model responsible for mapping memory to the individual cores and coordinating the interconnect integrity flow of the ATNA AES complex 1602.

[0110] Each AES cell unit extension 1606 is an expanded representation of one of the ATNA cell units 1610. In the embodiment shown in Figure 16, the AES cell unit is composed of AES encryption or decryption units 1626 through integrity units, memory mapping unit and controller core 1632, FIFO elasticity units, and interconnect units 1636. Each of the encryption or decryption units 1626 is a separate core capable of encryption or decryption.

[0111] Integrity unit A 1628 may calculate integrity for encryption. Integrity unit B 1630 may calculate integrity for transfer. Memory mapping unit and controller core 1632 facilitates communication with memory and interconnect controller 1616. FIFO elasticity unit 1634 acts as a buffer to store integrity requests when an interconnect transfer stalls before they are forwarded when the receiving unit is free.

[0112] The memory plus controller 1604 maps memory to the individual cores and coordinates interconnect integrity flows. The memory plus controller 1604 may be composed of multiple bound-through memory controllers 1620 and a forwarding interconnect plus controller 1622. Each of the multiple bound-through memory controllers 1620 is mapped to a core 1650 that corresponds to a memory mapping unit and controller core 1632.

[0113] Referring to FIG. 17, FIG. 17 is a schematic diagram of a computer system 1700 capable of implementing either encryption or decryption of the ATNA cipher. The computer system 1700 may include a bus 1702 that communicates with a memory 1706 coupled to a processor 1704. The bus 1702 may also communicate with a storage 1708 or a network 1710 of other computer systems. The memory 1706 may direct all data transfers within the computer system 1700. For example, the memory 1706 may direct instructions to be processed by the processor 1704 and may receive the processed instructions from the processor to be provided to one or more portions of the computer system 1700. Various types of memory 1706 include, but are not limited to, random access memory (RAM) and read only memory (ROM).

[0114] The processor 1704 processes instructions communicated from the memory 1706. Encryption and decryption are performed by the processor. Currently, the most widely used encryption method is AES encryption. Most commercially available processors are hard-wired to perform AES encryption. For example, most Intel and AMD central processing units (CPUs) include hardware to perform AES encryption and decryption. Other types of processors 1704 include graphics processing units (GPUs), complex programming logic devices (CPLDs), field programmable gate arrays (FPGAs), and application-specific integrated circuits (ASICs).

[0115] Storage 1708 is configured to hold data for long periods of time. Data that is saved before being transmitted is kept in storage 1708. Data received by the second entity from the first entity may be stored in storage 1708. Various types of storage include, but are not limited to, spinning hard drives and solid-state drives. ATNA encryption works by providing secure data transfer between the first entity and the second entity. This is often done over a network 1710, which may be any electronic connection between computer system 1700 and another computer system 1700.

[0116] Referring to FIG. 18, FIG. 18 is a diagram 1800 of a continuous test designed into the ATNA encryption. The continuous test, referred to herein as vmap64, is performed to ensure that each CCK key is not repeated. In various embodiments, vmap64 is FIPS-CC compliant and supports SP800-90B sanity testing. This ensures that a) for a particular encryption key, counter block IDs are always unique and forward (increasing with or without gaps) and b) the initialization vector (IV) bytes meet the required SP800-90B sanity criteria. This in turn prevents cases where a rogue peer can use weak or repeated IVs.

[0117] Figure 1800 is an example of a vmap64 continuity test. As each set of CCK keys is generated, the 64-bit prefix of each key is sorted. Duplicate CCK keys are removed based on the sort. In Figure 18, the 64-bit prefix of key (6-key) 1805 overlaps with key (3-key) 1810. Therefore, key 1805 is removed and the remaining keys are shifted to fill the gap.

[0118] Figure 19 is a schematic diagram 1900 for constructing a key confirming MAC (KCM). The KCM performs two functions: integrity key confirmation and encryption key confirmation. The key confirming embodiment using the KCM embeds a secure implementation onto the MAC, allowing the recipient to i) verify the integrity key using an integrity key confirming function with tag sizes of 128 bits, 192 bits, 256 bits, and ii) verify the encryption key using, optionally, an encryption key confirming function with tag sizes of 192 bits, 256 bits.

[0119] In the example KCM shown in schematic 1900, a 16 byte MAC 1905 is XORed with a 96 bit integrity key 1910 to produce a KCM that validates the integrity key. If the MAC is longer than 16 bytes, the first 16 bytes 1905 of the MAC are XORed with the 96 bit integrity key 1910. The KCM is then XORed with the 96 bit encryption key to validate the encryption key. In various embodiments, the KCM may be configured to validate either a 96 bit encryption key or a 128 bit encryption key.

[0120] Referring to Figure 20, Figure 20 is a schematic diagram 2000 illustrating the service-ID (SVC-ID) function. The SVC-ID may be a 32-bit peer identifier that is unique to the connection, or a per-message peer identifier that allows identification of group members that share the connection. The SVC-ID may be embedded in a counter block to facilitate a matching function to determine if the IVCTR is correct.

[0121] The per-message SVC-ID can be configured with a tag size of 128 bits, 192 bits, or 256 bits. In various embodiments, the integrity key check also verifies the per-message SVC-ID.

[0122] In an exemplary embodiment, each counter block includes a counter block key (CCK) 2005 followed by an SVC-ID 2010 followed by an STID 2015 followed by a BLKID 2020. The per-message SVC-ID may be XORed with a fast data tag (FDT) 2025 to generate a per-message SVC-ID FDT (SFDT) 2050. The per-message SVC-ID may be constructed differently based on whether in byte mode or bit mode. In bit mode, the first 28 bits 2035 consist of the STD and padding. This is followed by the 32-bit SVC-ID 2040. The last 4 bits 2045 allow for the identification of the IVCTR as a single DQP property in SP800-90B.

[0123] Bit mode and byte mode are mutually exclusive. In byte mode, the first 18 bits 2025 constitute the STID, followed by the 32-bit SVC-ID 2030. The last 14 bits 2032 make it possible to identify the IVCTR.

[0124] Another important innovation is support for align, acdlen, and align2 per connection: alignment on ACD, length of ACD, and alignment on unencrypted data, which can be used, among other things, a) to align them to processor cache lines, and b) to offset integrity and confidentiality required by some protocols.

[0125] Another innovation is the way we support runtime realignments using an Extended FDT (EFDT) that overwrites per-connection align, acdlen, align2 with per-message-field realigned ralign, racdlen, ralign2.

[0126] Another innovation is support for encryption Partial Bit Modes: a) no padding, b) traditional to cache line or cipher block length, or c) padding of preamble and postamble bits to cache line or cipher block length, i.e., if the encrypted data is not cache line or cipher block length, it will be preceded by align2 bits of EPBDWS and postamble bits of EPBDWS.

[0127] Many variations can be made to the embodiments described herein. All variations are intended to be included within the scope of the present disclosure, including combinations of variations. The description of the embodiments herein can be implemented in many ways. Any term used herein should not be interpreted as limiting the features or aspects of the disclosed subject matter. Instead, the scope should be interpreted according to the appended claims.

Claims

1. 1. A method for implementing a block cipher mode between a first entity and a second entity, comprising: It has a first step, a second step, and a third step, In the first step, an initialization vector counter is generated by the first entity and the second entity; In the second step, the first entity and the second entity generate a key tree based on the initialization vector counter; The key tree is one or more contemporaneous states, each of the one or more contemporaneous states representing a timing period in which the timing period of each subsequent contemporaneous state is nested within the previous contemporaneous state; a key determined for each of the one or more contemporaneous states; each of the one or more contemporaneous states is determined based on a counter maximum value; the third step encrypting, by the first entity, one or more data blocks to be transmitted to the second entity using the key; the second entity can decode the one or more blocks only if the one or more blocks are received during each of the one or more contemporaneous timing periods; method.

2. a fourth step of generating, by the first entity, an integrity tag including a fast drop tag and a key confirmation message authentication code (KCM); the fast drop tag includes data based on each of the contemporaneous states; the second entity may determine each of the concurrency states based on the fast drop tag; The method of claim 1.

3. the second entity includes one or more cores; the fast drop tag further includes a core designation that designates a core that processes the data block; The method of claim 2.

4. The core designation may designate two or more cores to process data from a single data packet. The method of claim 3.

5. a fifth step of sequentially testing keys for each timing period of the one or more contemporaneous states by sorting the keys; a sixth step of eliminating duplicate keys based on the sorting. The method of claim 1.

6. the integrity tag includes one or more padding bits that are not transmitted to the second entity; The method of claim 2.

7. The KCM is configured to verify both the integrity key and the encryption key. The method of claim 2.

8. a seventh step of generating a per-message service ID, the per-message service ID being capable of verifying the initialization vector counter; The method of claim 2.

9. The initialization vector counter is determined based on a request time from an initiator and a response time from a responder. The method of claim 1.

10. 1. A system for implementing a block cipher mode between a first entity and a second entity, comprising: a processor coupled to a memory of the first entity, the processor configured to generate an initialization vector counter in response to connecting with the second entity; the processor is configured to generate a key based on the initialization vector counter; The key is one or more contemporaneous states, each of the one or more contemporaneous states representing a timing period in which the timing period of each subsequent contemporaneous state is nested within the previous contemporaneous state; a key determined for each of the one or more contemporaneous states; each of the one or more contemporaneous states is determined based on a counter maximum value; the processor is configured to use the key to encrypt one or more data blocks to be transmitted to the second entity; the second entity can decode the one or more blocks only if the one or more blocks are received during each of the one or more contemporaneous timing periods; system.

Images