Sliding window based sequential relaxation for encrypted channels

Abstract

This application relates to sliding window based sequential relaxation for encrypted channels. A requester generates and encrypts a full initial value (IV) associated with a round trip communication with a responder. The requester sends a request to the responder indicating a secure value that includes a plurality of least significant bits (LSBs) of the full IV. The LSBs identify a phase associated with a predetermined number of requests that are allowed to be sent by the requester to the responder in sequence or out of sequence. The requester identifies a sliding window associated with a plurality of active phases that correspond to a time window in which the predetermined number of requests are currently allowed to be sent and at least one inactive phase that corresponds to a time window in which the predetermined number of requests are not currently allowed to be sent. The requester advances the sliding window by setting an oldest active phase to an inactive phase and by setting a current inactive phase to an active phase.

Description

[0001] Related applications This application claims the benefit of U.S. Provisional Patent Application No. 63 / 795,769, Agent No. P177460USPRV, filed April 28, 2025, by Derek Alan Sherlock, Frank R. Drops, and Keith D. Underwood, entitled “Sliding Window Based Sequential Relaxation for Encrypted Channels”. Background Technology

[0002] Some network architecture specifications under development use encryption protocols that require messages to be delivered in order. For example, the AES-GCM-256 protocol uses a shared key and a unique initial value (IV) for encryption operations between the requester and responder. While the key can be reused, reusing an IV with the same key can compromise security due to vulnerabilities that allow for cryptographic attacks. The IV can be generated by the requester and transmitted in plaintext, i.e., a full-length IV transmission. The IV can also be jointly maintained by the requester and responder, for example, based on a synchronization counter that requires messages to be delivered in order. Attached Figure Description

[0003] Figure 1 An environment based on a sliding window and sequential relaxation for encrypted channels is shown according to one aspect of this application.

[0004] Figure 2A A bit field diagram depicting a complete IV maintained by the requesting party, according to one aspect of this application, is shown.

[0005] Figure 2B A bit field diagram depicting a portion of the IV maintained by the respondent is shown according to one aspect of this application.

[0006] Figure 2C A schematic diagram of a hardware or data structure maintained by the requester according to one aspect of this application is shown.

[0007] Figure 2D A schematic diagram of a hardware or data structure maintained by the respondent according to one aspect of this application is shown.

[0008] Figure 2E shows a flowchart of the operations of a requester when sending a request according to one aspect of this application.

[0009] Figure 2F A flowchart illustrating the operations of a requester receiving a response according to one aspect of this application is shown.

[0010] Figure 2G A flowchart illustrating the operations of a respondent party upon receiving a request according to one aspect of this application is shown.

[0011] Figure 2H This is a flowchart illustrating the operations of a responding party when sending a response, according to one aspect of this application.

[0012] Figure 3A A schematic diagram illustrating the operation of a requester in sending a request and receiving a response based on a multi-epoch sliding window, according to one aspect of this application.

[0013] Figure 3B A schematic diagram illustrating the operation of a responder according to one aspect of this application when receiving a request and sending a response based on a multi-stage sliding window.

[0014] Figure 3C The illustration depicts one aspect of this application based on Figure 3B A schematic diagram of the four states of the responder in an exemplary four-stage sliding window.

[0015] Figure 4 A schematic diagram illustrating how a respondent and a requester generate, derive, and increment initial values ​​(IVs) according to one aspect of this application is shown.

[0016] Figure 5 A schematic diagram of the operation of a responder according to one aspect of this application based on a multi-stage sliding window with three active stages and one inactive stage is shown, including the identification of which partial IV the responder uses when reconstructing the complete IV.

[0017] Figure 6A A flowchart is shown of a method for promoting sequential relaxation based on a sliding window for encrypted channels according to one aspect of this application, including the operations of the requesting party.

[0018] Figure 6B A flowchart is shown that illustrates a method for promoting sequential relaxation based on a sliding window for encrypted channels according to one aspect of this application, including the operations of the responder.

[0019] Figure 7 A computational system based on sliding window sequential relaxation for encrypted channels is shown according to one aspect of this application.

[0020] Figure 8 A computer-readable medium based on sliding window sequential relaxation for encrypted channels is shown according to one aspect of this application.

[0021] In the accompanying drawings, the same reference numerals refer to the same elements. Detailed Implementation

[0022] Various aspects of this application provide a system that facilitates sequential relaxation based on a sliding window for encrypted channels.

[0023] As mentioned above, some network architecture specifications under development use encryption protocols that require messages to be delivered in order. For example, the AES-GCM-256 protocol uses a shared key and a unique initial value (IV) for each encryption operation between the requester and responder. While the key can be reused, reusing an IV with the same key can compromise security due to vulnerabilities that allow for cryptographic attacks. Existing solutions ensure that the requester and responder use the same key and IV value to encrypt and decrypt individual messages (e.g., requests or responses) sent between them. In one solution, the requester can generate the IV in plaintext and transmit it to the responder, achieving full-length IV transmission. However, transmitting the full-length IV value with each message can incur significant bandwidth overhead. In another solution, the IV can be maintained as a synchronization counter by both the requester and responder. Using a synchronization counter requires in-order message delivery to ensure that the IV counters maintained by both the requester and responder remain synchronized. However, in-order delivery can consume additional network resources or may unacceptably limit the use of multiple parallel network paths, especially in large-scale high-performance computing (HPC) networks.

[0024] The aforementioned aspects provide a system that relaxes these in-order delivery restrictions while maintaining a secure, encrypted channel for round-trip communication between requesters and responders over a network structure without transmitting the full-length IV value. Requesters and responders continue to communicate encrypted using a shared key and a common IV. However, instead of sending the full IV with every request, the requester sends only a subset of the full IV, such as multiple least significant bits (LSBs) (called "IV-LSB"), while the responder reconstructs the full IV by combining the received IV-LSB with its own counter used to track the remaining most significant bits (MSBs) (called "IV-MSB"). This approach reduces bandwidth overhead by allowing out-of-order message delivery while transmitting less IV data. The responder can encrypt its response using the shared key and the reconstructed IV without transmitting any IV bits back. This allows both the requester and responder to use nearly identical IVs for encryption / decryption and ensures their respective counters remain synchronized, with only the requester transmitting a portion of the full IV. Since IV values ​​are never repeated for the same encryption key, the IV values ​​used by the requester and responder will differ depending on the higher-order IV bits. For example, the MSB of the IV can be "0" for encryption by the requester and decryption by the responder, while the MSB of the IV can be "1" for encryption by the responder and decryption by the requester. Both the requester and the responder can understand this arrangement, thus eliminating the need to exchange this information. Choosing any other IV bit or exchanging this information would not result in any loss of functionality or security.

[0025] In all the aspects described, both the requester and the responder can use certain bits in the IV-LSB as “stage identifiers” (also known as “stage identifier bits”), which define a time window for a predetermined number of requests. For example, using the two most significant bits in the IV-LSB as stage identifiers in a “four-stage system” allows the requester to manage a sliding window of four stages (three active stages and one inactive stage). See below for more details. Figures 3A to 3B and Figure 5 The request and response can be exchanged simultaneously across three activity phases.

[0026] Figure 1An environment 100 for promoting sequential relaxation based on a sliding window for encrypted channels is illustrated according to one aspect of this application. Environment 100 may include a switch network 110, which may be referred to as a “switch fabric” or “network fabric,” and switch network 110 may include switches 112, 114, 116, 118, and 120. In switch fabric 110, each switch may have a unique address or identifier. Various types of endpoints, processing nodes, devices, and networks may be coupled to switch fabric. For example, storage array 130 may be coupled to switch fabric 110 via switch 112. Other networks 132 (e.g., HPC, Ethernet, InfiniBand, or any other network) may be coupled to switch fabric 110 via switch 12. Other networks 132 may include multiple networked computers and storage devices running concurrently to perform different complex and performance-intensive tasks. Other networks 132 may include application layer protocols between physical Ethernet cabling and Internet Protocol (IP)-based network devices, including communication via Transport Communication Protocol (TCP) / IP and User Datagram Protocol (UDP) packets. The switch structure 110 itself can be an Ethernet network or an HPC network.

[0027] Any number of endpoints, processing nodes, computing elements, or devices with computing elements (collectively, "devices") can also be coupled to switch structure 110. For example, devices 142 and 144 can be coupled to switch structure 110 via switch 114; devices 146 and 148 can be coupled to switch structure 110 via switch 118; and device 140 can be coupled to switch structure 110 via switch 120. Figure 1As shown, device 148 may include computing elements 150, which may include, for example, a central processing unit (CPU) 152, a graphics processing unit (GPU) 154, and an XPU 156, whereby the XPU 156 may be any processing unit, combination of processing units, or dedicated processing unit or hardware accelerator designed or optimized for a specific task. Similarly, device 142 may include computing elements 160, which may include, for example, a CPU 162, a GPU 164, and an XPU 166. Environment 100 may include more or fewer entities coupled to switch structure 110, and each device may include more or fewer computing elements than those described in computing elements 150. Entities coupled to switch structure 110 may include requesting nodes (“requesters”) and responding nodes (“responders”). Requesters may communicate with responders via a secure, encrypted channel, where each request sent by the requester expects a corresponding response from the responder. Requests and responses can flow between CPU / GPU / XPU blocks in different nodes, for example, between CPU / GPU / XPU 162 / 164 / 166 in node 142 and CPU / GPU / XPU 152 / 154 / 156 in node 148.

[0028] Generally, a switch can have edge ports and fabric ports. Edge ports can couple to devices outside the fabric. Fabric ports can couple to another switch within the fabric via fabric links. Typically, traffic can be injected into switch fabric 110 via the ingress port of an edge switch and can leave switch fabric 110 via the egress port of another (or the same) edge switch. Ingress links can couple the NIC of an edge device (e.g., an HPC terminal host) to the ingress edge port of an edge switch. Switch fabric 110 can then transmit the traffic to the egress edge switch, which can in turn transmit the traffic to the target edge device via another NIC. Packets can be forwarded within switch fabric 110 based on their Layer 2 address (“fab address”), which can be considered equivalent to the Media Access Control (MAC) address in Ethernet. The forwarding path for packets can be determined based on adaptive forwarding, for example, based on the local programming of the switches in switch fabric 110 and information related to the available and associated load, traffic, and congestion of switch fabric 110.

[0029] Figure 2AA bit field diagram 200 is shown, describing a complete IV 201 maintained by the requesting party according to one aspect of this application. The requesting party can generate the complete IV 201. The complete IV 201 can be generated by or based on a cryptographic counter (e.g., a Galois counter) and can contain a different number of bits. For example, the complete IV 201 can include 96 bits, such as: a non-counter field 202 [95:64]; a counter field 204 [63:0], which includes a stage value 206 [63:16] and a transaction number 208 [15:0]. The non-counter field 202 can include information used by the requesting party, the responding party, or other intermediate entities to process messages associated with the complete IV 201.

[0030] Counter field 204 can be used to identify the number of requests that have been sent by the requester using sequentially numbered IV-LSBs. Furthermore, transaction number 208 can indicate the LSB [15:0] of the complete IV 201, while IV-LSB 209 [17:0] can include these transaction number LSBs [15:0] as its LSB, and can also include the LSB [17:16] of stage value 206 as its MSB. These MSBs [17:16] of IV-LSB 209 [17:0] can be referred to as “stage identifier bits” because they can be used to clearly distinguish the stage of an incomplete transaction from the three currently active stages (in a four-stage system). Active stages can be sequentially numbered, allowing each stage to be distinguished based on its modulo-4 stage value (contained in the bits [17:16] of the IV, i.e., the LSB bits [17:16] of stage value 206).

[0031] Figure 2B A bit field diagram 210 is shown describing a portion IV 211 maintained by the responder according to one aspect of this application. The responder may maintain a portion IV 211, which may include: a non-counter field 212 [95:64]; and a counter field 214, which may include a stage value 216 [63:16]. The responder stage value 216 may include a stage identifier bit [17:16] as its LSB. The responder does not keep track of the count for each transaction number. The bottom 16 bits are not included in the bit range listed for portion IV 211 to facilitate the description of the synchronization of counter values ​​between the requester and the responder. The actual number of bits used to store portion IV 211 may be less than the highest number bit described for portion IV 211 (e.g., listed as 95, but maintained as 95-16=79).

[0032] Figure 2CA schematic diagram 270 of a hardware or data structure maintained by the requester according to one aspect of this application is shown. The requester may include in its hardware: a complete counter 272 that generates a stage value 273 and a transaction number 274; a counter field (e.g., 204) for the IV value of incomplete requests 275, i.e., a mechanism for tracking the counter field in the IV value for each incomplete request / transaction sent by the requester that is still awaiting a response; and an incomplete request counter (ORC) 276 that tracks the number of requests sent by the requester that are still awaiting a response. ORC 276 may include an ORC for each stage. For example, in a four-stage system, ORC 276 may include a stage_0 ORC, a stage_1 ORC, a stage_2 ORC, and a stage_3 ORC. Each ORC may be associated with an ORC value. Since, in this example, incomplete transactions at any given time may exist only in a maximum of three consecutively numbered stages, the stage numbers of simultaneously incomplete transactions can be distinguished by the modulo 4 value of the two LSBs of the stage number included in bits [17:16] of the IV. Therefore, four ORCs may be sufficient for the requester to keep track of the count of all incomplete transactions.

[0033] Figure 2D A schematic diagram 280 of a hardware or data structure maintained by a respondent according to one aspect of this application is shown. The respondent may include in its hardware a partial counter 282 that can generate a stage value 283 (e.g., in...). Figure 2B The values ​​are represented as bits [63:16]); a counter field 284 (also known as "previous stage value") for the IV values ​​of the current stage and one or more previous stages; and an IV value 285 (also known as "incomplete response") for received requests that are still waiting for a response to be sent. The following sections discuss... Figure 2G and 2H Operations 2058 and 2064 are used to further describe IV value 285.

[0034] Figure 2E illustrates a flowchart 2000 showing the operations of a requester when sending a request according to one aspect of this application. The operations performed by the requester can begin when the requester has one (or more) requests to send (2002). The requester uses a counter to generate a complete IV value (operation 2004). That is, the requester increments the counter and combines the counter value with a non-counter field, as described above regarding... Figure 2A And as described in the complete IV 201, including non-counter field 202 and counter field 204.

[0035] The requesting party determines whether to use the new stage (Decision 2006). The new stage can be indicated by the change in stage value 273 caused by the carry over to transaction number field 274 during increment operation 2004. If the new stage is not used, the operation continues at operation 2008. If the new stage is used, the requesting party determines whether the incomplete request counter (ORC) for the oldest active stage is zero (Decision 2016). The ORC for multiple stages can be stored by the requesting party, for example, as described above regarding... Figure 2C As described in ORC 276, one ORC is indicated for each stage.

[0036] If the ORC for the oldest active phase is zero (Decision 2016), the operation continues at Operation 2008. This oldest active phase becomes inactive; this new phase, along with the previous two phases, can be called the active phase. Transactions are only incomplete during the active phase. If the ORC for the oldest active phase is not zero (Decision 2016), the requester pauses and waits to receive responses(multiple) to decrement the ORC (Operation 2018). Therefore, Decision 2016 can be a blocking operation that does not unblock until all incomplete requests have received their corresponding responses, as discussed below. Figure 3A As described in 313 and 315.

[0037] If the phase is the same and unchanged (as indicated by the "No" branch of decision 2006), or if the phase has been changed to a new phase and the ORC for the oldest active phase is zero (as indicated by the "Yes" branch of decision 2016), the requester encrypts the request based on the shared key and the complete IV (Operation 2008). The requester stores the phase value and transaction number used to encrypt the request (Operation 2010). This phase value and transaction number can be used by the requester to subsequently decrypt the corresponding response, for example, as described above regarding... Figure 2C The counter field stores and describes the IV value of the incomplete request 285. The requester sends the encrypted request along with the IV-LSB (in plaintext) to the responder (Operation 2012), and the requester can increment its incomplete request counter for the current stage (Operation 2014). Flowchart 2000 is depicted as a loop because individual iterations are not independent; that is, when the requester blocks the sending of additional requests at decision 2016 and operation 2018, the current request sending and all future request sending are blocked.

[0038] Figure 2FA flowchart 2020 illustrates the operations of a requester upon receiving a response according to one aspect of this application. Responses to incomplete transactions can be received in any order, independent of the order in which the corresponding requests were sent. Operations performed by the requester can begin upon receiving the response (2022). The requester retrieves the stage value and transaction number used to encrypt the corresponding request (operation 2024), for example, as stored in... Figure 2C The stage value and transaction number in 285. The requester reconstructs the complete IV value by combining the retrieved stage value and transaction number with non-counter fields (Operation 2026). For example, the requester can obtain the stage value and transaction number from 285. Figure 2C Retrieve the previously stored stage value and transaction number of the request corresponding to the received response from field 275. The requester can also use non-counter field 202 (such as...). Figure 2A (As depicted in the complete IV 201) to reconstruct the complete IV.

[0039] The requester decrypts the response based on the shared key and the reconstructed complete IV (Operation 2028), and the requester decrements the ORC corresponding to the stage that matches the stage LSB bits [17:16] (Operation 2030). For example, the requester could decrement the ORC for stage _2, such as... Figure 2C The ORC is stored in ORC 276. If the response happens to match the last incomplete transaction in the oldest active phase, the operation that decrements the ORC to zero for the appropriate phase can end as part of decision 2016 in operation 2018, which is a pause or block performed by the requester (as shown in operation 2032). Flowchart 2020 is depicted as a linear flow rather than a loop (as in flowchart 2000) because each received response may have an independent flow. Unlike sending a request, there is no sequential dependency between received responses.

[0040] Figure 2G A flowchart 2040 illustrates the operations of a respondent upon receiving a request according to one aspect of this application. The operations performed by the respondent can begin when the respondent receives the request (2042). The order in which the respondent receives the requests may differ from the order in which the requesting party sends the requests. The request may be encrypted based on a shared key and a complete IV, and the request may include an IV-LSB in plaintext form. The respondent examines the received IV-LSB bits [17:16] to determine the stage number modulo 4 (operation 2044). For example: if both bits are “00”, it corresponds to stage 0; if both bits are “01”, it corresponds to stage 1; if both bits are “10”, it corresponds to stage 2; if both bits are “11”, it corresponds to stage 3. The following will discuss… Figure 3C Describes the movement between states in a specific active and inactive phase in a four-phase system.

[0041] The responder determines whether the received IV-LSB bits [17:16] match an inactive phase or any active phase (decision 2046). If the received IV-LSB bits match an inactive phase (decision 2046), the responder can determine that a "phase rollover" has occurred, meaning the responder has received a request whose IV-LSB bits indicate a modulo 4 phase number that does not correspond to any of the currently active phases. Therefore, the responder increments its phase counter (operation 2048). The responder adds the new phase value to the previous / current phase list (e.g., Figure 2D In step 284), the oldest stage entry is removed from the list (operation 2050, as mentioned above). Figure 2D (As described in section 284). The operation continues at operation 2052.

[0042] If the received IV-LSB bits match any active stage (decision 2046), the responder can determine that no stage rollover has occurred. The responder retrieves the stored stage value corresponding to the appropriate stage (operation 2052), i.e., the stage value whose stored value bits [17:16] match the IV-LSB bits [17:16] received in the request. The responder reconstructs the complete IV (operation 2054), i.e., by combining the received stage value, the received IV-LSB, and the non-counter field. The responder decrypts the request based on the shared key and the reconstructed IV (operation 2056). The responder stores the stage value and transaction number used to decrypt the current request for subsequent use in generating a response to the request (operation 2058), as described above regarding... Figure 2D As described in 285. Operation returns. Flowchart 2040 is described as a linear process rather than a loop (as in flowchart 2000) because there is neither a sequential dependency nor an implicit order between different transactions or between the order of requests and the order of responses.

[0043] Figure 2H A flowchart illustrating the operations of a respondent party when sending a response according to one aspect of this application is shown. The order in which the respondent party sends the response may differ from the order in which the corresponding request was received. The operations performed by the respondent party may begin when the respondent party has a response ready to be sent to the requester (2062). The respondent party retrieves the stage value and transaction number received along with the corresponding request (operation 2064), for example, as previously stored as part of operation 2058. Figure 2D The stage value and transaction number in 285. The responder reconstructs the complete IV by combining the retrieved stage value and transaction number with non-counter fields (Operation 2066). For example, the responder can obtain the stage value and transaction number from the stage value and transaction number in 285. Figure 2DRetrieve the previously stored stage value and transaction number for this response from field 285. The responder can also use non-counter field 212 (such as...). Figure 2B (as depicted in part IV 211) to reconstruct the complete IV.

[0044] The responder encrypts the response based on the shared key and the reconstructed complete IV value (operation 2068) and sends the encrypted response (without any plaintext IV-LSB) to the requester (operation 2070). That is, the responder does not include the IV-LSB in the response. The operation returns. Flowchart 2060 is described as a linear process rather than a loop (as in flowchart 2000) because there is neither a sequential dependency nor an implicit order between different transactions or between the order of requests and responses.

[0045] Figure 3A A schematic diagram 300 illustrating the operation of a requester sending a request and receiving a response based on a multi-stage sliding window according to one aspect of this application is shown. In Figure 300, several time snapshots are depicted, with each stage represented as a shaded rectangle (as in the indices of depicted patterns 302, 304, and 306), and the complete IV increasing upwards (308). Each rectangle also depicts the value of the MSB (Stage Identifier Bit) of the requester's IV-LSB. For example, when two bits are used for the stage identifier bit, the values ​​of these bits can include: {00, 01, 10, 11} in binary form; or {0, 1, 2, 3} in decimal form. These values ​​also correspond to the stage number modulo 4.

[0046] During each snapshot, the active phases of the sliding window are represented by a thick dashed border. A sliding window can be associated with multiple active phases and one inactive phase, depending on the number of phases tracked in the system. For example, in a four-phase system, a sliding window can be associated with three active phases and one currently inactive phase. Active phases can be represented by an unpatterned fill (304), in which requests can be sent using sequentially ordered IVs, and any number of requests can still be incomplete or awaiting a corresponding response. A currently inactive phase can be represented by a right-sloping line pattern (302), in which there are no incomplete requests. Phases depicted by a cross-shaded pattern (306) are not associated with the sliding window, either because the sliding window has not yet reached its phase number or because the sliding window has already passed those phases. These phases do not contain incomplete transactions—this is because if they did, the modulo-4 phase flags would not explicitly identify them.

[0047] Since the sliding window comprises four consecutive phases, the phases within the window can be explicitly described using only two LSBs of their phase numbers. Therefore, when it is known to be part of a window, the phase can be indicated based on the value of its phase identifier bit, such as "phase 00", "phase 01", "phase 10", or "phase 11". At intermediate phase time 310, the sliding window 320 can be associated with three active phases {00, 01, 10}, and the requester can send a request with sequentially ordered IV values ​​(311). In the sliding window 320, the current complete IV can be in active phase 10, where some requests have been sent and responses have arrived or are still pending (322), but other requests have not yet been sent (323) (i.e., for active phase 10 starting from the current value of the complete IV, there are no pending requests, as indicated by the cross-shading pattern in section 323 of phase 10).

[0048] Immediately before stage increment 312, the requester reaches the end of the active 10 stage in the sliding window 324 (i.e., the next request to be sent will use the new stage value, based on the carry-in to stage value 273 at increment counter 272) and performs a check (313) before rolling to the inactive stage. For example, the requester pauses sending requests and does not roll to the inactive stage until there are no incomplete responses in the oldest active stage (active 00 stage in the sliding window 324) (315).

[0049] Once it is determined that there are no more outstanding responses in the oldest active phase (active phase 00 in sliding window 324), the requester can perform phase roll and advance the sliding window up (to a new sliding window 326) as part of phase roll (319), as shown in 314, which shows the situation at the start of the next phase and continues into that new phase. That is, when there are no more outstanding responses in the oldest active phase (e.g., phase 00 in sliding window 324), the requester can begin sending a request in the next phase (e.g., phase 11 in sliding window 326) (317). The requester can advance the sliding window by setting the oldest active phase to an inactive phase, for example, as shown by the pattern fill of the oldest active phase 00 in sliding window 324 changing from no pattern at time 312 to a cross-shaded pattern at time 314.

[0050] Figure 3B A schematic diagram 330 illustrating the operation of a responder based on a multi-stage sliding window for receiving requests and sending responses according to one aspect of this application is shown. In Figure 330, multiple time snapshots are depicted, with each stage represented by a specific shaded rectangle (as in the indices depicting patterns 332, 334, and 336), and the complete IV increases in the upward direction (338). Figure 3ASimilar to Figure 300, each rectangle also depicts the value of the MSB (Stage Identifier Bit) of the requester's IV-LSB, for example, in binary form {00,01,10,11}.

[0051] During each snapshot, the three active phases of the sliding window are represented by thick dashed borders. The sliding window (e.g., for a four-phase system) can be associated with three active phases and one inactive phase. These active phases can be represented by an unpatterned fill (334), in which a request can arrive in any order along with an IV value from any of the three active phases. The responder can send responses to requests in any order during these active phases. The inactive phase can be represented by a right-sloping line pattern (332), in which no request has yet arrived. Phases in which the responder knows it is impossible for a request to arrive can be represented by a cross-shaded pattern (336). No request can arrive in these phases because these phases are known to fall outside the window that allows the requester to send a request.

[0052] At intermediate stage time 340, sliding window 350 can be associated with three active stages {00, 01, 10}, and the responder can track the current stage value (e.g., Figure 2B (216 in the middle) and store two previous stage values ​​(e.g., Figure 2D (284)(341). In sliding window 350, the responder only tracks the stage value and not the complete IV; that is, the responder does not store the IV-LSB as part of its stage counter value, but only uses the IV-LSB when constructing the complete IV for request decryption and response encryption.

[0053] At the point immediately preceding stage increment 342, the responder continues to track the current stage value (343). Although all requests in the oldest active window have been retired (i.e., in stage 00 of sliding window 352, all incomplete requests have received their corresponding responses), the responder is unaware of this (345) and has no need to be aware of it.

[0054] When a responder receives a request that matches a stage in the inactive stage range (11 stages in sliding window 354), the responder increments its stage value and stores two previous stage values ​​(347). The expected arrival window can "slide" or "scroll" (349) at time point 344: the oldest active stage can be set to an inactive stage, for example, as shown by the pattern fill of the oldest active 00 stage in sliding window 352 changing from no pattern at time 342 to a cross-shaded pattern at time 344; and an inactive stage can be set to an active stage, for example, as shown by the pattern fill of the next 11 stages in sliding window 352 changing from a right diagonal pattern at time 342 to no pattern at time 344.

[0055] Figure 3C The illustration depicts one aspect of this application based on Figure 3B A schematic diagram 360 illustrates the four states of a responder using an exemplary four-stage sliding window. The following section discusses... Figure 5 A description of the sliding window and appropriate IV-MSB used by the responder in response to an incoming request is provided. Figure 360 ​​illustrates a state diagram indicating the transitions between various states of the responder and the advancement of the sliding window based on the requests sent and responses received in each stage. During operation, after a reset operation 370, the responder may begin in state 362: inactive stage _3={11}. In this state, the responder may expect a request to arrive in the active stage {00,01,10}, where these bits correspond to the MSB or stage identifier bits of the received IV-LSB. Receiving a request in the active stage allows the responder to remain in this state (as indicated by the curved arrow 381 returning to state 362) until the responder receives a request (371) with a stage identifier bit pair set to {11}. The responder can then increment its stage value (372) and advance the expected arrival sliding window (similar to...). Figure 3B Operation 349 in the middle).

[0056] The responder can then enter state 364: Inactive phase _0 = {00}. In this state, the responder can expect requests in active phases {01, 10, 11} to arrive, where these bits correspond to the MSB or phase identifier bits of the received IV-LSB. Receiving requests in these active phases keeps the responder in this state (as indicated by the curved arrow 382 returning to state 364) until the responder receives a request (373) with a phase identifier bit pair set to {00}. Because this represents a “carry” or a different number in the MSB (IV-MSB) wrapping around to the responder’s phase counter value, the responder can store a copy of the current IV-MSB as the previous IV-MSB as described above with respect to element 218 of Figure 2. The responder can then increment its phase value (375), advancing the expected arrival at the sliding window (similar to...). Figure 3B Operation 349 in the middle).

[0057] The responder can then enter state 366: Inactive phase _1 = {01}. In this state, the responder can expect requests to arrive at active phases {10,11} corresponding to the previous IV-MSB and active phases {00} corresponding to the current IV-MSB. When the responder receives such a request (as indicated by the curved arrow 383 returning to state 366), the responder will remain in this state until the responder receives a request (377) with a phase flag pair set to {01}. The responder can then increment its phase value (378) and advance the expected arrival time through the sliding window (similar to...). Figure 3B Operation 349 in the middle).

[0058] The responder can then enter state 368: Inactive Phase _2 = {10}. In this state, the responder can expect requests to arrive at the active phase {11} corresponding to the previous IV-MSB and the active phase {00, 01} corresponding to the current IV-MSB. When the responder receives such a request (as indicated by the curved arrow 384 returning to state 368), the responder will remain in this state until the responder receives a request (379) with a phase flag bit pair set to {10}. The responder can then increment its phase value (380) and advance the expected arrival time to the sliding window (similar to...). Figure 3B Operation 349 in the middle).

[0059] The responder can then re-enter state 362 and continue with the operations described above for states 362, 364, 366, and 368, where the expected progress of the sliding window at each stage of the roll is anticipated, and the responder uses an appropriate IV-MSB, which depends on whether the received request corresponds to an active stage before or after a wrapback or carry.

[0060] Figure 4 A schematic diagram 400 is shown illustrating how a responder and a requester generate, derive, and increment an initial value (IV) according to one aspect of this application. In Figure 400, a complete IV may include: an IV-MSB 410 (e.g., 78 bits); and an IV-LSB 430 (e.g., 18 bits). A complete IV may include a non-counter field 412 (e.g., 48 bits) and a counter field 432 (e.g., 64 bits). The non-counter field 412 may include information known to both the requester and the responder, which may be because such information is shared knowledge or because such information is typically passed in the request and response message fields for reasons other than IV generation. The non-counter value may help ensure the uniqueness of the IV value used with any given key. For example, the non-counter field 412 may include a requester identifier (source identifier (ID) 414 [95:86]), a responder identifier (destination identifier 416 [85:76]), a message type 418 (e.g., request or response)

[75] , and other information 420 [74:64] that may be used for further processing of the message. The counter field 432 may include: a stage number (or stage value) 434 [63:18], where the two LSBs at [17:16] serve as stage identifier bits; and a transaction number 436 (e.g., 16 bits) [15:0]. The IV-LSB 430 may include [17:16] (which are the two LSBs of the stage number 434) and a transaction number (e.g., a 16-bit transaction number [15:0]).

[0061] The requester generates and maintains the complete IV [95:0] considering both the non-counter field and the counter field, or [63:0] considering only the counter field, while the responder maintains only a partial IV [63:16], also known as the responder's "stage number" or "stage value" (operation 450). The requester generates the complete IV 454 when encrypting the new request and encrypts the new request based on the shared key and the complete IV (operation 452). The complete IV 454 may include the requester ID, the responder ID, flags indicating the request message, and other information from the non-counter field 412. The complete IV 454 may also include the requester's 64-bit stage number or stage counter value (434). The requester sends the encrypted request along with the IV-LSB [17:0] portion of its 64-bit counter value [63:0] in plaintext (or its complete IV) to the responder (operation 456). The stage flag pair at [17:16] (460) can be the MSB (458) of the plaintext transmitted IV-LSB.

[0062] The responder receives the request and performs various operations (operation 462). For example, the responder compares the received stage identifier bit pair with bits [17:16] of the last three stage counter values ​​(i.e., stage numbers) used and stored by the responder to determine if a match exists. If a match exists, the responder uses the stage number with the matching stage identifier bit. If no match exists, the responder increments its own 48-bit stage number. (The above is about...) Figure 3B Operations 341 and 347 describe comparing bit pairs in the received plaintext transmission IV-LSB with bit pairs stored in the responder's stage counter value.

[0063] Next, the responder constructs a complete IV466 based on the determined value of its phase number and the received IV-LSB, and also decrypts the request based on the shared key and the constructed complete IV (operation 464). The complete IV 466 may include the requester ID, the responder ID, a flag indicating the request message, and other information not in the counter field 412. The complete IV 466 may also include a portion of the responder's IV (the 48-bit phase number or phase value as described in operation 450) and the IV-LSB 468 [17:0] received with the request. The LSB [17:16] of the responder's phase number (as described in operation 450) may overlap with the MSB [17:16] of the received IV-LSB 468 [17:0].

[0064] The responder encrypts the response that matches the received request based on the shared key and the same complete IV 474 (constructed from the received request (472)). The complete IV 474 can be similar to the complete IV 466, but in the complete IV 474, the responder encrypts the response using the same values ​​as the decryption request, instead of constructing a partial IV (i.e., the responder's stage counter) (472). Furthermore, some of the values ​​in the non-counter field 412 can vary in the complete IV 474 compared to the complete IV 466. For example, the requester ID and the responder ID can be interchanged (to indicate the source and destination of the interchange), and the message type can also change from "request" to "response". The responder sends the encrypted response to the requester (472) without sending the IV-LSB[17:0] back to the requester.

[0065] The requesting party receives the response and decrypts it (476) based on its shared key and the complete IV 478 used by the requesting party in the corresponding sending request. The complete IV 478 may include the responding party ID, the requesting party ID, a flag indicating the response message, and other information not in the counter field 412. The complete IV 478 may also include the requesting party's [stage counter + transaction number], which is the same value used when encrypting the corresponding sending request.

[0066] Figure 5 A schematic diagram 500 illustrating the operation of a responder based on a multi-stage sliding window with three active stages and one inactive stage, according to one aspect of this application, is shown, including the identification of which partial IV the responder uses when reconstructing the complete IV. In Figure 500, several time snapshots are depicted, where each stage is represented by a specific shaded rectangle (as depicted by the indices of patterns 502, 504, and 506), with the complete IV increasing in an upward direction (538). Figure 3B Similar to Figure 330, each rectangle is also depicted with the MSB (stage identifier bit) value of the requester's IV-LSB, for example, in binary form {00,01,10,11}.

[0067] During each snapshot, the three active phases of the sliding window are depicted with thick dashed borders. The sliding window (e.g., for a four-phase system) can be associated with three active phases and one inactive phase. Active phases can be represented by an unpatterned fill (504), in which requests can arrive in any order along with IV values ​​from any of the three active phases. Responders can send responses to requests in these active phases in any order, which will cause the corresponding requests to be retired by the requester or no longer marked as incomplete (e.g., by decrementing the ORC value for a given phase). An inactive phase can be represented by a right-sloping line pattern (502), in which no requests have yet arrived because there are still some incomplete requests in the oldest active phase. A phase in which no requests are likely to arrive can be represented by a cross-shaded pattern (506), in which no requests are likely to arrive.

[0068] Furthermore, for each group of {00, 01, 10, 11} in bits [17:16] of the requester's stage counter, all arrival requests sent based on the requester's IV-MSB can use the same high bits [63:18] as part of the IV-MSB. Therefore, bits [63:18] remain unchanged throughout the four stages of the "cycle" N, because the requester uses 2 for each of the four stages represented by {00, 01, 10, 11} in bits [17:16]. 16A request is sent using an IV. When all active phases are in the same such period N, all arriving requests can directly use the IV-MSB matching that period along with the appropriate phase identifier bits (as shown in IV_MSB[N]510). When the requester advances its complete IV to a value that results in a wrapback or carry of the bits in [63:18] (i.e., moving to the next period N+1), some arriving requests can use the IV-MSB for period N+1 (e.g., IV-MSB[N+1]512), while other arriving requests can still use the IV-MSB for period N (e.g., IV-MSB[N]510). The responder can determine the appropriate IV-MSB to use by determining a possible set of matching phase identifiers, which includes the LSB of the current value of a partial IV or the LSB of a previous partial IV value stored by the responder. The responder can further determine whether the two MSBs of the received IV-LSB match any of the possible set of matching phase identifiers. If a match is found (meaning the sliding window covers stages within the same period), the responder constructs the full IV based on a partial IV with two or more LSBs that match the IV-LSB. If no match is found (meaning the sliding window covers stages across different periods), the responder increments its partial IV and constructs the full IV based on the incremented partial IV. The responder may store the incremented partial IV. In some aspects, the responder may delete the value of a previously stored partial IV corresponding to a new inactive stage.

[0069] At time 550, sliding window 530 can be associated with three active phases {01, 10, 11} in the same period N, which corresponds to IV-MSB[N] 510. The next period N+1 can be associated with four inactive phases, which corresponds to IV-MSB[N+1] 512. The responder can keep track of the current phase counter and store two previous phase counters (i.e., IV-MSB[N], which include the appropriate two phase flag bits), as described above regarding... Figure 2B and 2D As described in 216 and 284. All arrival requests use an IV-MSB[N] value (540) that matches the appropriate stage identifier bit. The responder's state at time 550 can correspond to Figure 3C Status 364 in the middle.

[0070] At time 552, the sliding window has advanced (represented by sliding window 532). Since the advancement of the sliding window at time 552 results in a "carry" or "wrapback" of the requester's IV-MSB (where the stage flags [17:16] are {00}), the arriving request can use either the stored matching IV-MSB[N] value 514 or the current / new IV-MSB[N+1] value 516 (542). The responder's state at time 550 can correspond to... Figure 3C The status is 366.

[0071] At time 554, the sliding window has advanced (represented by sliding window 534). Since the advancement of the sliding window at time 554 results in the request arriving in the stages of the previous period N and the current period N+1, the arriving request can use either the stored matching IV-MSB[N] value 518 or the current / new IV-MSB[N+1] value 520 (544). The responder's state at time 554 can correspond to... Figure 3C Status 368.

[0072] At time 556, the sliding window has advanced (represented by sliding window 536). Since the advancement of the sliding window at time 554 results in requests arriving only in the current N+1 cycle, all arriving requests use an IV-MSB[N+1] value 524 (546) that matches the appropriate stage flag. At this point, the IV-MSB from the previous cycle (IV-MSB[N] 522) is no longer used, and all partial IVs associated with the previous cycle N no longer need to be stored (and can be deleted or marked to indicate free or available memory). The responder's state at 550 corresponds to... Figure 3C Status 362.

[0073] Figure 6A A flowchart 600 illustrating a sliding window-based sequential relaxation method for encrypted channels according to one aspect of this application is shown, including the operations of the requesting party. The system generates a complete IV (operation 602) associated with the round-trip communication between the requesting and responding parties in the network structure. For example, the requesting party may generate a cryptographic counter (such as a Galois counter), also referred to as a complete IV 201 including both a non-counter field 202 and a counter field 204. The initial value of the complete IV can be a value agreed upon by the requesting and responding parties, such as all zeros, a value adapted to the width of the multiple bits constituting the complete IV, or some other predetermined value. (See above regarding...) Figure 4 As described in section 450, the requesting party may maintain a complete IV, and the responding party may maintain a partial IV. The requesting and responding parties may also use a shared key, which has been agreed upon or determined before transmitting the encrypted request and encrypted response.

[0074] The system sends a request from the requester to the responder, indicating a secure value comprising multiple least significant bits (LSBs) of the complete IV, where two or more most significant bits (MSBs) identify a stage associated with a predetermined number of requests that can be sent by the requester to the responder in order or out of order (operation 604). For example, the requester may perform operations to generate and encrypt the request based on a shared key and the complete IV, and the requester may send the encrypted request along with the IV-LSBs (in plaintext) to the responder, as described above with respect to operations 2004, 2008, and 2012 in Figure 2E.

[0075] The system can increment the complete IV in response to sending the request (operation 606). For example, the requester can increment its complete IV in response to sending the request, as described above in the loop operation in flowchart 2000 of Figure 2E.

[0076] The system identifies a sliding window associated with the following by the requester: multiple active phases corresponding to a time window currently allowing the sending of a predetermined number of requests; and at least one inactive phase corresponding to a time window currently disallowing the sending of a predetermined number of requests (operation 608). For example, in Figure 3A At time 310, the requester can identify three active phases {00, 01, 10} and one inactive phase {11}, where the active and inactive phases are depicted based on specific shading or fill patterns (as described above). Figure 3A (As described in 302, 304 and 306).

[0077] The system determines, by the requester, whether all requests have been sent in the current phase (i.e., the most recent active phase) (Decision 610). If not all requests have been sent in the current phase (Decision 610), then the operation proceeds... Figure 6B The process continues at label A (describing the responder's actions) because no additional decision is needed regarding the sliding of the window at this point. That is, since the requester still has requests to send (out of a predetermined number of requests), the requester does not need to execute the first condition or perform checks related to determining whether to advance the sliding window. If all requests in the current phase have been sent (decision 610), the system proceeds to determine whether all incomplete responses have been received in the oldest active phase (decision 612). For example, in Figure 3A In this process, the requester sends a predetermined quantity (e.g., 2). 16When the request (number of requests) reaches the end of the phase (where the first condition or check yields a "Yes" result from decision 610), a check is performed to determine whether all incomplete responses have been received in the oldest active phase, as in decision 612 and as stated above regarding... Figure 3A As described in operation 313.

[0078] If not all outstanding responses have been received in the oldest active phase (Decision 612), the requester suspends sending any requests (i.e., suspends before phase rolling or before advancing the sliding window, as indicated by the "No" branch returning to Decision 612), while waiting for any outstanding responses for the oldest active phase. For example, as mentioned above regarding... Figure 3A As described above, the requester may pause sending the request and not roll to the inactive phase until there are no more pending responses in the oldest active phase (e.g., the active 00 phase in the sliding window 324 of operation 315 at time 312). As per Figures 2E to... Figure 2H As described, the requester can increment its own Unfinished Request Counter (ORC) value for each active stage in the sliding window when sending a request, and can also decrement its own ORC value when receiving a response to the request.

[0079] If all pending responses have been received in the oldest active phase (decision 612), the requester advances the sliding window by setting the oldest active phase to inactive and by setting the current inactive phase to active (operation 614), as described above regarding advancing the sliding window from sliding window 324 at time 312 to sliding window 326 at time 314. The operation is in... Figure 6B The process continues at label A (describing the responder's actions), and then continues at operation 616 after completing the actions at label A. The system receives a response from the requester in response to sending the request (operation 616). For example, the requester can receive the response and can begin operations from 2024 to 2030, as described above regarding... Figure 2F The flowchart in 2020 is shown. The response can correspond to a previously sent response that can be... Figure 2F The operations in 2024 and 2026 will determine the requests.

[0080] The system allows the requesting party to decrypt the response based on the shared key and the complete IV (Operation 618). The requesting party can decrypt the received response based on the shared key and complete IV previously used to encrypt the corresponding request, as described above. Figure 2F As described in Operation 2028. As another example, the requesting party can decrypt the response based on the shared key and the complete IV 478 (as in Operation 476), as mentioned above regarding... Figure 4 As described. Operation returned.

[0081] Figure 6B A flowchart 630 illustrates a method for facilitating sequential relaxation based on a sliding window for encrypted channels according to one aspect of this application, including operations by the responder. The system generates a partial IV by the responder based on the most significant bit (MSB) of the complete IV (operation 632). The responder can generate the partial IV based on the complete IV, i.e., based on a previously agreed start value or initial value. As above Figures 2A to 2D As shown, the portion of IV 211 maintained by the responder may include non-counter field 212 and counter field 214, and may be an MSB based on the full IV 201 (stage counter 206 [63:16] of non-counter field 202 [95:64] and counter field 204).

[0082] The system receives requests indicating security values ​​from the responder (Operation 634). For example, in Figure 4 In this process, the responder receives an encrypted request with an IV-LSB in plaintext form. Figure 4 (462 in the text). The requester may have already encrypted the request using a shared key and the complete IV, but the requester only transmits a portion of the complete IV (i.e., the IV-LSB) over the wire to the responder.

[0083] The responder constructs a complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. Specifically, the system determines a set of possible matching time identifiers, which includes two or more LSBs from the current or previous values ​​of the partial IV (Operation 636). For example, the responder can compare the received stage identifier bit pair with bits [17:16] of the last three stage counter values ​​(i.e., stage numbers) used and stored by the responder to determine if there is a match.

[0084] If a match is found between the two MSBs of the received security value and the set of possible matching stage identifiers (decision 638), the responder constructs a complete IV based on a partial IV having two or more LSBs that match the two or more MSBs of that security value (operation 640). As part of receiving, processing, or processing a request (received in operation 634), the responder may determine whether a match has been found. For example, after comparing the received stage identifier bit pairs with bits [17:16] of the last three stage counter values ​​(i.e., stage numbers) used and stored by the responder, if a match is found, the responder uses the stage number with the matching stage identifier bits, for example, as... Figure 2D One of the IVs tracked or stored in 284. The above text concerns operations 2042 and 2044, and... Figure 2GDecision 2046 describes the action taken by the responder upon receiving the request. The action continues at action 646.

[0085] If no match is found between the two MSBs of the received security value and the set of possible matching stage identifiers (decision 638), the responder will increment the partial IV in response to the determination of no match (operation 642). (See above regarding...) Figure 4 If no match is found, this indicates that the requester has performed a phase rollover after the check was performed (as mentioned above). Figure 3A (As described in 313, 315, and 317 above), this is because the responder has received a request for a new phase. Therefore, the responder can increment its own 48-bit phase number, for example, as described above regarding... Figure 2B 216 and Figure 4 The operation of the responder in section 462 is described.

[0086] The responder constructs the complete IV based on the incremented partial IV (operation 644), similar to operation 640, but using the incremented partial IV instead of the matching partial IV. For example, the responder can determine its partial IV (i.e., the incremented partial IV) based on the non-counter field 212 and the responder's stage value 216. The responder can construct the complete IV by combining the stage value with the received transaction number [15:0] or as a bit appended to the received transaction number [15:0], which was previously received from the requester as IV-LSB 209 [17:0]. The above is about... Figure 2G and Figure 2H Operations 2054 and 2066 in the middle and Figure 4 Operation 464, performed by the responder, describes the construction of the complete IV.

[0087] The system decrypts the request by the responder based on the shared key and the constructed complete IV (Operation 646). As mentioned above... Figure 4 As described in Operation 464, the responder can decrypt the request based on the shared key and the constructed complete IV.

[0088] The system responds to a request by sending a response encrypted with the shared key and the constructed complete IV, omitting the security value and the constructed complete IV (Operation 648). The respondent can obtain or generate a response to the decrypted request and send it back to the requester, where the response is encrypted using the same [key + IV] that the respondent used to decrypt the request. For example, in Figure 4In Operation 472, the responder encrypts and sends a response based on the complete IV 474, matching the received request (i.e., corresponding to or responding to the received request). The operation then returns, continuing to the previous state. Figure 6A Operation 608 in the context of the requester includes actions performed by the requester after receiving a response from the responder.

[0089] Figure 7 A computing system 700 based on a sliding window for sequential relaxation of encrypted channels is illustrated according to one aspect of this application. The computing system 700 includes a processor 702, a memory 704, and a storage device 706. The memory 704 may include volatile memory (e.g., random access memory (RAM)) that serves as managed memory and can be used to store one or more memory pools. Furthermore, the computing system 700 may be coupled to peripheral I / O user devices 710 (e.g., a display device 711, a keyboard 712, and a pointing device 713). The storage device 706 includes a non-transitory computer-readable storage medium and stores an operating system 716, instructions 718, and data 736. The computing system 700 may include a processor 702, a memory 704, and a storage device 706. Figure 7 The number of entities or instructions shown may be fewer or more.

[0090] When executed by computing system 700, instruction 718 can cause computing system 700 to perform the methods and / or processes described in this disclosure. Instruction 718 may include instructions executed by the requesting party (or by the requesting party function in computing system 700), such as instructions 720 to 726. Instruction 718 may also include instructions executed by the responding party (or by the responding party function in computing system 700), such as instructions 728 to 734. Specifically, instruction 718 may include instruction 720 for generating a complete IV associated with encrypted round-trip communication between the requesting party and the responding party in the network structure, as described above regarding... Figure 6A As described in operation 602.

[0091] Instruction 718 may also include instruction 722 for the requesting party to send a request indicating a security value to the responding party, the security value comprising a plurality of least significant bits (LSBs) of a complete IV. Two or more most significant bits (MSBs) of the security value may identify a stage associated with a predetermined number of requests that are permitted to be sent by the requesting party to the responding party in order or out of order, as described above regarding Figure 6A Operation 604 is described.

[0092] Instruction 718 may also include instruction 724, for the requester to identify a sliding window associated with: multiple active phases corresponding to a time window currently allowing the sending of a predetermined number of requests; and at least one inactive phase corresponding to a time window currently disallowing the sending of a predetermined number of requests, as described above regarding... Figure 6A The operation described in 612.

[0093] Instruction 718 may further include instruction 726, for the requester to advance the sliding window by setting the oldest active stage to an inactive stage and by setting the currently inactive stage to an active stage, as described above regarding... Figure 6A The operation described in 616.

[0094] Furthermore, instruction 718 may include instruction 728, used by the responder to generate a partial IV based on the most significant bit (MSB) of the complete IV, as described above. Figure 6B The operation described in 632.

[0095] Instruction 718 may further include instruction 730 for constructing a complete IV by the responder based on the partial IV, the security value indicated in the received request, and multiple previous partial IVs stored by the responder, as described above regarding Figure 6B Operations 636, decision 638, and operations 640 to 644 are described.

[0096] Instruction 718 may include instruction 732, used by the responder to decrypt the request based on the shared key and the constructed complete IV, as described above. Figure 6B Operation 646 is described.

[0097] Instruction 718 may also include instruction 734, for the responder to send an encrypted response to the requester based on the shared key and the constructed complete IV, as described above. Figure 6B The operation described in 648.

[0098] Instruction 718 may include more than Figure 7 Further instructions are shown. For example, instruction 718 may include instructions for performing the operations described above in relation to the following: Figures 2E to Figure 2H Flowchart; Figures 3A to 3B and Figure 5 Sliding window; Figure 3C State diagram; Figure 4 The generation, tracking, and maintenance of complete and partial IVs in the system; Figure 6A The operations shown in Figure B; and Figure 8 Instructions for CRM 800.

[0099] Data 736 may include data required as input or generated as output for the methods, operations, communications, and / or processes described in this disclosure. Specifically, data 736 may store at least: requests; security values; ordered security values; responses; initial values ​​(IVs); counter values; complete IVs; constructed complete IVs; incremented IV values; partial IVs; current or previous partial IV values; one or more MSBs or LSBs; a predetermined quantity; an identifier or indicator of a phase corresponding to a time window in which a certain number of requests can be sent; an indicator of an active or inactive phase; encrypted requests or responses; a shared key; a phase identifier; a phase identifier bit; a set of matching phase identifiers; a non-counter field; a counter field; IV-MSBs; IV-LSBs; a phase counter; a phase counter value; a phase number; a transaction number; multiple incomplete responses; incomplete request counter values; multiple requests sent in a phase; incomplete response counter values; and multiple corresponding responses received in a phase.

[0100] Figure 8 A computer-readable medium (CRM) 800 according to one aspect of this application is illustrated, which facilitates sequential relaxation based on a sliding window for encrypted channels. The CRM 800 may be a non-transient computer-readable medium or device storing instructions that, when executed by a computer or processor, cause the computer or processor to perform those instructions or execution methods. The CRM 800 may store instructions 810 for generating a complete IV associated with the round-trip communication between the requesting party and the responding party in a network structure, as described above regarding... Figure 6A As described in operation 602.

[0101] The CRM 800 can store instruction 820 for the requester to send a request indicating a security value to the responder, the security value comprising multiple least significant bits (LSBs) of a complete IV. Two or more most significant bits (MSBs) of the security value can identify a stage associated with a predetermined number of requests that are allowed to be sent by the requester to the responder, either sequentially or out of order. Sending the request, security value, and overlapping LSBs and MSBs are discussed above regarding... Figure 6A Operation 604 is described in detail.

[0102] CRM 800 can store instructions 830 for the requester to identify a sliding window associated with: multiple active phases corresponding to a time window currently allowing the sending of a predetermined number of requests; and at least one inactive phase corresponding to a time window currently disallowing the sending of a predetermined number of requests, as described above. Figure 6A The operation described in 612.

[0103] CRM 800 can store instruction 840, which is used by the requester to advance the sliding window by setting the oldest active stage to an inactive stage and by setting the currently inactive stage to an active stage, as mentioned above. Figure 6A The operation described in 616.

[0104] In addition, the CRM 800 can store instruction 850 for the responder to maintain a partial IV based on the most significant bit (MSB) of the complete IV, as mentioned above. Figure 6B The operation described in 632.

[0105] CRM 800 can store instructions 860 for constructing a complete IV by the responder based on partial IVs, a security value indicated in the received request, and multiple previous partial IVs stored by the responder, as described above. Figure 6B Operations 636, decision 638, and operations 640-644 are described.

[0106] The CRM 800 can store instruction 870, which is used by the responder to decrypt the request based on the shared key and the constructed complete IV, as mentioned above. Figure 6B Operation 646 is described.

[0107] CRM 800 can store instruction 880, which is used by the responder to send an encrypted response to the requester based on a shared key and the constructed complete IV, as mentioned above. Figure 6B The operation described in 648.

[0108] CRM 800 can include more Figure 8 The instructions shown are more numerous than those in the diagram. For example, the CRM 800 may include instructions for performing the operations described above in relation to the following: Figures 2E to... Figure 2H Flowchart; Figures 3A to 2B and Figure 5 Sliding window; Figure 3C State diagram; Figure 4 The generation, tracking, and maintenance of complete and partial IVs in the system; Figures 6A to 6B Operations within; and Figure 7 The instructions of the computing system 700.

[0109] The term "network device" refers to any device, component, or computing entity that can provide a communication channel for data packets sent from a "processing node" or "endpoint node." An example of a network device could be a switch, as discussed above. Figure 1The term "processing node" or "endpoint node" can refer to a device, component, or hardware component that can operate as a source or destination of data (including, for example, control packets or data packets). The processing node or endpoint node can be referred to as a "requester" or a "responder." The requester and responder can transmit data (e.g., requests or responses) to each other via a communication channel as a round-trip communication. The requester can generate an encrypted request and send it to the responder. The responder can decrypt the request, generate a response, and send the encrypted response back to the requester. The requester can then decrypt the response. Accordingly, the requester and responder can each operate via a communication channel (e.g., a network structure, such as...). Figure 1 The endpoint of the data sent by structure 110 in the document. Furthermore, the endpoint node or processing node can serve as both a requester and a responder. That is, the endpoint node or processing node can include both requester and responder functions, as described herein, including, for example... Figure 4 The operation and communication of the requester and responder as described in IV-MSB 410 and IV-LSB 430.

[0110] In general, the disclosed aspects provide a method, computational system, and computer-readable medium that facilitates sequential relaxation based on a sliding window for encrypted channels. In one aspect, the system generates and encrypts a complete IV associated with round-trip communication with a responder in a network structure. The system involves the requester sending a request indicating a security value to the responder, the security value comprising multiple least significant bits (LSBs) of the complete IV. Two or more most significant bits (MSBs) of the security value identify a phase associated with a predetermined number of requests that are allowed to be sent by the requester to the responder, either sequentially or out of order. The system involves the requester identifying a sliding window associated with: multiple active phases corresponding to a time window currently allowing the transmission of the predetermined number of requests; and at least one inactive phase corresponding to a time window currently disallowing the transmission of the predetermined number of requests. The system advances the sliding window by setting the oldest active phase to an inactive phase and setting the currently inactive phase to an active phase.

[0111] In one variation of this approach, the system involves the requester encrypting the request based on a shared key and the complete IV. The requester increments the complete IV in response to sending the request. The requester receives a response in response to sending the request to the responder. The requester decrypts the response based on the shared key and the complete IV used by the requester to encrypt the request.

[0112] In another variation of this approach, the system involves the responder generating a partial IV based on the most significant bit (MSB) of the complete IV. The system involves the responder receiving a request indicating a security value. The system involves the responder constructing a complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. The system involves the responder decrypting the request based on a shared key and the constructed complete IV. The system involves the responder sending an encrypted response to the requester based on the shared key and the constructed complete IV in response to the request.

[0113] In another variant, the responder sends a response, but without including a security value or the complete IV constructed.

[0114] In another variant, the responder constructs the complete IV by performing the following steps: The responder determines a set of possible matching time identifiers, which includes two or more least significant bits (LSBs) of at least one of the following: the current value of the partial IV; or the value of a previous partial IV stored by the responder. The responder determines whether two or more MSBs of the received security value match any of the possible matching time identifiers.

[0115] In another variant, the responder constructs the full IV by performing the following action: In response to the identification of a match, the responder constructs the full IV based on a partial IV that has two or more LSBs that match two or more MSBs of the security value.

[0116] In another variant, the responder constructs the full IV in response to no match being found by performing the following actions: The responder increments the partial IV. The responder constructs the full IV based on the incremented partial IV. The responder stores the incremented partial IV. The responder deletes the previously stored value of the partial IV corresponding to the current inactive phase.

[0117] In another variant, the requester advances the sliding window in response to: sending a predetermined number of requests for the most recent active phase; and determining that an incomplete response has been received for all requests sent for the oldest active phase.

[0118] In another variant, the requester identifies multiple incomplete responses by tracking multiple requests sent and corresponding responses received for each activity phase.

[0119] In another variant, the security value comprises 18 LSBs of the complete IV. The sliding window is associated with four phases, including three active phases and one inactive phase. The phase identifier bit in the security value includes two bits used to identify one of the four phases in the sliding window. Each phase corresponds to a time window in which the requester assigns 2 bits indicating the sequentially ordered security values.16 A request is sent to the responder.

[0120] In another variation, a predetermined number of requests may be sent by the requesting party to the responding party in or out of order. Responses corresponding to the predetermined number of requests may be sent by the responding party to the requesting party in or out of order. Responses corresponding to the predetermined number of requests may be received by the requesting party from the responding party in or out of order.

[0121] On the other hand, a computing system includes processing resources and storage devices for storing instructions, which, when executed by the processing resources, cause the processing resources to perform a method, such as... Figure 7 Instruction 718. These instructions or methods can be executed by either the requester or the responder. These instructions are used by the requester in the network structure to generate a complete IV associated with encrypted round-trip communication with the responder. The instructions are further used by the requester to send a request indicating a security value to the responder, the security value comprising multiple least significant bits (LSBs) of the complete IV, two or more most significant bits (MSBs) of the security value identifying a phase associated with a predetermined number of requests that are allowed to be sent by the requester to the responder, either sequentially or out of order. The instructions are further used by the requester to identify a sliding window associated with: multiple active phases corresponding to a time window in which the predetermined number of requests are currently allowed to be sent; and at least one inactive phase corresponding to a time window in which the predetermined number of requests are currently not allowed to be sent. The instructions are further used by the requester to advance the sliding window by setting the oldest active phase to an inactive phase and by setting the currently inactive phase to an active phase.

[0122] The instructions in the computing system are further used by the responder to generate a partial IV based on the most significant bit (MSB) of the complete IV. These instructions are further used by the responder to receive a request indicating a security value. These instructions are further used by the responder to construct a complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. These instructions are further used by the responder to decrypt the request based on the shared key and the constructed complete IV. These instructions are further used by the responder to send an encrypted response based on the shared key and the constructed complete IV to the requester in response to the request.

[0123] The computing system may include additional instructions, including those related to: Figure 2E to Figure 2H Flowchart; Figures 3A to 3B and Figure 5 Sliding window; Figure 3C State diagram; Figure 4 The generation, tracking, and maintenance of complete and partial IVs in the system; Figures 6A to 6B Operations within; and Figure 8 Instructions for CRM 800.

[0124] On the other hand, a non-transient computer-readable storage medium (or CRM) stores instructions for performing methods. These instructions or methods can be executed by either the requester or the responder. These instructions are used by the requester in the network structure to generate and encrypt a complete IV associated with round-trip communication with the responder. These instructions are further used by the requester to send a request indicating a security value to the responder, the security value comprising multiple least significant bits (LSBs) of the complete IV, two or more most significant bits (MSBs) of the security value identifying a phase associated with a predetermined number of requests that the requester is allowed to send to the responder sequentially or out of order. These instructions are further used by the requester to identify a sliding window associated with: multiple active phases corresponding to a time window currently allowing the sending of the predetermined number of requests; and at least one inactive phase corresponding to a time window currently disallowing the sending of the predetermined number of requests. These instructions are further used by the requester to advance the sliding window by setting the oldest active phase to an inactive phase and by setting the currently inactive phase to an active phase.

[0125] The instructions in the CRM are further used by the responder to generate a partial IV based on the most significant bit (MSB) of the complete IV. These instructions are further used by the responder to receive a request indicating a security value. These instructions are further used by the responder to construct a complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. These instructions are further used by the responder to decrypt the request based on the shared key and the constructed complete IV. These instructions are further used by the responder to send an encrypted response to the requester based on the shared key and the constructed complete IV in response to the request.

[0126] The CRM may include additional instructions, including those related to the following: Figure 2E to Figure 2H Flowchart; Figures 3A to 3B and Figure 5 Sliding window; Figure 3C State diagram; Figure 4 The generation, tracking, and maintenance of complete and partial IVs in the system; Figures 6A to 6B Operations within; and Figure 7 The instructions of the computing system 700.

[0127] The above description is intended to enable any person skilled in the art to make and use these aspects and examples, and is provided in the context of a particular application and its requirements. Various modifications to the disclosed aspects will be apparent to those skilled in the art, and the general principles defined herein can be applied to other aspects and applications without departing from the spirit and scope of this disclosure. Therefore, the aspects described herein are not limited to those shown, but are given the widest scope consistent with the principles and features disclosed herein.

[0128] Furthermore, descriptions of the foregoing aspects have been presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the aspects described herein to the disclosed forms. Therefore, many modifications and variations will be apparent to those skilled in the art. Additionally, the foregoing disclosure is not intended to limit the aspects described herein. The scope of the aspects described herein is defined by the appended claims.

Claims

1. A computer-implemented method, the method comprising: The requester in the network structure generates a complete initial value (IV), which is associated with the encryption of round-trip communication with the responder; The requesting party sends a request to the responding party to indicate a security value, the security value including: The multiple least significant bits (LSBs) of the complete IV, and Two or more most significant bits (MSBs) of the security value, the two or more most significant bits (MSBs) identifying the phase associated with a predetermined number of requests that the requester is allowed to send to the responder; The sliding window identified by the requester and associated with the following: Multiple activity phases, the multiple activity phases corresponding to a time window currently allowing the sending of the predetermined number of requests; and At least one inactive phase, the at least one inactive phase corresponding to a time window during which sending the predetermined number of requests is currently not permitted; and The requester advances the sliding window by setting the oldest active stage to an inactive stage and by setting the current inactive stage to an active stage.

2. The method of claim 1, further comprising: The request is encrypted using the shared key and the complete IV; Increment the complete IV in response to sending the request; Receive a response in response to sending the request to the responding party; as well as The response is decrypted based on the shared key used by the requesting party to encrypt the request and the complete IV.

3. The method of claim 1, further comprising: The responder generates a partial IV based on the most significant bit (MSB) of the complete IV; The responder receives the request indicating the security value; The responder constructs the complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. The responder decrypts the request based on the shared key and the constructed complete IV; as well as The responding party sends an encrypted response to the requesting party based on the shared key and the constructed complete IV in response to the request.

4. The method of claim 3, further comprising: The response is sent by the responder, wherein the response does not include the security value and the constructed complete IV.

5. The method of claim 3, wherein constructing the complete IV comprises: Determine a possible set of matching stage identifiers, the set of possible matching stage identifiers including two or more least significant bits (LSBs) of at least one of the following: The current value of the IV portion; or The value of the previous partial IV stored by the responder; and Determine whether two or more MSBs of the received security value match any of the possible matching stage identifiers.

6. The method of claim 5, wherein constructing the complete IV further comprises: In response to determining a match, the complete IV is constructed based on the partial IV of two or more LSBs that match the two or more MSBs of the security value.

7. The method of claim 5, wherein constructing the complete IV further comprises: In response to no match being found, perform the following actions: Increment the portion IV; The complete IV is constructed based on the incremented partial IV; Store the incremented portion of the IV; and Delete the previously stored value of the portion of IV corresponding to the current inactive phase.

8. The method as described in claim 1, in, The sliding window is advanced in response to the following: Requests to send the predetermined quantity for the most recent activity phase; and It has been determined that incomplete responses have been received for all requests sent for the oldest active phase.

9. The method of claim 1, further comprising: Multiple incomplete responses are identified by tracking multiple requests sent and corresponding responses received for each activity phase.

10. The method as described in claim 1, in, The security value comprises 18 LSBs of the complete IV; The sliding window is associated with four phases, including three active phases and one inactive phase. The stage identifier bit of the security value includes two bits, which identify one of the four stages in the sliding window; and Each stage corresponds to a time window, in which the requesting party indicates the sequentially arranged security values ​​2. 16 A request is sent to the responder.

11. The method as described in claim 1, in, The predetermined number of requests can be sent by the requesting party to the responding party in sequence or out of sequence; The responses corresponding to the predetermined number of requests can be sent by the responding party to the requesting party, either sequentially or out of order; and The responses corresponding to the predetermined number of requests may be received by the requesting party from the responding party in an orderly or unordered manner.

12. A computing system, comprising: Processing resources; as well as A storage device storing instructions, which, when executed by the processing resource, cause the processing resource to perform a method, the method comprising: The requester in the network structure generates a complete initial value (IV), which is associated with the encryption of round-trip communication with the responder; The requesting party sends a request to the responding party to indicate a security value, the security value including: The multiple least significant bits (LSBs) of the complete IV, and Two or more most significant bits (MSBs) of the security value, the two or more most significant bits (MSBs) identifying the phase associated with a predetermined number of requests that the requester is allowed to send to the responder; The sliding window identified by the requester and associated with the following: Multiple activity phases, the multiple activity phases corresponding to a time window currently allowing the sending of the predetermined number of requests; and At least one inactive phase, the at least one inactive phase corresponding to a time window during which sending the predetermined number of requests is currently not permitted; and The requester advances the sliding window by setting the oldest active stage to an inactive stage and by setting the current inactive stage to an active stage.

13. The computing system of claim 12, wherein the method further comprises: The request is encrypted using the shared key and the complete IV; Increment the complete IV in response to sending the request; Receive a response in response to sending the request to the responding party; as well as The response is decrypted based on the shared key used by the requesting party to encrypt the request and the complete IV.

14. The computing system of claim 12, wherein the method further comprises: The responder generates a partial IV based on the most significant bit (MSB) of the complete IV; The responder receives the request indicating the security value; The responder constructs the complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. The responder decrypts the request based on the shared key and the constructed complete IV; as well as The responding party sends an encrypted response to the requesting party based on the shared key and the constructed complete IV in response to the request, wherein the security value or the constructed complete IV is omitted from the response.

15. The computing system of claim 14, wherein constructing the complete IV comprises: Determine a possible set of matching stage identifiers, the set of possible matching stage identifiers including two or more least significant bits (LSBs) of at least one of the following: The current value of the IV portion; or The value of the previous partial IV stored by the responder; and Determine whether two or more MSBs of the received security value match any of the possible matching stage identifiers.

16. The computing system of claim 15, wherein constructing the complete IV further comprises: In response to determining a match, the complete IV is constructed based on the partial IV of two or more LSBs that match the two or more MSBs of the security value; as well as In response to no match being found, perform the following actions: Increment the portion IV; The complete IV is constructed based on the incremented partial IV; Store the incremented portion of the IV; and Delete the previously stored value of the portion of IV corresponding to the current inactive phase.

17. The computing system of claim 12, wherein advancing the sliding window responds to the following: Requests to send the predetermined quantity for the most recent activity phase; and It has been determined that incomplete responses have been received for all requests sent for the oldest active phase.

18. A non-transitory computer-readable medium storing instructions that, when executed by a processed resource, cause the processed resource to perform a method, the method comprising: The requester in the network structure generates a complete initial value (IV), which is associated with the encryption of round-trip communication with the responder; The requesting party sends a request to the responding party to indicate a security value, the security value including: The multiple least significant bits (LSBs) of the complete IV, and Two or more most significant bits (MSBs) of the security value, the two or more most significant bits (MSBs) identifying the phase associated with a predetermined number of requests that the requester is allowed to send to the responder; The sliding window identified by the requester and associated with the following: Multiple activity phases, the multiple activity phases corresponding to a time window currently allowing the sending of the predetermined number of requests; and At least one inactive phase, the at least one inactive phase corresponding to a time window during which sending the predetermined number of requests is currently not permitted; and The requester slides the window by setting the oldest active stage to an inactive stage and by setting the currently inactive stage to an active stage.

19. The non-transient computer-readable medium of claim 18, wherein the method further comprises: The request is encrypted using the shared key and the complete IV; Increment the complete IV in response to sending the request; In response to sending the request to the responding party, a response is received; and The response is decrypted based on the shared key used by the requesting party to encrypt the request and the complete IV. The sliding of the window responds to the following: Requests to send the predetermined quantity for the most recent activity phase; and It has been determined that incomplete responses have been received for all requests sent for the oldest active phase.

20. The non-transient computer-readable medium of claim 18, wherein the method further comprises: The responder generates a partial IV based on the most significant bit (MSB) of the complete IV; The responder receives the request indicating the security value; The responder constructs the complete IV based on the partial IV, the security value, and multiple previous partial IVs stored by the responder. The construction of the complete IV is further based on the current or previous value of the partial IV; and Constructing the complete IV includes incrementing the partial IV in response to determining that there is no match between two or more MSBs of the received security value and a possible set of matching stage identifiers; The responder decrypts the request based on the shared key and the constructed complete IV; and The responding party sends an encrypted response to the requesting party based on the shared key and the constructed complete IV in response to the request, wherein the security value and the constructed complete IV are omitted from the response.

Images