Widely applicable communication network encrypted data transmission method

Abstract

The invention belongs to the technical field of communication engineering and information security, particularly relates to a widely applicable communication network encrypted data transmission method, and aims to solve the problems of fragile key synchronization, high re-synchronization overhead and contradiction between security and performance caused by key management and data stream state separation in the prior art. Establishing an initial key and an updating rule through session initialization; the method comprises the following steps of: segmenting data blocks according to a serial number at a sending end, encrypting by adopting an AEAD algorithm, and executing a deterministic key updating function based on a ciphertext when each data block is encrypted so as to evolve a next key; and a receiving end decrypts in sequence and synchronously updates a decryption key, so that endogenous coupling of a cryptographic state and data stream processing is realized. By adopting the above technical scheme, the secret key state can be implicitly synchronized without out-of-band signaling, and the method has the performance of packet loss resistance, forward secrecy and adaptive security, and is suitable for efficient and secure communication in an unreliable network environment.

Description

Technical Field

[0001] This invention belongs to the field of communication engineering and information security technology, and specifically relates to a widely applicable method for encrypted data transmission in communication networks. Background Technology

[0002] Against the backdrop of the deep integration of information technology and communication engineering, data has become a core element driving social operation and economic development. Its secure and efficient flow within various communication networks forms the cornerstone of modern information systems. To protect data from threats such as eavesdropping, tampering, or forgery during transmission, cryptographic encryption has become an industry-recognized standard practice. Correspondingly, encrypted data transmission technology for communication networks has emerged and has been widely deployed and applied in many key areas such as financial transactions, instant messaging, cloud computing, and the Internet of Things. The security, efficiency, and universality of its technical solutions directly affect the stability and reliability of the entire information infrastructure.

[0003] The inherent disconnect between existing security mechanisms and data flow creates a dilemma between security and performance. Pursuing higher security through frequent key updates necessitates more intensive out-of-band negotiations, incurring significant performance overhead with limited wireless bandwidth and amplifying the risk of state synchronization failures. Conversely, reducing key update frequency to ensure smooth communication sacrifices system security, making it more vulnerable to attacks. This inherent contradiction demonstrates that existing technologies, attempting to force a state-dependent encryption model designed for stable network environments onto a dynamic and unpredictable network reality, suffer from inherent incompatibility, becoming a fundamental bottleneck restricting their widespread applicability.

[0004] Therefore, designing an encrypted data transmission mechanism that enables its key management system to achieve intrinsic and close coupling and synchronous evolution with the data stream itself, thereby freeing it from dependence on complex external negotiation mechanisms and adapting to dynamic and unreliable network transmission environments, while ensuring high security and achieving robustness, efficiency and wide applicability of the transmission process, has become a key challenge and an urgent technical problem for those skilled in the art. Summary of the Invention

[0005] The technical problem this invention aims to solve is to overcome the inherent contradictions between security and performance caused by the separation of encryption key management and data stream state in existing technologies, including the vulnerability of key synchronization in unreliable network environments, high resynchronization overhead, and the inherent conflict between security and performance. To achieve the above-mentioned objective, this invention provides a widely applicable method for encrypted data transmission in communication networks. This method constructs a deterministic cryptographic state machine driven by the data stream itself, intrinsically and strongly coupling the evolution of the key with the processing of each data block. This achieves implicit, block-by-block synchronization of the cryptographic states of both communicating parties without the need for additional out-of-band signaling negotiation, fundamentally improving the robustness, efficiency, and security of encrypted communication in dynamic, high-packet-loss network environments.

[0006] To achieve the above objectives, this invention provides a widely applicable encrypted data transmission method for communication networks, applied between a sending end and a receiving end. The method achieves implicit, block-by-block synchronization of the cryptographic states of both communicating parties by constructing a deterministic cryptographic state machine driven by the data stream itself. Specifically, it includes: S1, Session initialization: The sending end and the receiving end negotiate and establish an initial encryption key, an initial decryption key that is the same as the initial encryption key, and a key update rule for subsequent key evolution; S2, At the sending end, for each data block D_i carrying a unique sequence number i, the sending end encrypts the data block D_i using the current encryption key K_i in its cryptographic state context to generate an encrypted data block C_i. After the encryption operation is completed, the sending end immediately executes a deterministic key update function F_update according to the key update rule. The input of the key update function includes at least the current encryption key K_i and the generated encrypted data block C_i to calculate the next encryption key K_{i+1} used to encrypt the next data block and update its cryptographic state context. S3, Decryption at the receiving end: The receiving end obtains the corresponding encrypted data block C_j from the received data according to the sequence number j it expects to receive, and decrypts the encrypted data block C_j using the current decryption key K_j in its cryptographic state context. When decryption is successful, the receiving end executes the deterministic key update function F_update according to the same key update rule as the sending end. The input of the key update function includes at least the current decryption key K_j and the successfully decrypted encrypted data block C_j, so as to calculate the next decryption key K_{j+1} for decrypting the next data block, and update its cryptographic state context to ensure that the evolution of the receiving end's key state is strictly synchronized with the processing progress of the data stream.

[0007] Further, S1 includes: The sender and receiver exchange messages by exchanging key parameters. They use the ECDH protocol, a variant of the Diffie-Hellman key exchange, to generate a temporary elliptic curve public-private key pair and calculate the shared initial secret by exchanging the public key portion. The sending end and the receiving end each input the shared initial secret into a key derivation function (KDF) to derive the initial encryption key and the initial decryption key from the initial secret; The cryptographic state context of the sending end and the receiving end also each contains an initial key state variable, which is also derived from the initial secret by the key derivation function KDF.

[0008] Furthermore, before the sending and receiving ends calculate the shared initial secret using the ECDH protocol, S1 also integrates enhanced two-way authentication, including: S11, the sending end and the receiving end exchange their respective X.509 digital certificates issued by a trusted Certificate Authority (CA); S12, after receiving the other party's digital certificate, each party uses the pre-set CA public key to verify the certificate signature and checks the certificate's validity period and issuer information. S13. After the certificate verification is successful, both parties execute the challenge-response mechanism, in which one party sends a challenge value generated by a cryptographically secure pseudo-random number generator to the other party, and the other party uses the private key corresponding to its digital certificate to sign the challenge value through the Elliptic Curve Digital Signature Algorithm ECDSA, and returns the generated digital signature to the initiator for verification. S14, after both parties have successfully verified each other's digital certificates and signed the challenge value, they continue with the subsequent exchange of key parameters.

[0009] Furthermore, in S2, the encryption operation employs an algorithm with associated data authentication encryption AEAD features; The input to the AEAD algorithm includes the current encryption key K_i, the plaintext of the data block D_i, and a random number Nonce generated based on the sequence number i of the data block, which is unique in each encryption. The AEAD algorithm also processes the sequence number i of the data block itself as associated data; The output of the AEAD algorithm also includes an authentication tag Tag_i, which simultaneously guarantees the confidentiality and integrity of the encrypted data block C_i and the integrity of the sequence number i. In the decryption step at the receiving end, the receiving end uses the same AEAD algorithm, whose inputs include the current decryption key K_j, the encrypted data block C_j, the authentication tag Tag_j, the corresponding random number calculated based on the sequence number j, and the sequence number j as associated data. The condition for successful decryption is that the authentication tag Tag_j passes verification.

[0010] Furthermore, the cryptographic state context of the sending end includes not only the current encryption key K_i, but also a current key state variable S_i; The input to the deterministic key update function F_update is the current encryption key K_i, the current key state variable S_i, and the generated encrypted data block C_i; The output of the key update function F_update is the next encryption key K_{i+1} and the next key state variable S_{i+1}. The sending end uses this output to update its cryptographic state context. The cryptographic state context of the receiving end also includes the current key state variable S_j. The key update function F_update executed by it takes the current decryption key K_j, the current key state variable S_j, and the successfully decrypted encrypted data block C_j as input, and outputs the next decryption key K_{j+1} and the next key state variable S_{j+1}.

[0011] Furthermore, the deterministic key update function F_update is implemented using the HMAC-based extract-expand key derivation function HKDF, and the specific steps include: S21, extract HKDF, use the current key state variable S_i or S_j as a random value, and use the current encryption key K_i or the current decryption key K_j as the input key material IKM to generate a pseudo-random key PRK; S22, Extend HKDF, using the pseudo-random key PRK as input, and concatenating the encrypted data block C_i or C_j with a predefined string that identifies the key update context as input, and extend to generate an output key material OKM of a predetermined length; S23, the next encryption key K_{i+1} or K_{j+1} and the next key state variable S_{i+1} or S_{j+1} are separated from the output key material OKM.

[0012] Furthermore, S2 also includes: The sending end determines the data block size based on the maximum transmission unit of the current communication network path. The data block size is set to the maximum transmission unit of the path minus the header overhead of each layer of the network protocol stack and the transmission header overhead introduced by this method. When dividing the data to be transmitted into multiple data blocks, if the length of the last data block is less than the determined data block size, then a deterministic padding process is performed on the last data block.

[0013] Furthermore, in S2, the sending end encapsulates each encrypted data unit into a data packet for transmission, the data packet consisting of a header and a payload; The payload includes the encrypted data block C_i and its corresponding authentication tag Tag_i; The header contains key information for synchronization, including a sequence number i, a payload length field indicating the length of the payload portion, and a header checksum for verifying header integrity.

[0014] Furthermore, the method also includes a data block loss handling mechanism based on negative acknowledgment (NACK), specifically including: At the receiving end, if the data packet corresponding to its expected sequence number j is not received within the predetermined time, or if a large gap is detected in the sequence number of the data packet stored in its receiving buffer, the receiving end sends a retransmission request message to the sending end through the control channel. The message clearly indicates one or more sequence number ranges that need to be retransmitted. After receiving the retransmission request, the sending end searches for and retrieves the generated and stored encrypted data block C_i and authentication tag Tag_i with the corresponding sequence number from its historical transmission records, and retransmits them to the receiving end without having to re-encrypt the original data block.

[0015] Furthermore, the key update rule is dynamically adjustable, and the method further includes: The sending and receiving ends jointly maintain the key update frequency parameter N, with an initial value of 1, indicating that a key update is performed once for each data block; The sending and receiving ends assess the current network condition by continuously monitoring network transmission quality parameters, including round-trip time and packet loss rate. When the network quality is detected to meet the preset good conditions, the sending end initiates negotiation with the receiving end to adjust the key update frequency parameter N to an integer value greater than 1. After reaching an agreement, both parties synchronously change to execute the key update function F_update once every N data blocks processed. When network quality deterioration is detected, both parties negotiate to adjust the key update frequency parameter N back to 1 to achieve an adaptive balance between security and performance.

[0016] The technical solution provided by this invention constructs a self-synchronizing cryptographic state evolution system by atomically binding the lifecycle of the key to the processing flow of data blocks. This system completely eliminates the dependence on external key update negotiation signaling, fundamentally solving the key state synchronization problem caused by signaling loss in unreliable networks, a problem inherent in traditional schemes. Regardless of the degree of packet loss or out-of-order delivery, as long as the data blocks eventually arrive, the cryptographic state machines of both communicating parties can deterministically and independently evolve to a consistent state, exhibiting extremely high robustness. Simultaneously, the block-by-block key update mechanism provides excellent security features such as forward secrecy and recovery after corruption. This method is particularly suitable for communication scenarios with unstable or unpredictable network conditions, such as tactical ad hoc networks, deep space communication, industrial IoT, and cross-border high-latency links, and has broad engineering application value. Attached Figure Description

[0017] Figure 1 A flowchart illustrating the workflow of a widely applicable encrypted data transmission method for communication networks, as claimed in an embodiment of the present invention. Figure 2 This is a second flowchart illustrating a widely applicable encrypted data transmission method for communication networks, as claimed in an embodiment of the present invention. Figure 3 The third flowchart illustrates a widely applicable encrypted data transmission method for communication networks, as claimed in the embodiments of this invention. Detailed Implementation

[0018] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0019] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a mutually exclusive, independent, or alternative embodiment. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0020] To address security requirements, existing technologies in this field primarily revolve around the framework of establishing secure sessions between communicating entities. A commonly adopted approach involves the sender and receiver establishing a shared session key before data transmission via an independent key negotiation protocol, such as the Transport Layer Security (TLS) handshake process. Throughout the session's lifecycle, all data to be transmitted is encrypted using this fixed key, and the receiver uses the same key for decryption. This approach is advantageous because of its clear concept, relatively simple implementation, and the ability to support encrypted transmission of large amounts of data with a single negotiation. In scenarios with stable network conditions and controllable session duration, it effectively balances security overhead and communication efficiency. To further mitigate potential security risks arising from unchanging keys over long periods, such as statistical attacks or the cracking of historical data after key leakage, subsequent improvements introduce a periodic key update mechanism. Specifically, the communicating parties pre-agree on a time window or a data transmission threshold. Once this condition is met, the key negotiation process is restarted, generating and synchronizing a new session key to replace the old one. This mechanism, by shortening the effective usage time of a single key, enhances forward security to some extent and constitutes one of the core components of current mainstream secure communication protocols.

[0021] However, as communication networks evolve towards wireless, mobile, and IoT architectures, the heterogeneity, dynamism, and unreliability of network environments are becoming increasingly prominent. The traditional technical paradigm of key management, which relies on explicit negotiation at the session level, is showing significant limitations due to its inherent characteristics at the fundamental level. The core issue lies in the design philosophy of these solutions, which macroscopically binds the key's lifecycle to the communication session's lifecycle, while relatively separating it from the microscopic state of the data stream. This "asynchronous" or "weakly coupled" relationship between the security layer state key and the data transmission layer state packet sequence is not a problem in stable, reliable channels, but it can trigger a series of negative effects in network environments with high packet loss, high latency, or frequent switching. The reason is that key updates are usually driven by an external event independent of the data stream, such as a timer or control signaling interaction. When network conditions deteriorate, the signaling packets used to negotiate new keys also face the risk of loss or severe delay. This can easily lead to a loss of key synchronization between the communicating parties: the sender may have switched to the new key and started encrypting subsequent data, while the receiver, having failed to receive the negotiation signaling, still holds the old key, resulting in a series of data decryption failures. To correct this inconsistency, the system must introduce complex exception handling and resynchronization mechanisms, which not only significantly increases the complexity of the protocol and communication overhead but may also cause prolonged service interruptions during recovery, which is unacceptable for applications with high real-time requirements. Furthermore, the rigid data fragmentation strategy fails to dynamically adapt to the maximum transmission unit (MTU) of the underlying network, often leading to further fragmentation of data packets at the network layer. This exacerbates the probability of the entire encrypted data block failing to reassemble due to the loss of a single fragment, further worsening the vulnerability of key synchronization.

[0022] According to a first embodiment of the present invention, the present invention claims protection for a widely applicable method for encrypting data transmission in communication networks, referring to... Figure 1 This method, applied between the sending and receiving ends, achieves implicit, block-by-block synchronization of the cryptographic states of both communicating parties by constructing a deterministic cryptographic state machine driven by the data stream itself. Specifically, it includes: S1, Session initialization: The sending end and the receiving end negotiate and establish an initial encryption key, an initial decryption key that is the same as the initial encryption key, and a key update rule for subsequent key evolution; S2, At the sending end, for each data block D_i carrying a unique sequence number i, the sending end encrypts the data block D_i using the current encryption key K_i in its cryptographic state context to generate an encrypted data block C_i. After the encryption operation is completed, the sending end immediately executes a deterministic key update function F_update according to the key update rule. The input of the key update function includes at least the current encryption key K_i and the generated encrypted data block C_i to calculate the next encryption key K_{i+1} used to encrypt the next data block and update its cryptographic state context. S3, Decryption at the receiving end: The receiving end obtains the corresponding encrypted data block C_j from the received data according to the sequence number j it expects to receive, and decrypts the encrypted data block C_j using the current decryption key K_j in its cryptographic state context. When decryption is successful, the receiving end executes the deterministic key update function F_update according to the same key update rule as the sending end. The input of the key update function includes at least the current decryption key K_j and the successfully decrypted encrypted data block C_j, so as to calculate the next decryption key K_{j+1} for decrypting the next data block, and update its cryptographic state context to ensure that the evolution of the receiving end's key state is strictly synchronized with the processing progress of the data stream.

[0023] Further, S1 includes: The sender and receiver exchange messages by exchanging key parameters. They use the ECDH protocol, a variant of the Diffie-Hellman key exchange, to generate a temporary elliptic curve public-private key pair and calculate the shared initial secret by exchanging the public key portion. The sending end and the receiving end each input the shared initial secret into a key derivation function (KDF) to derive the initial encryption key and the initial decryption key from the initial secret; The cryptographic state context of the sending end and the receiving end also each contains an initial key state variable, which is also derived from the initial secret by the key derivation function KDF.

[0024] Furthermore, referring to Figure 2 Before the sending and receiving ends calculate the shared initial secret using the ECDH protocol, S1 also integrates enhanced two-way authentication, including: S11, the sending end and the receiving end exchange their respective X.509 digital certificates issued by a trusted Certificate Authority (CA); S12, after receiving the other party's digital certificate, each party uses the pre-set CA public key to verify the certificate signature and checks the certificate's validity period and issuer information. S13. After the certificate verification is successful, both parties execute the challenge-response mechanism, in which one party sends a challenge value generated by a cryptographically secure pseudo-random number generator to the other party, and the other party uses the private key corresponding to its digital certificate to sign the challenge value through the Elliptic Curve Digital Signature Algorithm ECDSA, and returns the generated digital signature to the initiator for verification. S14, after both parties have successfully verified each other's digital certificates and signed the challenge value, they continue with the subsequent exchange of key parameters.

[0025] In this embodiment, an encrypted communication session is established between the sending and receiving ends, setting initial conditions for the subsequent data-driven cryptographic state evolution process. Specifically, the sending and receiving ends negotiate and establish an initial encryption key, an identical initial decryption key, and key update rules for subsequent key deterministic evolution. This session initialization step is achieved by exchanging a series of predefined negotiation messages between the sending and receiving ends. The process begins with the sending end initiating a session request message to the receiving end. The data structure of this message includes an identity identifier field to uniquely identify the sending end and a list field of supported encryption algorithms. This list details the symmetric encryption algorithm suites supported by the sending end for block encryption, including parameters such as algorithm identifier, key length, and operating mode. After receiving and parsing the session request message, the receiving end returns a session response message, which includes the receiving end's identity identifier and an encryption algorithm suite selected from the algorithm list provided by the sending end. Subsequently, both parties securely generate a shared initial key by exchanging key parameter exchange messages.

[0026] In a specific implementation, this process employs an elliptic curve variant of Diffie-Hellman key exchange, ECDH. The sending and receiving ends each generate a temporary elliptic curve public-private key pair and exchange their public key portions. Subsequently, each uses its own private key and the other's public key to compute a shared initial secret. This initial secret is then fed into a key derivation function (KDF), such as the HMAC-based extract-expand key derivation function (HKDF) conforming to RFC 5869, to generate initial encryption and decryption keys of predetermined length and high cryptographic strength. Key update rules are also precisely synchronized at this stage by exchanging rule identifiers or rule parameters, ensuring that both parties use identical state transition functions.

[0027] Furthermore, as a preferred embodiment of the present invention, the session initialization step also integrates a strengthened two-way authentication sub-step to prevent man-in-the-middle attacks and ensure the legitimacy of the communicating entities. This authentication sub-step employs a digital certificate and challenge-response mechanism based on the X.509 standard v3.

[0028] Specifically, the sender first sends its digital certificate to the receiver. This certificate is issued by a trusted Certificate Authority (CA) and contains the sender's public key, subject information, and the CA's digital signature. Upon receiving the certificate, the receiver verifies the signature using a pre-set CA public key and checks fields such as the certificate's validity period, issuer, and scope of use to confirm its authenticity and validity.

[0029] Subsequently, the receiving end sends its own digital certificate to the sending end, which then performs the same verification process. Only after both certificates have been successfully verified does the subsequent key parameter exchange proceed. To further enhance security, a challenge-response mechanism is embedded in the verification process. The sending end generates a 256-bit challenge value using a cryptographically secure pseudo-random number generator and sends it to the receiving end. The receiving end uses its private key, corresponding to its certificate, to sign the challenge value using the Elliptic Curve Digital Signature Algorithm (ECDSA) conforming to the FIPS PUB 186-4 standard, and returns the generated digital signature to the sending end. The sending end verifies the signature using the public key in the receiving end's certificate. Conversely, the receiving end also initiates the same challenge-response process to the sending end. Only when both parties have successfully verified each other's signatures is the authentication sub-step complete, and the entire session initialization process continues.

[0030] Furthermore, in S2, the encryption operation employs an algorithm with associated data authentication encryption AEAD features; The input to the AEAD algorithm includes the current encryption key K_i, the plaintext of the data block D_i, and a random number Nonce generated based on the sequence number i of the data block, which is unique in each encryption. The AEAD algorithm also processes the sequence number i of the data block itself as associated data; The output of the AEAD algorithm also includes an authentication tag Tag_i, which simultaneously guarantees the confidentiality and integrity of the encrypted data block C_i and the integrity of the sequence number i. In the decryption step at the receiving end, the receiving end uses the same AEAD algorithm, whose inputs include the current decryption key K_j, the encrypted data block C_j, the authentication tag Tag_j, the corresponding random number calculated based on the sequence number j, and the sequence number j as associated data. The condition for successful decryption is that the authentication tag Tag_j passes verification.

[0031] Furthermore, the cryptographic state context of the sending end includes not only the current encryption key K_i, but also a current key state variable S_i; The input to the deterministic key update function F_update is the current encryption key K_i, the current key state variable S_i, and the generated encrypted data block C_i; The output of the key update function F_update is the next encryption key K_{i+1} and the next key state variable S_{i+1}. The sending end uses this output to update its cryptographic state context. The cryptographic state context of the receiving end also includes the current key state variable S_j. The key update function F_update executed by it takes the current decryption key K_j, the current key state variable S_j, and the successfully decrypted encrypted data block C_j as input, and outputs the next decryption key K_{j+1} and the next key state variable S_{j+1}.

[0032] Furthermore, referring to Figure 3 The deterministic key update function F_update is implemented using the HMAC-based extract-expand key derivation function HKDF, and the specific steps include: S21, extract HKDF, use the current key state variable S_i or S_j as a random value, and use the current encryption key K_i or the current decryption key K_j as the input key material IKM to generate a pseudo-random key PRK; S22, Extend HKDF, using the pseudo-random key PRK as input, and concatenating the encrypted data block C_i or C_j with a predefined string that identifies the key update context as input, and extend to generate an output key material OKM of a predetermined length; S23, the next encryption key K_{i+1} or K_{j+1} and the next key state variable S_{i+1} or S_{j+1} are separated from the output key material OKM.

[0033] Furthermore, S2 also includes: The sending end determines the data block size based on the maximum transmission unit of the current communication network path. The data block size is set to the maximum transmission unit of the path minus the header overhead of each layer of the network protocol stack and the transmission header overhead introduced by this method. When dividing the data to be transmitted into multiple data blocks, if the length of the last data block is less than the determined data block size, then a deterministic padding process is performed on the last data block.

[0034] Furthermore, in S2, the sending end encapsulates each encrypted data unit into a data packet for transmission, the data packet consisting of a header and a payload; The payload includes the encrypted data block C_i and its corresponding authentication tag Tag_i; The header contains key information for synchronization, including a sequence number i, a payload length field indicating the length of the payload portion, and a header checksum for verifying header integrity.

[0035] In this embodiment, the sending end performs a data preparation step, which aims to transform a continuous application-layer data stream, such as a video file to be transmitted, into a series of discrete data units suitable for block-by-block encryption and state synchronization. The sending end first dynamically obtains the maximum transmission unit of the current network path by performing a path MTU discovery (PMTUD). In the network environment of this embodiment, the obtained path MTU is 1500 bytes; based on this value, the sending end calculates the optimal data block size.

[0036] The specific calculation process is as follows: 1500-byte MTU minus 20-byte IPv4 header minus 8-byte UDP header minus the 16-byte custom transmission header overhead defined in this invention (including sequence number, length, checksum, and authentication tag overhead, generated by AES-256-GCM) yields 1440 bytes. To ensure alignment with the AES packet size, this value is an integer multiple of 16 bytes. The sender then divides the data into multiple 1440-byte blocks sequentially and without overlap, starting from the beginning of the data to be transmitted. When the total size of the data to be transmitted is not an integer multiple of 1440 bytes, the length of the last data block will be less than 1440 bytes. In this case, the sender performs PKCS#7 standard padding on the last data block. For example, if the last data block is 1430 bytes long, 10 bytes of padding are needed, each with a value of 0x0A.

[0037] Next, each data block is assigned a unique, monotonically increasing 64-bit unsigned integer sequence number, represented in big-endian byte order and starting from an initial value of 0x00000000000000000. This sequence number is crucial for achieving ordered reassembly and state synchronization at the receiving end. Finally, this sequence number is logically associated with the corresponding data block to form an intermediate data structure, ready for subsequent encryption processing.

[0038] Subsequently, the encryption step is performed at the sending end, which is the core of the data-driven cryptographic state evolution of this invention. The sending end maintains a cryptographic state context, which is a structure in memory containing the current encryption key, the current key state variable, and the next 64-bit sequence number to be used. When processing data block D_i with sequence number i, the sending end first encrypts data block D_i using the current encryption key K_i in its state context. The encryption operation uses the AES-256-GCM algorithm with the associated data authentication encryption (AEAD) feature. The input to the encryption function includes: a 256-bit key K_i, the plaintext data block D_i, and a 96-bit unique random number Nonce. This Nonce is obtained by performing a bitwise XOR operation between the lower 64 bits of a 96-bit initial Nonce securely generated during the session initialization phase and the current 64-bit sequence number i. This ensures that the Nonce is never repeated for each encryption operation with the same key; in addition, the 64-bit sequence number i of the data block itself is input as associated data into the AES-256-GCM algorithm. The output of the encryption operation is an encrypted data block C_i, which is the same length as D_i, and a 128-bit authentication tag Tag_i. This authentication tag not only protects the confidentiality and integrity of C_i, but also protects the integrity of the sequence number i, preventing attackers from tampering with the sequence number of the data packet.

[0039] After the encryption operation is completed, the sending end immediately updates its cryptographic state context according to the preset key update rule to prepare for encrypting the next data block. The key update rule is implemented as a deterministic key update function F_update. The input of the function F_update is the current encryption key K_i, the current key state variable S_i, and the newly generated encrypted data block C_i. Its output is the next encryption key K_{i+1} and the next key state variable S_{i+1}. Specifically, the internal implementation of the function F_update is also based on HKDF-SHA256: First, the HKDF extraction step is performed, using the current key state variable S_i as salt and the current encryption key K_i as the input key material IKM to generate a 256-bit pseudo-random key PRK. That is, PRK = HKDF-Extract(S_i, K_i). Next, the HKDF expansion step is executed. Using PRK as input, the encrypted data block C_i is concatenated byte-wise with a fixed ASCII string identifying the key update context, such as "key_update_v1.0", and this concatenation is used as the info input to generate a 512-bit output key material OKM. That is, OKM = HKDF - Expand(PRK, C_i || "key_update_v1.0", 64), where 64 represents the expected output byte length. Finally, the next encryption key K_{i+1} is extracted from the first 256 bits (32 bytes) of OKM, and the next key state variable S_{i+1} is extracted from the last 256 bits (32 bytes). The sender then overwrites the corresponding values ​​in its cryptographic state context with K_{i+1} and S_{i+1}, and increments the sequence number to be used by one. This process tightly binds the result of the encryption operation to the evolution of the key, making each step of the key chain deterministically dependent on the encryption result of the previous step, forming a cryptographic ratchet that cannot be predicted or forged by attackers.

[0040] Subsequently, the sending end transmits the encrypted data units sequentially to the receiving end via the communication network. Each transmitted data packet consists of a 16-byte header and a variable-length payload. The header structure is defined as follows: a 64-bit big-endian sequence number i, a 16-bit big-endian payload length field indicating the total number of bytes in the payload, and a 16-bit CRC-16-CCITT checksum, which is calculated only for the first 10 bytes of the sequence number and length field. The payload is composed of encrypted data blocks C_i and their corresponding 128-bit authentication tag Tag_i concatenated sequentially. The sending end sends these data packets out via UDP sockets in ascending order of sequence number, starting from 0.

[0041] Furthermore, the method also includes a data block loss handling mechanism based on negative acknowledgment (NACK), specifically including: At the receiving end, if the data packet corresponding to its expected sequence number j is not received within the predetermined time, or if a large gap is detected in the sequence number of the data packet stored in its receiving buffer, the receiving end sends a retransmission request message to the sending end through the control channel. The message clearly indicates one or more sequence number ranges that need to be retransmitted. After receiving the retransmission request, the sending end searches for and retrieves the generated and stored encrypted data block C_i and authentication tag Tag_i with the corresponding sequence number from its historical transmission records, and retransmits them to the receiving end without having to re-encrypt the original data block.

[0042] In this embodiment, at the receiving end, a receiving step is performed. The receiving end's dedicated I / O thread continuously listens on a designated UDP port to receive data packets from the sending end. Whenever a data packet arrives, the receiving end first reads the payload length field in the header and checks if the received data packet size is complete based on this length. Then, it recalculates the CRC-16-CCITT checksum of the first 10 bytes of the header and compares it with the checksum field in the data packet. If the checksum fails or the length does not match, the data packet is considered corrupted during transmission and is silently discarded. If the checksum succeeds, the 64-bit sequence number i is parsed, and the encrypted data block C_i and the authentication tag Tag_i are extracted. Due to the unreliability of network transmission, the received data packet sequence number may be out of order or discontinuous. Therefore, the receiving end maintains a receive buffer in memory based on a hash table to temporarily store out-of-order data packets, where the key is the 64-bit sequence number and the value is a data structure containing encrypted data and the authentication tag. Simultaneously, the receiving end maintains the expected sequence number j, with an initial value of 0.

[0043] Subsequently, the decryption step is performed at the receiving end, mirroring the encryption step at the sending end and synchronously advancing the cryptographic state machine at the receiving end. The processing logic at the receiving end is strictly driven by its expected sequence number j. A separate decryption processing thread continuously checks whether a data packet with sequence number j exists in the receive buffer. If it exists, the encrypted data block C_j and authentication tag Tag_j of the data packet are retrieved from the buffer, and decrypted using the current decryption key K_j in its locally maintained cryptographic state context, which is completely consistent with the initial state of the sending end. The decryption operation also uses the AES-256-GCM algorithm. The inputs to the decryption function include: key K_j, encrypted data block C_j, authentication tag Tag_j, nonce N_j calculated according to the same rules as the sending end, and sequence number j as associated data. The AES-256-GCM decryption process first verifies the authentication tag Tag_j. If the authentication tag verification fails, it means that the data has been tampered with during transmission, the key does not match, or the sequence number does not match. The receiving end will discard the data block and record a decryption failure event, expecting the sequence number j to remain unchanged, and the state machine will stagnate. If both decryption and authentication are successful, the original data block D_j is obtained.

[0044] Successful decryption is the sole prerequisite for the receiving end's cryptographic state machine to advance. Once data block D_j is successfully recovered, the receiving end immediately executes the same key update function F_update as the sending end, using the current decryption key K_j, the current key state variable S_j, and the just successfully decrypted encrypted data block C_j as input. It calculates the next decryption key K_{j+1} and the next key state variable S_{j+1} in the exact same way, i.e., (K_{j+1}, S_{j+1}) = F_update(K_j, S_j, C_j). Subsequently, the receiving end updates its cryptographic state context with the new key and state variables, and increments the expected sequence number j by 1. Then, the decryption thread continues to loop, checking whether there is a data packet corresponding to the new expected sequence number j in the receive buffer.

[0045] This mechanism ensures that the receiver can only obtain the correct key to decrypt the next data block after the previous data block has been correctly processed, thus achieving strict and deterministic synchronization between the key state and the data stream processing progress. If the data packet with expected sequence number j has not yet arrived due to network loss, the receiver's cryptographic state machine will remain in its current state, waiting for the arrival or retransmission of the data packet.

[0046] Finally, the data reconstruction step is performed. The receiving end successfully decrypts and removes any padding from the data block D_j, if present, and stores it in a first-in-first-out (FIFO) output buffer. Since the decryption process is strictly performed according to the sequence number j, the data blocks stored in the output buffer are inherently ordered. The upper-layer application can read the data from this output buffer in order and securely, thereby recovering the original data stream that is completely consistent with the sending end before encryption. This step also includes a mechanism for handling lost data blocks. The receiving end's decryption thread maintains a timer. If the data packet with the expected sequence number j is not received within a preset time window, or if a large gap is detected between the arrived sequence number in the receiving buffer and the expected sequence number j, the receiving end will send a retransmission request to the sending end through a separate control channel also protected by the method of this invention. This request message explicitly indicates one or more sequence number ranges that need to be retransmitted. After receiving the request, the sending end finds the encrypted data block C_i with the corresponding sequence number and the authentication tag Tag_i in a sent data packet buffer in its memory and retransmits it. Since the evolution of the key state is deterministic, the sender does not need to re-perform encryption calculations; it only needs to retransmit the existing encrypted data, which greatly reduces the computational overhead of retransmission.

[0047] Furthermore, the key update rule is dynamically adjustable, and the method further includes: The sending and receiving ends jointly maintain the key update frequency parameter N, with an initial value of 1, indicating that a key update is performed once for each data block; The sending and receiving ends assess the current network condition by continuously monitoring network transmission quality parameters, including round-trip time and packet loss rate. When the network quality is detected to meet the preset good conditions, the sending end initiates negotiation with the receiving end to adjust the key update frequency parameter N to an integer value greater than 1. After reaching an agreement, both parties synchronously change to execute the key update function F_update once every N data blocks processed. When network quality deterioration is detected, both parties negotiate to adjust the key update frequency parameter N back to 1 to achieve an adaptive balance between security and performance.

[0048] In this embodiment, the sending and receiving ends jointly maintain a key update frequency parameter N, initially set to 1, indicating that a key update is triggered for each data block. The two parties periodically exchange encrypted messages containing network statistics, such as packet loss rate and RTT jitter over the past minute, via a control channel. When the sending end detects a significant improvement in network quality—for example, a packet loss rate below 0.1% and RTT jitter less than 5 milliseconds for one consecutive minute—it sends a control message to the receiving end, proposing to adjust the key update frequency parameter N to a larger value, such as N=16. This message specifies the starting sequence number from which this change takes effect, for example, at the 100th sequence number after the current sequence number. After receiving and confirming the proposal, the receiving end and the two parties will synchronously switch the update rule when the specified sequence number arrives. In the N=16 mode, the key update function F_update only processes sequence number k. In step 16-1, where k is a positive integer, the encryption / decryption key is invoked only after the last block of data is processed. While processing other blocks, the encryption / decryption key remains unchanged. However, the sequence number i used to generate the Nonce is still incremented block by block, ensuring the uniqueness of the Nonce for each encryption operation and maintaining basic cryptographic security. When network quality deterioration is subsequently detected, both parties negotiate a similar process to reset the value of N back to 1, restoring the highest security level and enhancing resistance to data tampering and injection attacks. This dynamic adjustment mechanism significantly optimizes computational overhead in good network environments while maintaining basic security, achieving an adaptive balance between security and performance.

[0049] After all application-layer data transmissions are complete, the system executes the session termination procedure. The sending end constructs a special session termination message, the data block portion of which is a predefined termination identifier, encrypted and authenticated using the current cryptographic state context. Its sequence number is the sequence number of the last data block plus one. After successfully decrypting and verifying this message, the receiving end identifies the termination identifier and constructs a termination confirmation message with the same encryption and authentication, returning it to the sending end. Upon receiving the confirmation, both parties securely destroy all cryptographic resources related to this session. The destruction operation is achieved by calling the secure memory erase interface provided by the operating system or manually performing three overwrite operations on the RAM area storing the keys and state variables, ensuring that sensitive information cannot be recovered by subsequent memory forensics tools. Simultaneously, the system records the metadata logs of this session, such as session duration, total number of bytes transmitted, total number of retransmissions, and average throughput, in a local audit log file for subsequent performance analysis and security auditing.

[0050] To verify the actual effect of the technical solution of the present invention, we conducted a set of comparative experiments.

[0051] This embodiment uses the aforementioned C++ application based on the "A Widely Applicable Encrypted Data Transmission Method for Communication Networks" of this invention. The test environment consists of two identical servers connected via a network simulator. The simulation parameters are set to a 2% random packet loss rate, a 500ms RTT, and ±50ms latency jitter. The test task is to transmit a 100MB video file. The key update frequency parameter N is set to 1, meaning the key is updated block by block.

[0052] The comparison example uses an application based on the standard DTLS 1.2 protocol, implemented using the OpenSSL library. It runs in the exact same hardware and network simulation environment as Example 1, transmitting the same 100MB video file. The DTLS 1.2 cipher suite was chosen as TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 to ensure comparability with the encryption algorithm in Example 1. When facing packet loss, the retransmission mechanism of the DTLS protocol's record layer and handshake protocols relies on timeouts, which can easily lead to connection stalls and renegotiations in high-latency and high-packet-loss environments.

[0053] The technical solution of this invention demonstrates significant advantages in simulated harsh network environments. Its average effective throughput is far higher than that of the DTLS 1.2 scheme. This is because the data-driven state synchronization mechanism of this invention can efficiently handle packet loss and out-of-order delivery, avoiding the long handshake timeouts and session interruptions caused by the loss of control messages in DTLS. Specifically, in terms of recovery time after sudden packet loss, the method of this invention only requires about one RTT to recover via the NACK mechanism, while DTLS may require several seconds of timeout before triggering retransmission or renegotiation, resulting in a significant decrease in transmission efficiency. Although the block-by-block key update of this invention results in a slightly higher CPU utilization than DTLS, the resulting improvement in network robustness and transmission efficiency is substantial. Most importantly, key synchronization of this invention never fails during the entire transmission process, while DTLS 1.2 experiences 17 synchronization failures due to the loss of handshake messages, requiring costly session reconnections.

[0054] In summary, the technical solution provided by this invention constructs a self-synchronizing cryptographic state evolution system by atomically binding the lifecycle of the key to the processing flow of data blocks. This system completely eliminates the dependence on external key update negotiation signaling, fundamentally solving the key state synchronization problem caused by signaling loss in unreliable networks, a problem inherent in traditional schemes. Regardless of the degree of packet loss or out-of-order delivery, as long as the data blocks eventually arrive, the cryptographic state machines of both communicating parties can deterministically and independently evolve to a consistent state, exhibiting extremely high robustness. Simultaneously, the block-by-block key update mechanism provides excellent security features such as forward secrecy and recovery after corruption. This method is particularly suitable for communication scenarios with unstable or unpredictable network conditions, such as tactical ad hoc networks, deep space communication, industrial IoT, and cross-border high-latency links, and has broad engineering application value.

[0055] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0056] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated units described above can be implemented in hardware or as software functional units. The above are merely embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made based on the description and drawings of this application, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

[0057] The specific embodiments of the invention have been described in detail above, but they are only examples, and this application is not limited to the specific embodiments described above. For those skilled in the art, any equivalent modifications or substitutions to the invention are also within the scope of this application. Therefore, all equivalent changes, modifications, and improvements made without departing from the spirit and principles of this application should be covered within the scope of this application.

Claims

1. A widely applicable method for encrypted data transmission in communication networks, applied between a sending end and a receiving end, characterized in that, The method achieves implicit, block-by-block synchronization of the cryptographic states of the communicating parties by constructing a deterministic cryptographic state machine driven by the data stream itself, specifically including: S1, Session initialization: The sending end and the receiving end negotiate and establish an initial encryption key, an initial decryption key that is the same as the initial encryption key, and a key update rule for subsequent key evolution; S2, At the sending end, for each data block D_i carrying a unique sequence number i, the sending end encrypts the data block D_i using the current encryption key K_i in its cryptographic state context to generate an encrypted data block C_i. After the encryption operation is completed, the sending end immediately executes a deterministic key update function F_update according to the key update rule. The input of the key update function includes at least the current encryption key K_i and the generated encrypted data block C_i to calculate the next encryption key K_{i+1} used to encrypt the next data block and update its cryptographic state context. S3, Decryption at the receiving end: The receiving end obtains the corresponding encrypted data block C_j from the received data according to the sequence number j it expects to receive, and decrypts the encrypted data block C_j using the current decryption key K_j in its cryptographic state context. When decryption is successful, the receiving end executes the deterministic key update function F_update according to the same key update rule as the sending end. The input of the key update function includes at least the current decryption key K_j and the successfully decrypted encrypted data block C_j, so as to calculate the next decryption key K_{j+1} for decrypting the next data block, and update its cryptographic state context to ensure that the evolution of the receiving end's key state is strictly synchronized with the processing progress of the data stream.

2. The widely applicable encrypted data transmission method for communication networks according to claim 1, characterized in that, S1 includes: The sender and receiver exchange messages by exchanging key parameters. They use the ECDH protocol, a variant of the Diffie-Hellman key exchange, to generate a temporary elliptic curve public-private key pair and calculate the shared initial secret by exchanging the public key portion. The sending end and the receiving end each input the shared initial secret into a key derivation function (KDF) to derive the initial encryption key and the initial decryption key from the initial secret; The cryptographic state context of the sending end and the receiving end also each contains an initial key state variable, which is also derived from the initial secret by the key derivation function KDF.

3. The widely applicable encrypted data transmission method for communication networks according to claim 2, characterized in that, Before the sending and receiving ends calculate the shared initial secret using the ECDH protocol, step S1 also integrates enhanced two-way authentication, including: S11, the sending end and the receiving end exchange their respective X.509 digital certificates issued by a trusted Certificate Authority (CA); S12, after receiving the other party's digital certificate, each party uses the pre-set CA public key to verify the certificate signature and checks the certificate's validity period and issuer information. S13. After the certificate verification is successful, both parties execute the challenge-response mechanism, in which one party sends a challenge value generated by a cryptographically secure pseudo-random number generator to the other party, and the other party uses the private key corresponding to its digital certificate to sign the challenge value through the Elliptic Curve Digital Signature Algorithm ECDSA, and returns the generated digital signature to the initiator for verification. S14, after both parties have successfully verified each other's digital certificates and signed the challenge value, they continue with the subsequent exchange of key parameters.

4. The widely applicable encrypted data transmission method for communication networks according to claim 1, characterized in that, In S2, the encryption operation uses an algorithm with associated data authentication encryption AEAD feature; The input to the AEAD algorithm includes the current encryption key K_i, the plaintext of the data block D_i, and a random number Nonce generated based on the sequence number i of the data block, which is unique in each encryption. The AEAD algorithm also processes the sequence number i of the data block itself as associated data; The output of the AEAD algorithm also includes an authentication tag Tag_i, which simultaneously guarantees the confidentiality and integrity of the encrypted data block C_i and the integrity of the sequence number i. In the decryption step at the receiving end, the receiving end uses the same AEAD algorithm, whose inputs include the current decryption key K_j, the encrypted data block C_j, the authentication tag Tag_j, the corresponding random number calculated based on the sequence number j, and the sequence number j as associated data. The condition for successful decryption is that the authentication tag Tag_j passes verification.

5. The widely applicable encrypted data transmission method for communication networks according to claim 4, characterized in that, In addition to the current encryption key K_i, the cryptographic state context of the sending end also includes a current key state variable S_i; The input to the deterministic key update function F_update is the current encryption key K_i, the current key state variable S_i, and the generated encrypted data block C_i; The output of the key update function F_update is the next encryption key K_{i+1} and the next key state variable S_{i+1}. The sending end uses this output to update its cryptographic state context. The cryptographic state context of the receiving end also includes the current key state variable S_j. The key update function F_update executed by it takes the current decryption key K_j, the current key state variable S_j, and the successfully decrypted encrypted data block C_j as input, and outputs the next decryption key K_{j+1} and the next key state variable S_{j+1}.

6. The widely applicable encrypted data transmission method for communication networks according to claim 5, characterized in that, The deterministic key update function F_update is implemented using the HMAC-based extract-expand key derivation function HKDF, and the specific steps include: S21, extract HKDF, use the current key state variable S_i or S_j as a random value, and use the current encryption key K_i or the current decryption key K_j as the input key material IKM to generate a pseudo-random key PRK; S22, Extend HKDF, using the pseudo-random key PRK as input, and concatenating the encrypted data block C_i or C_j with a predefined string that identifies the key update context as input, and extend to generate an output key material OKM of a predetermined length; S23, the next encryption key K_{i+1} or K_{j+1} and the next key state variable S_{i+1} or S_{j+1} are separated from the output key material OKM.

7. The widely applicable encrypted data transmission method for communication networks according to claim 1, characterized in that, S2 also includes: The sending end determines the data block size based on the maximum transmission unit of the current communication network path. The data block size is set to the maximum transmission unit of the path minus the header overhead of each layer of the network protocol stack and the transmission header overhead introduced by this method. When dividing the data to be transmitted into multiple data blocks, if the length of the last data block is less than the determined data block size, then a deterministic padding process is performed on the last data block.

8. The widely applicable encrypted data transmission method for communication networks according to claim 4, characterized in that, In S2, the sending end encapsulates each encrypted data unit into a data packet for transmission. The data packet consists of a header and a payload. The payload includes the encrypted data block C_i and its corresponding authentication tag Tag_i; The header contains key information for synchronization, including a sequence number i, a payload length field indicating the length of the payload portion, and a header checksum for verifying header integrity.

9. A widely applicable method for encrypted data transmission in communication networks according to claim 1, characterized in that, The method also includes a data block loss handling mechanism based on negative acknowledgment (NACK), specifically including: At the receiving end, if the data packet corresponding to its expected sequence number j is not received within the predetermined time, or if a large gap is detected in the sequence number of the data packet stored in its receiving buffer, the receiving end sends a retransmission request message to the sending end through the control channel. The message clearly indicates one or more sequence number ranges that need to be retransmitted. After receiving the retransmission request, the sending end searches for and retrieves the generated and stored encrypted data block C_i and authentication tag Tag_i with the corresponding sequence number from its historical transmission records, and retransmits them to the receiving end without having to re-encrypt the original data block.

10. A widely applicable method for encrypted data transmission in communication networks according to claim 1, characterized in that, The key update rule is dynamically adjustable, and the method further includes: The sending and receiving ends jointly maintain the key update frequency parameter N, with an initial value of 1, indicating that a key update is performed once for each data block; The sending and receiving ends assess the current network condition by continuously monitoring network transmission quality parameters, including round-trip time and packet loss rate. When the network quality is detected to meet the preset good conditions, the sending end initiates negotiation with the receiving end to adjust the key update frequency parameter N to an integer value greater than 1. After reaching an agreement, both parties synchronously change to execute the key update function F_update once every N data blocks processed. When network quality deterioration is detected, both parties negotiate to adjust the key update frequency parameter N back to 1 to achieve an adaptive balance between security and performance.

Images