Data information security encryption method and system based on hash function

Abstract

The invention provides a data information security encryption method and system based on a hash function, and belongs to the technical field of data encryption, and the method specifically comprises the following steps: on the basis of encryption optimization server data, combining with delay influence conditions of different servers in an encryption optimization time period; the method comprises the following steps: determining an update identification processing strategy of a potential optimization target of an encryption optimization server, determining the potential optimization target based on the update identification processing strategy, and determining an update management method of the potential optimization target on the basis of association degrees of the potential optimization target and the encryption optimization server in different interaction periods. And the management and control reliability of data security is improved.

Description

A Data Encryption Method and System Based on Hash Functions Technical Field

[0001] This invention belongs to the field of data encryption technology, and in particular relates to a data information security encryption method and system based on hash functions. Background Technology

[0002] Hash functions are core cryptographic primitives for ensuring data integrity, authenticity, and non-repudiation. Traditional cryptographic hash functions (such as MD5 and SHA-1 series) use fixed initialization vectors (IVs) and constant parameters. However, these static structures expose potential security risks when faced with increasingly powerful cryptanalysis techniques (such as collision attacks and differential attacks).

[0003] Chaotic systems, due to their extreme sensitivity to initial conditions and parameters, ergodicity, pseudo-randomness, and one-wayness, are naturally compatible with cryptographic principles. Existing technologies include schemes that directly use chaotic mappings to generate hash values ​​or construct S-Boxes; however, these schemes often suffer from the following drawbacks: Since the frequency of interactions varies across different time periods, applying a dynamic encryption method based on chaotic systems to all servers leads to more severe latency during periods with high interaction frequency and a large number of interacting servers, impacting the timeliness of server interactions. Therefore, dynamically updating and adjusting the encryption methods for different servers based on the interaction data and its correlation, thereby improving the efficiency and reliability of encryption processing while reducing the risk of data leakage, has become an urgent technical problem to be solved.

[0004] To address the aforementioned technical problems, this application provides a data information security encryption method and system based on hash functions. Summary of the Invention

[0005] To achieve the objectives of this invention, the following technical solution is adopted: Specifically, this application provides a data information security encryption method based on a hash function, specifically including: S1 using the request data of the target server to determine the interaction processing delay data of the target server in different time periods, and combining the interaction data between different servers and the target server in the time periods to determine the encryption optimization requirement period for data information based on the hash function; and determining the encryption optimization server among the servers based on the interaction period between the server and the target server, and the degree of overlap between the interaction period and the encryption optimization requirement period; S2 using the encryption optimization server data as a basis, and combining the delay impact of different servers in the encryption optimization period, determining the update identification and processing strategy for the potential optimization targets of the encryption optimization server; S3 determining the potential optimization targets based on the update identification and processing strategy, and determining the update management method for the potential optimization targets based on the degree of correlation between the potential optimization targets and the encryption optimization server in different interaction periods.

[0006] The beneficial effects of this invention are as follows: By analyzing the interaction processing latency data of the target server at different time periods and the interaction data between different servers and the target server, the encryption optimization requirement period for data information based on hash functions is determined. The invention filters out high-risk periods where the target server itself experiences high processing latency from a time perspective. It also analyzes the behavioral patterns of other servers interacting with the target server during these high-risk periods from a relational perspective. Finally, through a set of progressive judgment rules, the severity, concentration, and breadth of the latency impact are comprehensively assessed. Only when the latency problem simultaneously possesses a certain frequency of occurrence, depth of impact, and potential ripple effect is the period determined as an encryption optimization requirement period. This logic ensures the necessity and economy of the optimization action, achieving a balanced control of security risks and interaction latency.

[0007] Based on the degree of correlation between potential optimization targets and the encryption optimization server in different interaction periods, a method for updating and managing potential optimization targets is determined. This method avoids the technical problem of excessively high data leakage risks caused by a large number of servers using the same encryption method in the same period, based on the degree of overlap with the frequent interaction periods of existing optimization demand targets. It also performs targeted update processing of optimization demand servers, which not only reduces its own latency impact, but also reduces the latency severity in the target period. This provides a crucial dynamic governance logic for building a large-scale distributed security system with elasticity, scalability, and self-balancing capabilities.

[0008] Furthermore, the interaction processing delay data of the target server includes the interaction processing delay process of the target server and the delay duration of the interaction processing delay process.

[0009] Furthermore, the interaction data between the server and the target server includes the number of historical interaction processes between the server and the target server during the time period.

[0010] Furthermore, the method for determining the encryption optimization requirement period is as follows: using the interaction processing delay data of the target server during the period, determine the interaction processing delay process of the target server during the period; based on the interaction processing delay process data, determine the delay risk period in the period; based on the interaction data between different servers and the target server during the delay risk period, determine the historical interaction process between the server and the target server during the delay risk period; based on the historical interaction process between different servers and the target server during the delay risk period, determine whether the period belongs to the encryption optimization requirement period.

[0011] Furthermore, the method for determining the update management method of the potential optimization targets is as follows: based on the potential optimization target data, determine the number of potential optimization targets; based on the degree of correlation between the potential optimization targets and the encryption optimization server in different interaction periods, determine the overlap coefficient of the frequent interaction periods between the potential optimization targets and the encryption optimization server; based on the number of potential optimization targets, the overlap coefficient of the frequent interaction periods between the potential optimization targets and the encryption optimization server, and the frequent interaction periods, determine the update management method of the potential optimization targets.

[0012] In a second aspect, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the aforementioned data information security encryption method based on a hash function when running the computer program.

[0013] Other features and advantages will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention are realized and obtained through the structures particularly pointed out in the description and the drawings.

[0014] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0015] The above and other features and advantages of the present invention will become more apparent from a detailed description of exemplary embodiments thereof with reference to the accompanying drawings.

[0016] Figure 1 is a flowchart of a data information security encryption method based on a hash function; Figure 2 is a flowchart of a method for determining the encryption optimization requirement period; Figure 3 is a flowchart of a method for determining the encryption optimization server in the server. Detailed Implementation

[0017] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the embodiments set forth herein; rather, they are provided so that the invention will be thorough and complete, and the concept of the exemplary embodiments will be fully conveyed to those skilled in the art. The same reference numerals in the drawings denote the same or similar structures, and therefore their detailed description will be omitted.

[0018] The terms “a,” “one,” “the,” and “the” are used to indicate the existence of one or more elements / components / etc.; the terms “including” and “having” are used to indicate an open-ended meaning of inclusion and that other elements / components / etc. may exist in addition to the listed elements / components / etc.

[0019] Example 1: To address the above problems, according to one aspect of the present invention, as shown in FIG1, a data information security encryption method based on a hash function is provided, specifically including: S1: using request data from a target server, determining the interaction processing delay data of the target server in different time periods, and combining the interaction data between different servers and the target server in the time periods to determine the encryption optimization requirement period for data information based on a hash function; determining the encryption optimization server among the servers based on the interaction period between the server and the target server, and the degree of overlap between the interaction period and the encryption optimization requirement period; S2: based on the data of the encryption optimization server, and combining the delay impact of different servers in the encryption optimization period, determining the update identification and processing strategy for the potential optimization targets of the encryption optimization server; S3: determining the potential optimization targets based on the update identification and processing strategy, and determining the update management method for the potential optimization targets based on the degree of correlation between the potential optimization targets and the encryption optimization server in different interaction periods.

[0020] Furthermore, the interaction processing delay data of the target server includes the interaction processing delay process of the target server and the delay duration of the interaction processing delay process.

[0021] Furthermore, the interaction data between the server and the target server includes the number of historical interaction processes between the server and the target server during the time period.

[0022] Specifically, as shown in Figure 2, the method for determining the encryption optimization requirement period is as follows: In this embodiment, to accurately identify and limit the specific time window for initiating a specific encryption optimization strategy, the core logic lies in constructing a coarse-to-fine, multi-level linkage decision funnel. First, the risk period with high latency for the target server itself is screened from the time dimension. Second, the behavior patterns of other servers interacting with the target server during this risk period are analyzed from the perspective of correlation. Finally, through a set of progressive judgment rules, the severity, concentration, and breadth of the latency impact are comprehensively assessed. Only when the latency problem simultaneously possesses a certain frequency of occurrence, depth of impact, and potential scope of influence is the period determined as the encryption optimization requirement period. This logic ensures the necessity and economy of the optimization action, achieving a balanced control of security risks and interaction latency.

[0023] S21 uses the interaction processing delay data of the target server during the time period to determine the interaction processing delay process of the target server during the time period, and determines the delay risk period in the time period based on the interaction processing delay process data; the interaction processing delay process refers to a single event in which the time interval between the target server receiving a complete interaction request and starting its core processing logic or issuing a response is abnormally extended, and its duration is the delay duration. The delay risk period refers to the time interval calculated based on historical statistical data where the average daily number of interaction processing delay processes exceeds a certain preset threshold.

[0024] Server performance fluctuations can be time-dependent, making continuous monitoring and analysis prohibitively expensive. This step aims to pinpoint the problem and concentrate subsequent complex analytical resources on the time period when it is most likely to manifest, representing a data preprocessing strategy to improve overall analytical efficiency.

[0025] S22 determines the historical interaction process between the server and the target server during the latency risk period based on the interaction data between different servers during the latency risk period. In this context, "server" specifically refers to any other independent computing node that has a network-level connection with the target server and may exchange data. The historical interaction process refers to a record of a complete transaction link initiated and completed between any server and the target server within the identified latency risk period; its quantity reflects the frequency of interaction.

[0026] Understanding "who" communicates with the target server during the risk period is the first step in assessing the scope of latency impact. Knowing only that the target server itself has latency is insufficient; it is essential to identify potentially affected stakeholders. This expands the analytical perspective from individual servers to the entire server interaction network, providing crucial data input for assessing the ripple effect of latency and serving as a bridge between "internal latency" and "external impact."

[0027] S23 determines whether the time period belongs to the encryption optimization requirement period based on the historical interaction process between different servers and the target server during the latency risk period.

[0028] It should be noted that the delay risk period is the period in which the average daily number of interactive processing delay processes exceeds a preset threshold for the number of delay processes.

[0029] Specifically, based on the historical interaction processes between different servers and the target server during the latency risk period, it is determined whether the period belongs to the encryption optimization requirement period. This includes: S231, using the historical interaction processes between different servers and the target server during the latency risk period, identifying servers whose daily average number of historical interaction processes exceeds a preset threshold, and using these servers as matching servers. It is then determined whether the number of matching servers exceeds a preset matching server number threshold. If yes, the period is determined to belong to the encryption optimization requirement period; otherwise, proceed to step S232. A matching server refers to a server whose daily average number of historical interaction processes with the target server exceeds a preset high-frequency threshold during the latency risk period. This threshold is used to distinguish between high-frequency interaction partners and low-frequency, occasional interaction partners. The preset matching server number threshold is a benchmark value used to determine the cluster size of high-frequency interaction partners.

[0030] Servers with high-frequency interactions are most sensitive to the performance and stability of the target server, and their business flows are more likely to be continuously affected by latency. If there are a large number of such servers, it means that the latency problem is directly impacting the core business chain, and the situation is serious, providing sufficient reason to immediately trigger optimization and establish the first and most stringent judgment checkpoint. It prioritizes handling situations with concentrated and severe impacts, enabling rapid decision-making, and is suitable for scenarios where latency problems have already significantly affected the core interaction groups.

[0031] S232 determines whether a matching server exists within the specified time period. If yes, proceed to step S233; otherwise, determine that the specified time period does not belong to the encryption optimization requirement period. If no matching server with high-frequency interactions exists, it indicates that during the risky period, although the target server itself experiences numerous latency events, the interactions with it are all low-frequency or sporadic. In this case, the impact of latency may be scattered and limited, significantly reducing the necessity to immediately initiate high-strength encryption optimization, thus serving as an effective filter. When the most severe "high-frequency concentrated impact" condition is not met, this step determines whether further in-depth analysis is necessary. If no matching server exists, gracefully exit early to save computing resources.

[0032] S233 identifies servers that interacted with the target server during the latency risk period on different dates, and classifies them as interacting servers. It then determines whether the average number of interacting servers on different dates exceeds a preset server number threshold. If so, the time period is determined to be within the encryption optimization requirement period; otherwise, proceed to step S234. "Interacting server" is a broader definition than "matching server," referring to all servers that, within the statistical period, have had at least one historical interaction with the target server during the latency risk period, regardless of their interaction frequency. The preset server number threshold is a benchmark value used to measure the overall number of servers that interacted with the target server during the risk period.

[0033] During certain periods, there may not be any particularly prominent high-frequency interaction partners (few matching servers), but there may be a large number of low-frequency interaction requests of different types. This "wide and scattered" interaction pattern means that the period is a busy time for a common interface of the server. Once a delay occurs, the impact will be very wide, potentially involving many different business lines or downstream systems, and thus carries a high risk.

[0034] S234 takes the date when the average number of interactive servers is greater than the preset server number threshold as the affected date, determines the delay impact coefficient of the time period based on the proportion of the affected dates and the number of matching servers, and determines whether the delay impact coefficient is greater than the preset impact coefficient threshold. If it is, the time period is determined to be a time period with encryption optimization requirements; otherwise, the time period is determined not to be a time period with encryption optimization requirements.

[0035] The affected dates refer to those specific dates within the historical statistical period where the number of interacting servers exceeded the preset breadth threshold (i.e., the threshold used in S233). The latency impact coefficient is a comprehensive quantitative evaluation indicator that takes into account both the frequency of the "breadth of impact" (the proportion of affected dates) and the potential basis of the "depth of impact" (the number of matching servers).

[0036] When the aforementioned direct and explicit judgment conditions (high-frequency concentration, widespread diffusion) are not met, a more refined and compromise-based assessment scheme is needed. A high percentage of impact dates indicates that while the "widespread impact" does not occur daily, it appears periodically or frequently; the existence of a matching server implies the presence of stable core interacting parties. Combining these two factors can identify complex problem periods with intermittent widespread impact risks and core victims, providing a final and refined decision-making process. It uses a mathematical model to integrate multiple dimensions of risk factors into a comparable scalar, capturing complex and atypical risk patterns and ensuring the comprehensiveness and scientific rigor of the decision-making system.

[0037] In this embodiment, the target server is an encrypted forwarding server. The time period to be analyzed is from 19:00 to 21:00 every day (denoted as time period P), which is the peak period. The historical data collection period is the most recent 30 calendar days.

[0038] Execute S21: Count the number of interaction processing delays that occur daily on the target server within time period P. Statistical data from the past 30 days shows a minimum of 8 and a maximum of 20 delays, resulting in a daily average of 12.5 delays. The system's preset threshold for the number of delays is 9 per day. Since 12.5 > 9, time period P is identified as a high-risk delay period.

[0039] Execution S22: Analyze all other servers that interacted with the target server in the past 30 days during the risk period P. The interactions were found to primarily involve 12 lower-level edge cache servers (EC1-EC12) and 8 user session management servers (SM1-SM8). The system recorded the number of historical interactions between these 20 servers during period P.

[0040] Execute S23: Perform a hierarchy determination based on the above interaction data.

[0041] Execute S231: Set the threshold for high-frequency interactions (preset process number threshold) to an average of 15 times per day. Calculations show that among the 20 servers, only three lower-level edge cache servers (EC3, EC5, and EC7) have average daily interactions with the target server of 18, 22, and 16 times respectively, exceeding this threshold. Therefore, the matching servers are EC3, EC5, and EC7, totaling 3. The system's preset threshold for the number of matching servers is 4. Since 3 < 4, the direct judgment condition is not met, and the process proceeds to S232.

[0042] Execute S232: Determine if a matching server exists. Since there are three matching servers (EC3, EC5, and EC7), the process continues to S233.

[0043] Execute S233: Count the number of servers that actually interacted with the target server each day within time period P. Over 30 days, this number fluctuated between 15 and 28 servers daily, resulting in an average of 21 interacting servers per day. The system's preset threshold for the number of servers used to measure the breadth of interaction is 25. Since 21 < 25, the direct judgment condition for this level is not met, and the process proceeds to the final step, S234.

[0044] Execute S234: Identify Impact Dates: Mark dates when the number of daily interactive servers exceeds the widespread threshold (25 servers) as impact dates. Upon verification, this condition was met for 9 out of 30 days.

[0045] Calculate the percentage of affected dates: 9 / 30 = 0.3. Obtain the number of matching servers: as mentioned before, it is 3. Calculate the delay impact coefficient: this embodiment uses a product model, that is, delay impact coefficient = percentage of affected dates × number of matching servers. Substituting the data, we get: 0.3 × 3 = 0.9.

[0046] The system's preset impact coefficient threshold is 0.6. Since 0.9 > 0.6, it is ultimately determined that time period P (19:00 to 21:00 daily) falls within the encryption optimization requirement period. Therefore, it is necessary to adjust the encryption method, i.e., not uniformly using a hash function based on dynamic encryption, but using a hash function based on static encryption for some servers.

[0047] The encryption process employs a statically encrypted hash function, specifically involving: static encryption using fixed chaotic parameters to generate a pseudo-random key stream, which is then XORed bit-by-bit with the plaintext to achieve encryption. The key stream is iteratively generated through a chaotic system, exhibiting quasi-randomness and unpredictability.

[0048] Key and parameter initialization: Input key K (length 128 / 256 bits) and initial vector IV; set chaotic mapping parameters α, β0; generate initial chaotic state X0=ChaosInit(K,IV).

[0049] Keystream generation: Iterative generation of pseudo-random sequences using chaotic maps.

[0050] Xi is quantized into a binary key stream KSi.

[0051] Encryption process: Divide the plaintext MM into blocks of the same length as the key stream; perform XOR encryption on each block:

[0052] Decryption process: Regenerate the keystream using the same key and initial parameters; perform an XOR operation on the ciphertext:

[0053] Example: Static encryption based on Logistic chaotic mapping: chaotic mapping xn+1=μxn(1-xn), where μ∈[3.57,4]; key stream generation: take the last 8 bits of the binary representation of xn as the key byte; supports stream encryption mode, suitable for real-time communication encryption.

[0054] The encryption process employs a hash function based on dynamic encryption, specifically by introducing dynamically changing chaotic parameters into the encryption process. This ensures that each round of the encryption algorithm depends on the plaintext or ciphertext of the previous round, thereby enhancing the algorithm's diffusion and resistance to attacks.

[0055] Implementation steps: Parameter initialization: Set the initial chaotic parameters R0=(a0,β0,s0); set the group length to 128 or 256 bits.

[0056] Dynamic parameter update mechanism: After encrypting each data block, update the chaotic parameters according to the current ciphertext or intermediate state: Ri+1=ChaosUpdate(Ri,Ci); Block encryption process: For each plaintext block Pi: use the current parameter Ri to generate a chaotic S-Box or permutation table; perform multiple rounds of confusion and diffusion operations, including: byte substitution (based on chaotic S-Box), row shifting, column confusion, round key addition (using the subkey generated by chaos), and output ciphertext block Ci.

[0057] Decryption process: The encryption operation is performed in reverse, and the same parameter update mechanism is used to generate the S-Box and subkey required for decryption.

[0058] Example: Block encryption based on chaotic dynamic S-Box; each round uses chaotic mapping to generate a different 16×16 S-Box; the round key is dynamically generated by the chaotic sequence; supports block encryption modes such as ECB, CBC, and CTR.

[0059] This method provides a systematic, data-driven, and fine-grained solution for identifying encryption optimization needs during specific time periods. Its primary value lies in achieving precise allocation of security resources. By strictly limiting high-strength encryption optimization to high-risk periods verified through multi-dimensional analysis, it effectively avoids the global performance degradation and increased response latency caused by heavy-load encryption mechanisms such as 24 / 7 activation of dynamic hash functions. Secondly, the multi-level progressive judgment logic employed by the method exhibits high robustness and adaptability. It not only focuses on the latency phenomenon itself but also deeply analyzes the impact patterns (including depth, breadth, and frequency) of latency on the server's associated network. This allows decisions to cover various complex scenarios, from severe impact on core links to intermittent widespread effects, significantly improving the comprehensiveness and accuracy of risk identification. Finally, the method's automation provides core decision support for intelligent operation and maintenance and dynamic scheduling of security policies in large-scale distributed systems or cloud environments. This helps maintain overall service level agreements and optimize resource utilization while ensuring data transmission security, demonstrating significant practical application value.

[0060] Furthermore, as shown in Figure 3, the method for determining the encryption optimization servers in the server configuration is as follows: In this embodiment, from all servers that interact with the target server, those servers that should be prioritized for encryption optimization configuration are identified, i.e., "encryption optimization servers". The core logic lies in constructing a multi-level, multi-dimensional screening funnel: First, quickly identify core partners that maintain high-frequency interaction with the target server during the encryption optimization demand period; second, for servers whose interaction frequency does not reach the highest standard, analyze the overlap and consistency of their historical interaction behavior with the demand period in the time dimension to determine the regularity and severity of their impact; finally, through comprehensive calculation, quantified evaluation values ​​are obtained to accurately rank and determine the necessity of server optimization. This logic ensures that the screening results are both focused and comprehensive.

[0061] S31, based on the interaction data between the server and the target server, determines the time period during which the server belongs to the matching server within the encryption optimization requirement period, and designates this as the matching requirement period. The matching requirement period refers to the time period during which a specific server was identified as a "matching server" in previous processes. This period must be a subset of the "encryption optimization requirement period." If a server has never been a "matching server" in any "encryption optimization requirement period," then no matching requirement period exists for it.

[0062] This is the most direct and stringent screening criterion. The definition of a "matching server" means that this server maintains high-frequency interaction with the target server during the problem period, and is the object most directly and severely affected by latency. Prioritizing this attribute allows for rapid identification of the core optimization target, establishing the first rapid screening hurdle. This distinguishes those clearly high-frequency interacting core servers from other servers and provides crucial input (matching demand period data) for subsequent steps.

[0063] Example: Suppose the target server has been identified as requiring encryption optimization between 8:00 PM and 9:00 PM daily. Server A has an extremely high daily interaction frequency with the target server during this period, and therefore was marked as a "matching server" for this period in the previous assessment. Thus, for server A, 8:00 PM to 9:00 PM is its "matching demand period." Although server B also interacts with the target server during this period, the frequency is low and does not meet the "matching server" standard. Therefore, server B does not have a matching demand period and is initially excluded in this step.

[0064] It should be noted that if the server does not have a matching demand period in the above steps, then the server is determined not to be an encryption optimization server.

[0065] Furthermore, if the server has matching demand periods, the number of matching demand periods is obtained, and it is determined whether the proportion of the matching demand periods in the encryption optimization demand periods is greater than a preset demand period proportion threshold. If so, the server is determined to be an encryption optimization server; otherwise, proceed to step S32. The proportion of matching demand periods in the encryption optimization demand periods refers to the proportion of the cumulative duration (or the number of periods covered) of all matching demand periods of a single server to the total duration of all encryption optimization demand periods. The preset demand period proportion threshold is a benchmark value used to measure the degree of association between the server and the encryption optimization demand periods.

[0066] A server might only be a high-frequency interactor during certain periods of encryption optimization demand. If its matching demand period accounts for a high proportion of all demand periods, it indicates that it is a core affected party in almost all problem periods, and optimizing it naturally has a very high priority. Servers with matching demand periods should be classified by importance. A high proportion means that the server is a consistently core associated party and can be directly identified as an optimization target.

[0067] Example: Continuing the previous example, suppose three different periods of encryption optimization demand are identified. Server A is a matching server in two of these periods (i.e., it has two periods of matching demand). Therefore, its matching demand period ratio is 2 / 3. If the preset threshold is set to 60%, then 2 / 3 ≈ 66.7% > 60%, and server A is directly identified as an encryption optimization server.

[0068] S32 determines the interaction periods between the server and the target server on different dates based on the interaction periods between the server and the target server. It then determines the overlap ratio on different dates based on the degree of overlap between the interaction periods on different dates and the encryption optimization requirement period. The interaction period refers to the specific time range within which the server and the target server actually conduct historical interactions. The overlap ratio refers to the percentage of the encryption optimization requirement period that overlaps with the server's actual interaction period within a single date. Overlapping dates refer to those dates whose overlap ratio is greater than a preset overlap ratio threshold.

[0069] For servers that cannot be directly identified based on high frequency and high percentage, a more detailed analysis is needed. Examining the overlap between their historical daily interaction behavior and the problem periods can determine whether the impact is accidental or regular. Even if the daily average interaction frequency is not the highest, if its business routinely runs during the problem periods, then the certainty of its being affected by latency is still high. A deep screening based on the dimension of "consistency of time behavior" can help identify servers that, while not interacting frequently at every moment, have business cycles highly synchronized with the problem periods, thus avoiding overlooking regularly affected servers.

[0070] Example: Server C is not a high-frequency matching server. However, analysis of its logs over the past 7 days reveals a significant overlap between its daily active business periods and encryption optimization demand periods. The daily overlap ratio is calculated. For example, if Monday runs for a total of 3 time slots, and one of these slots overlaps with the encryption optimization demand period, the overlap ratio is 0.33. If this overlap ratio is greater than a preset threshold, then Monday meets the condition. If this condition is met for 5 out of 7 days, these days are considered "overlapping dates".

[0071] The above steps specifically include the following: S321 Determine whether there are dates with an overlap ratio greater than a preset overlap ratio threshold based on the overlap ratio among different dates. If yes, proceed to step S322; otherwise, determine that the server does not belong to the encryption optimization server. S322 Take the dates with an overlap ratio greater than the preset overlap ratio threshold as the overlapping dates, and determine whether the proportion of the overlapping dates among the dates is greater than a preset date proportion threshold. If yes, determine that the server belongs to the encryption optimization server; otherwise, proceed to step S33.

[0072] After identifying the overlapping dates, it's necessary to determine whether this overlap is widespread. If the overlap only occurs on a few days, it might be accidental; if it occurs on most observed dates, it indicates that the server's business model is indeed closely tied to the encryption optimization requirements, adding a frequency dimension to the date overlap analysis. Ensure that the selected servers are regularly affected parties with stable behavioral patterns, rather than occasional interaction targets.

[0073] S33 determines whether the server is an encryption optimization server based on the overlap ratio of the servers on different dates and the matching demand time period data.

[0074] It is understood that in the above steps, the average proportion of the servers is determined based on the average of the overlap ratio of the servers on different dates and the average of the proportion of the matching demand period in the encryption optimization demand period. When the average proportion is greater than the preset threshold, the server is determined to be an encryption optimization server.

[0075] The ratio mean is a comprehensive quantitative indicator, typically calculated using a weighted or arithmetic average of two dimensions: "the average of the overlap ratio of servers on different dates" and "the average of the ratio of matching demand periods to encryption optimization demand periods." A preset threshold for the ratio serves as the final benchmark for judging this comprehensive indicator.

[0076] This is the final and most comprehensive adjudication step. It applies to servers that do not directly meet the standards in either of the two single-dimensional proportional judgments (after S31 and after S322). They may have high overlap on some days, but not every day; or they may have a small number of matching demand periods, but the proportion is not high. By calculating a comprehensive score that combines "frequency" (proportion of matching demand periods) and "consistency" (average date overlap ratio), the overall impact can be assessed more fairly, providing a final, refined screening mechanism to prevent misjudgment of servers that perform reasonably well in both dimensions and whose overall impact is still significant due to the failure to meet a single condition, making the screening system more complete and scientific.

[0077] In one specific embodiment, the implementation process of this method is fully described by way of a patented embodiment. This embodiment follows the aforementioned embodiment of the "method for determining encryption optimization demand period", wherein the core data server (target server) has been determined to have a fixed encryption optimization demand period from 01:00 to 02:00 daily. Now, it is necessary to determine the specific encryption optimization server from among the many servers that interact with the target server.

[0078] Assume the server to be evaluated is the business server SX. The historical data period is the most recent 10 working days.

[0079] Step S31: Check whether server SX was marked as a "matching server" during the encryption optimization demand period (01:00-02:00). Historical records show that on two out of 10 days (day 3 and day 8), server SX's interaction frequency with the target server exceeded the high-frequency interaction threshold during this period. Therefore, it was a matching server on those two days. Thus, server SX has two matching demand periods. Calculate the proportion of matching demand periods in the total demand periods: 2 days / 10 days = 20%. The preset demand period proportion threshold is 50%. Since 20% < 50%, the direct judgment condition is not met, proceed to step S32.

[0080] Execution S32: Analyze the actual interaction time periods between server SX and the target server on 10 different dates. It was found that server SX interacted between 01:00 and 02:00. The actual interaction time periods each day included two time periods that included the above-mentioned encryption optimization requirements.

[0081] Calculate the overlap ratio between the actual daily interaction time period and the fixed encryption optimization requirement time period (01:00-02:00). For example, if there are two interaction time periods on a certain day, the overlap with 01:00-02:00 is 01:00-02:00, and the overlap ratio is 0.5.

[0082] Execute S321: The preset overlap ratio threshold is 40%. Check the dates within a 10-day period where the overlap ratio is greater than 40%. Calculations show that 3 days (days 2, 5, and 9) have overlap ratios of 50%, 50%, and 50% respectively, exceeding the threshold.

[0083] Execute S322: Mark these 3 days as "overlapping dates". Calculate the proportion of overlapping dates in the total number of dates: 3 days / 10 days = 30%. The preset date proportion threshold is 40%. Since 30% < 40%, this judgment condition is not met, proceed to step S33.

[0084] Execute S33: Perform a comprehensive judgment. Calculate the average value of the "matching demand period ratio": this value has been previously obtained as 20% (or 0.2). Calculate the average value of the "overlap ratio of different dates": add up the overlap ratios of each day for 10 days and then average them. Assume the calculation result is 0.4% (or 0.4). Calculate the average ratio: in this embodiment, the arithmetic mean is used, that is, (0.2 + 0.4) / 2 = 0.3.

[0085] The preset percentage threshold is 0.3 = (20%). Since 0.3 > 0.2, it is finally determined that server SX belongs to the encryption optimization server category.

[0086] This method provides a refined, multi-layered mechanism for identifying encrypted optimization servers, possessing significant practical value. Its core value lies in the precise targeting of optimization objectives. Through a progressive screening logic, it identifies servers that truly require encryption configuration adjustments, progressing from "high-frequency cores" to "regular correlations" and then to "comprehensive impacts." This ensures that optimization measures are precisely applied to key bottlenecks, avoiding the resource waste and potential risks associated with a "one-size-fits-all" approach. Secondly, by introducing overlap and consistency analysis over time, this method effectively identifies servers whose behavioral patterns coincide with problem periods and are definitively affected by systemic latency, enhancing the depth and breadth of risk identification. Finally, implementing this method significantly improves the overall return on investment for encryption optimization strategies. While ensuring system communication security, it optimizes operational costs and system performance, providing crucial technical decision support for building intelligent, adaptive large-scale distributed system security architectures.

[0087] Furthermore, the impact of server latency is determined based on the proportion of the number of historical interaction processes during the encryption optimization requirement period to the total number of historical interaction processes across all interaction periods.

[0088] Furthermore, the method for determining the update identification and processing strategy for potential optimization targets of the encryption optimization server is as follows: In this embodiment, it is determined whether the existing encryption optimization server list needs to be expanded, and the corresponding target identification and update strategy is determined. Its core logic is a hierarchical evaluation and dynamic adjudication process. First, the overall coverage ratio of the existing list to active interactive servers during the encryption optimization demand period is evaluated. If the coverage is sufficient, the status quo is maintained; if the coverage is insufficient, further analysis is conducted to determine whether there are individual servers whose business activities are highly concentrated in that period and are significantly affected by latency. Finally, combining the "prevalence of insufficient coverage" and the "scale of new risk targets," a comprehensive adjudication is made through a dynamically adjusted threshold to determine whether to trigger an update and which update strategy to select. This logic ensures that the update decision is both efficient and accurate, capable of quickly responding to significant coverage failures while prudently handling complex edge cases.

[0089] Based on the encryption optimization server data, S41 determines the percentage of encryption optimization servers among servers that have data interaction during the encryption optimization period on different dates, and uses this percentage as the encryption optimization percentage. The encryption optimization percentage refers to the proportion of servers marked as "encryption optimization servers" among all servers that have data interaction with the target server during the encryption optimization demand period on a single date. This indicator is used to measure the breadth of coverage of the current optimization target set to the active interactive entities on that day. Coverage deviation dates refer to dates where the encryption optimization percentage is not greater than a preset encryption optimization percentage threshold.

[0090] This step serves as the first rapid check of overall performance. Its setup is based on the fundamental principle that an effective set of optimized servers should represent the main interactive traffic during the problem period. By calculating the average percentage of encrypted optimizations over multiple days and comparing it to a threshold, it efficiently determines whether the current list still possesses broad representativeness, thus avoiding unnecessary deep analysis while the list remains valid, building an efficient preliminary filtering mechanism. It uses macro-statistical indicators for stability screening, quickly drawing conclusions when the system is in good condition, and only triggering subsequent fine-grained analysis when clear signs of insufficient coverage appear, optimizing the efficiency of the overall decision-making process.

[0091] The above steps include the following: Case 1: If the average value of the encryption optimization percentage on different dates is greater than the preset encryption optimization percentage threshold, then it is determined that the encryption optimization server does not need to be updated.

[0092] When the average percentage of encryption optimizations across different dates consistently exceeds a preset threshold, it indicates that the existing list stably covers most of the interactive activities during the problematic period within the statistical period. This means that the current optimization target set can effectively manage the main latency impacts, and the system is in a stable state. At this point, updating operations have low marginal benefits and may introduce unnecessary configuration complexity. Therefore, it is crucial to confirm and maintain the stable and effective state of the system, ensure the continuity of the strategy, and prevent unnecessary operations that could cause fluctuations.

[0093] Case 2: If the average encryption optimization percentage of different dates is not greater than the preset encryption optimization percentage threshold, obtain the dates whose encryption optimization percentage is not greater than the preset encryption optimization percentage threshold and use them as coverage deviation dates. Determine whether the percentage of the number of coverage deviation dates is greater than the preset coverage deviation date percentage threshold. If yes, determine that the update identification and processing strategy for the potential optimization target of the encryption optimization server is the preset update identification strategy. If not, proceed to step S42.

[0094] When average coverage is insufficient, it indicates a potential systemic weakness in the current list. This step concretizes the macro-level problem by identifying all non-compliant dates. By calculating the percentage of these dates out of the total observed dates, the frequency of coverage inadequacy can be quantified, distinguishing between occasional fluctuations and systemic issues. This allows for a quantified classification of the severity of coverage failure, providing crucial guidance for subsequent decision-making. A high percentage signifies a serious problem and may directly recommend updating the standards; a low percentage requires further investigation to identify new high-impact individuals.

[0095] S42 determines the number of historical interaction processes of a server during different dates within the encryption optimization period, and its proportion among all historical interaction periods, based on the latency impact of different servers during the encryption optimization period. This proportion is used as the server's latency impact ratio. The latency impact ratio refers to the proportion of a single server's historical interaction processes during the encryption optimization demand period to its total historical interaction processes across all periods. This indicator reflects the degree of overlap between its business activities and the problem period in time. The latency impact value is the average of the server's latency impact ratio over multiple days, used to assess the persistence and stability of its impact. An affected server refers to a server whose latency impact value exceeds a preset latency impact threshold.

[0096] When overall coverage is insufficient, it is necessary to accurately identify which servers not on the list are suffering from significant latency risks. The latency impact ratio, based on the time characteristics of the server's own business, can identify those "vulnerable" nodes whose business is highly dependent on the problematic time period and therefore extremely sensitive to latency. This avoids omissions that may occur when judging solely based on total interaction frequency, shifting the assessment perspective from "breadth of group coverage" to "depth of individual vulnerability," accurately locating high-risk but uncovered servers, and ensuring that updates effectively fill existing protection blind spots.

[0097] Example: A server that performs data archiving at a set time every morning has 30% of its interactions concentrated during the encryption optimization period. Although its total interaction volume is not large, an interruption during this period will directly cause its core business to fail. Therefore, its latency impact is extremely high and it should be identified as a potentially affected server.

[0098] The above steps include the following: S421 Based on the average value of the server's latency impact ratio on different dates, determine the latency impact value of the server, and determine whether there are servers whose latency impact value is greater than a preset latency impact threshold. If yes, proceed to step S422; otherwise, determine that the update identification and processing strategy for the potential optimization target of the encryption optimization server is no update processing required. S422 Servers with latency impact values ​​greater than the preset latency impact threshold are identified as affected servers. Determine whether the number of affected servers is greater than a preset affected server number threshold. If yes, determine that the update identification and processing strategy for the potential optimization target of the encryption optimization server is the preset update identification strategy; otherwise, proceed to step S43.

[0099] After identifying individual high-impact servers, it's necessary to determine whether this is an isolated phenomenon or a group trend. A few affected servers may stem from isolated business adjustments, making a global update less urgent. However, if multiple servers are affected simultaneously, it indicates that delays during the optimization period will have a significant impact, greatly increasing the necessity for a systemic update. A quantitative assessment of the potential delay impact is crucial to provide an objective basis for initiating a batch update, preventing overreaction to a single anomaly or neglect of collective risks.

[0100] S43 determines the update identification and processing strategy for the potential optimization targets of the encryption optimization server based on the proportion of encryption optimization on different dates and the proportion of latency impact on different servers.

[0101] The above steps include the following: based on the proportion of the number of days with coverage deviation, determine the threshold of the number of servers affected; determine whether the number of servers affected is greater than the threshold of the number of servers affected; if so, determine the update identification and processing strategy for the potential optimization target of the encryption optimization server as the second preset update identification strategy; if not, determine the update identification and processing strategy for the potential optimization target of the encryption optimization server as no update processing is required.

[0102] It should be noted that the larger the proportion of the number of dates with coverage deviation, the smaller the threshold for the number of impacts on the server.

[0103] In this step, a dynamic value is used, and its magnitude is negatively correlated with the proportion of coverage deviation dates. This step handles complex situations that cannot be directly decided by previous steps (such as when both coverage deviation and new risk scale are at a moderate level). It introduces dynamic correlation logic: the more prevalent the coverage deviation (the larger the proportion), the more severe the failure of the existing list, that is, the smaller the impact on improvements with latency, and the more urgent the system's need for improved coverage. Therefore, the requirement for the number of impact servers that would severely affect the latency required to trigger the update should be reduced (i.e., dynamically lowering the impact quantity threshold), achieving adaptive and refined final decision-making. This allows the update triggering conditions to be dynamically adjusted according to the severity of the problem, enhancing the rationality and flexibility of the method in complex scenarios.

[0104] Regarding the default update identification strategy and the second default update identification strategy: These strategies differentiate the intensity and priority of update operations in different scenarios. The default update identification strategy typically addresses specific situations with severe coverage discrepancies and a large number of affected servers. Its triggering conditions are more comprehensive and stringent, aiming to perform a relatively comprehensive review and addition of targets. The second default update identification strategy, on the other hand, is for situations triggered by S43 comprehensive adjudication or where the degree of new risk aggregation is moderate. Its strategy focuses more on precisely adding individual servers with the greatest impact.

[0105] Provide differentiated update operation guidance, enabling the system to not only determine "whether to update", but also to obtain strategy suggestions on "how to update", supporting different granular operations from "full refresh" to "precise supplementation".

[0106] Specifically, the preset update identification strategy is as follows: if there are no new potential optimization targets in the most recent preset time period, and the proportion of dates with encryption processing delay periods in the encryption optimization demand period is greater than a preset date proportion value, then the server with the largest delay impact value among the potential optimization targets is taken as the potential update target.

[0107] Specifically, the encryption processing delay period is the period during which the proportion of interactive processing processes with encryption processing delays greater than a preset time threshold does not meet the requirements for encryption optimization.

[0108] It is understandable that the second preset update identification strategy is to identify the server with the largest delay value among the potential optimization targets if there are no new potential optimization targets in the most recent preset time period, and there are encryption processing delay periods in the encryption optimization demand periods of different dates.

[0109] This embodiment strictly follows and conforms to the logic and data conclusions of embodiments S31 to S33. In a possible specific embodiment: Background and preconditions: Encryption optimization requirement period: 01:00 to 02:00 daily.

[0110] Current list of encryption optimization servers: Identified through S31-S33, only server SX is included. It was included because: in 10 observation days, its matching demand period ratio was only 20%, the average date overlap ratio was 40%, and the average ratio calculated by S33 was (0.2+0.4) / 2=0.3, slightly higher than the threshold of 0.2.

[0111] Analysis period: the last 5 working days (D1 to D5).

[0112] Logical consistency constraint: In S31-S33, if a server's average "date overlap ratio" (i.e., the core input of "latency impact value" in this method) is extremely high (e.g., >80%), its "average ratio" is very likely to exceed the threshold of S33 and be identified. Therefore, servers to be analyzed in S42 that are not in the list must have a relatively low or medium latency impact value, or be excluded by S33 due to an extremely low "matching demand time period ratio".

[0113] Execute S41: Calculate the encryption optimization percentage daily (only SX is listed): D1: 8 interactive servers, 1 optimization server (SX), accounting for 12.5%.

[0114] D2: 7 interactive servers and 1 optimization server (SX), accounting for 14.3%.

[0115] D3: 9 interactive servers and 1 optimization server (SX), accounting for 11.1%.

[0116] D4: 6 interactive servers and 1 optimization server (SX), accounting for 16.7%.

[0117] D5: 8 interactive servers and 1 optimization server (SX), accounting for 12.5%.

[0118] The average encryption optimization percentage over 5 days is calculated as: (12.5%+14.3%+11.1%+16.7%+12.5%) / 5 = 13.4%.

[0119] The preset encryption optimization percentage threshold is 50%. Since 13.4% < 50%, we proceed to scenario 2, identifying coverage deviation dates: all 5-day periods have a percentage of no more than 50%, therefore all are coverage deviation dates. The percentage of coverage deviation dates is 5 / 5 = 100%, and the preset coverage deviation date percentage threshold is 60%. Since 100% > 60%, according to the process, a preset update identification strategy should be initially considered.

[0120] Execute S42: Filter out all servers that interacted with the target server between 01:00 and 02:00 during the time period D1-D5 but are not currently listed (i.e., not SX). Assume this includes servers A, B, C, and D.

[0121] Calculate the latency impact values ​​(5-day average latency impact percentage) for these servers. To ensure consistency with the logic in S31-S33, these values ​​should be at a medium or low level: Server A: Latency impact value = 62%, Server B: Latency impact value = 58%, Server C: Latency impact value = 40%, Server D: Latency impact value = 68%; Execute S421: The preset latency impact threshold is 65%. It was found that only Server D (68%) has a latency impact value greater than this threshold.

[0122] Execution S422: Therefore, the number of affected servers is D, and the quantity is 1. The preset threshold for the number of affected servers is 2. Since 1 < 2, the condition for directly triggering the preset update identification policy is not met, so proceed to S43.

[0123] Execution S43: The percentage of the number of covered deviation dates is 100%. According to the rule that "the larger the percentage of the number of covered deviation dates, the smaller the threshold of the number of affected servers", since the percentage is 100%, the system dynamically determines the threshold of the number of affected servers to be 0.9. The current number of affected servers is 0.9. Since 1>0.9, it is determined that an update is needed.

[0124] Since this conclusion was reached through S43 comprehensive adjudication (the coverage deviation was extremely serious, but only one server was affected), the system determined to adopt the second preset update identification strategy.

[0125] The second preset update identification strategy logic is executed: It checks if there are any new potential optimization targets within the most recent preset time period (e.g., 3 days). The check reveals that encryption processing delays exist in the encryption optimization requirement periods from D1 to D5. After all conditions are met, the system identifies server D (68%), which is not a current potential optimization target and has the largest delay impact value, as the potential update target.

[0126] This method introduces a crucial dynamic evaluation and update mechanism to the static configuration of encryption optimization targets, demonstrating significant systems engineering value. Its primary value lies in achieving continuous adaptability of the optimization strategy. By monitoring the breadth of the optimization list and identifying servers with high latency impact, it can respond promptly to business evolution and changes in traffic patterns, ensuring that security optimization resources are always focused on the most critical risk points. Secondly, the method's multi-level condition-triggered decision-making framework ensures both scientific decision-making and execution efficiency. Through a progressive process from rapid macro-level screening to in-depth micro-level analysis, and finally to comprehensive dynamic adjudication, it effectively balances judgment speed and decision accuracy. Finally, by outputting clear potential update targets and differentiated update strategies, this method transforms intelligent analysis conclusions into automatically executable operational instructions, providing core decision support for building a closed-loop, intelligent operation and maintenance security system. This ensures the sustained and accurate protection of system service quality and data communication security in dynamic and complex environments.

[0127] Furthermore, the method for determining the update management of potential optimization targets is as follows: In this embodiment, potential optimization targets are comprehensively evaluated based on three dimensions: risk concentration, target urgency, and backlog resolution, to determine a safe and orderly update management plan. Its core logic is a decision-making process that gradually resolves complexity, progressing from simple to complex. First, targets that can significantly disperse risk (low overlap coefficient) are prioritized for approval. Second, when targets are scarce, clearly identified high-risk targets are processed quickly. Next, it prevents the stifling of future optimization opportunities by approving targets with too broad coverage. Finally, when faced with a large backlog of highly overlapping targets, the target with the least deterioration to the overall risk profile is selected for approval by analyzing the interrelationships between targets. This allows for the gradual resolution of the backlog in the most controllable way, avoiding excessively high and concentrated security impacts on periods of encryption optimization demand due to prolonged stagnation or indiscriminate approval.

[0128] S51 determines the number of potential optimization targets based on the data of potential optimization targets. Potential optimization targets refer to servers identified through the updated identification and processing strategies in S41-S43 that are significantly affected by latency during the encryption optimization demand period (e.g., latency impact value exceeds a threshold) and are not currently included in the encryption optimization server list. This number is the basis for judging the problem scale. A large number of potential targets means a large backlog of high-risk nodes awaiting processing, resulting in high decision-making complexity, thus quantifying the scale and complexity of the current task requiring decision-making.

[0129] S52 determines the overlap coefficient of frequent interaction periods between the potential optimization target and the encryption optimization server based on the degree of correlation between the potential optimization target and the encryption optimization server in different interaction periods; it should be noted that the frequent interaction period is the interaction period in which the average percentage of the number of interaction processes on different dates is greater than a preset percentage.

[0130] Frequent interaction periods refer to the time windows during which the average percentage of interactions between a server and a target server exceeds a preset threshold within a historical period. Overlap coefficient refers to the proportion of frequent interaction periods of a potential optimization target that overlap with the frequent interaction periods of any existing encryption optimization server, relative to its total number of frequent interaction periods. It quantifies the degree of overlap between a single potential target and the existing system during active encryption periods. A high overlap coefficient indicates that its introduction will directly exacerbate the risk of homogenization of encryption strategies during a specific period.

[0131] Specifically, the overlap coefficient is determined based on the proportion of frequent interaction periods of the encryption optimization server in the frequent interaction periods of the potential optimization target.

[0132] S53 determines the update management method for the potential optimization targets based on the number of potential optimization targets, the overlap coefficient of the frequent interaction periods between the potential optimization targets and the encryption optimization server, and the frequent interaction periods.

[0133] Furthermore, the above steps specifically include: S531 determining whether there are potential optimization targets with an overlap coefficient less than a preset overlap coefficient threshold. If so, the potential optimization target with an overlap coefficient less than the preset overlap coefficient threshold and the smallest overlap coefficient is selected as the potential optimization target for updating the encryption optimization server. If not, proceed to step S532; prioritize the approval of potential targets with an overlap coefficient lower than the security threshold. These targets have a low degree of overlap with the frequent interaction periods of the encryption optimization server, therefore, a hash function-based encryption method based on static encryption is used simultaneously. In this case, during the overlapping frequent interaction periods, if a leakage risk occurs, the impact is small because the number of servers using the static encryption method is relatively small, achieving low-risk, high-return optimization coverage expansion.

[0134] S532 determines whether the number of potential optimization targets is less than a preset threshold for the number of potential optimization targets. If so, the update process for potential optimization targets is temporarily suspended, i.e., none of them are updated to the encryption optimization server. If not, proceed to step S533. When the number of potential targets is small, it indicates that the number of clearly identified high-risk points is limited, and at this time, the overlap between the frequent interaction periods of all potential optimization targets and the encryption optimization server is high. Therefore, updating would lead to a high risk of leakage. When the delay impact is small, the update process for the encryption optimization server is temporarily suspended to ensure data security.

[0135] S533 Based on the number of frequent interaction periods of the potential optimization targets, determine the frequent interaction periods of the potential optimization targets excluding the frequent interaction periods of the encryption optimization server, and take these as the influencing interaction periods. Determine whether there are potential optimization targets whose number of influencing interaction periods is less than a preset threshold. If so, all potential optimization targets whose number of influencing interaction periods is less than the preset threshold are taken as update targets, i.e., updated to the encryption optimization server. If not, proceed to step S534. The influencing interaction period refers to the part of the frequent interaction period of a potential optimization target that does not overlap with the frequent interaction period of the existing encryption optimization server, i.e., the independent new period that it can contribute.

[0136] Assess the long-term impact of updating individual objectives on the system's future flexibility. If an objective has too many independent interaction periods, these periods will be immediately "defined" and occupied once approved. In future cycles, any other potential objective whose business overlaps with these new periods will have a significantly increased overlap factor, making it more difficult to meet the update criteria. This essentially sets up numerous "entry barriers" prematurely, severely limiting the system's ability to absorb other potentially better or more urgent objectives in the future, leading to rigid optimization paths and decreased responsiveness. Maintaining the system's long-term adaptability and optimization potential is crucial, and it's essential to avoid overdrawing future optimization space by introducing overly broad objectives.

[0137] S534 determines whether the number of potential optimization targets is greater than a preset threshold for the number of potential targets (greater than the preset threshold for the number of potential optimization targets). If yes, proceed to step S535. If no, determine that the update management method for the potential optimization targets is not required. At this time, the number of interaction periods affected is large. Once updated, the overlap coefficient of potential optimization targets will become larger, making it more difficult to update the encryption optimization server. S535 determines the number of other potential optimization targets whose interaction periods overlap with the potential optimization target based on the overlap data of the interaction periods affected by the potential optimization target. The potential optimization target with the smallest number of other potential optimization targets whose interaction periods overlap with the potential optimization target is selected as the update target, i.e., updated to the encryption optimization server.

[0138] This is a crucial step in resolving decision-making deadlock. When the process reaches this point, it means that the following situation exists: there is no objective with a low overlap coefficient (the first step is not satisfied).

[0139] There are a large number of potential targets, which is not a scarce period (the second step is not satisfied). Each target has a large number of independent interaction periods, and there are no targets with very little "resistance" (the third step is not satisfied).

[0140] This depicts a typical high-risk target backlog scenario: the core activity periods of a large number of servers highly overlap with those of existing optimized servers, and each has a wide range of business coverage. Prolonged lack of updates will lead to a risk backlog, but blindly approving any target could significantly exacerbate the risk concentration during a specific period.

[0141] Faced with this dilemma, the approach shifts to analyzing the interactions between potential targets. Specifically, for each potential target, the overlap between its "influence interaction period" and the "influence interaction periods" of all other potential targets is calculated. The target with the smallest overlap in influence interaction periods with other potential targets is selected as the updated target.

[0142] Minimizing global risk deterioration: Selecting the target with the least overlap with other backlog targets for updating means that the new encryption period "activated" in this approval has minimal overlap with the business of other pending servers. This results in the least impact of this update on increasing the overall "overlap coefficient" of the remaining backlog target set, i.e., the weakest effect on exacerbating the overall risk concentration of the system.

[0143] Orderly backlog clearing: This strategy is a greedy algorithm that removes the target that causes the least "damage" to the current backlog set at each step. This ensures that the system clears the backlog in the smoothest and most controllable way, avoiding a surge in update difficulty for the entire backlog group (i.e., a general increase in overlap coefficients) due to approving the wrong target all at once.

[0144] Avoid decision stagnation: It provides a clear decision-making path in complex and high-risk scenarios, preventing the system from falling into a state of inaction due to its inability to make a "perfect" choice, and ensuring the continuous optimization process.

[0145] Continuing from the background of the aforementioned embodiments: the encryption optimization requirement period is 01:00-02:00, and the current list is [SX].

[0146] Scenario setting: Through the S41-S43 process, three potential optimization objectives have been identified: D, E, and F. Their overlap coefficients are all high (>0.5), and the number of interaction periods they affect is also large (≥2), which meets the conditions for entering the fourth and fifth sub-steps.

[0147] Execute S51: The number of potential optimization objectives is 3.

[0148] Executing S52 (simplified): The calculated overlap coefficients for D, E, and F are 0.6, 0.7, and 0.8, respectively. The preset threshold is 0.5, therefore none of them meet the standard.

[0149] Execute S53: First judgment: No target overlap coefficient <0.5, fail.

[0150] Second judgment: The target quantity is 3, which is not less than the scarcity period threshold (e.g., 2), so it fails.

[0151] Third judgment: Assuming that the number of interaction periods of the influence of D, E, and F are 2, 3, and 2 respectively, and none of them are less than the resistance threshold (e.g., 1), it will not pass.

[0152] Proceed to the fourth and fifth sub-steps (careful dredging): Step four: Determine if the number of potential targets (3) is greater than a higher number threshold (e.g., 2). If the condition is met, proceed to the final selection.

[0153] Step 5: Analyze the overlap of the interaction periods between the targets.

[0154] Assume that the period of influence of D is T1 and T2.

[0155] The periods of influence of E are T2, T3, and T4.

[0156] The periods of influence of F are T1 and T4.

[0157] Calculate the overlap count between the impact period of each target and the impact period of other targets: D: its T1 overlaps with the T1 of F, and its T2 overlaps with the T2 of E → the overlap count is 2.

[0158] E: Its T2 coincides with D, and its T4 coincides with F → The number of coincidences is 2.

[0159] F: Its T1 coincides with D, and its T4 coincides with E → The coincidence count is 2.

[0160] Selecting the Update Target: In this example, all three have the same count (2). According to the rules, the target with the largest delay impact is selected. Target E, which has the largest delay impact, is chosen as the update target. Given that all three targets have a similar impact on the backlog group, target E, which is currently most severely affected by the delay, is prioritized for approval to maximize the benefits of risk mitigation.

[0161] The update management mechanism constructed by this method achieves complete decision-making coverage from routine optimization to handling complex deadlocks, demonstrating significant systems engineering value. Its core breakthrough lies in providing a solution based on the degree of overlap between frequent interaction periods with existing optimization targets. This avoids the technical problem of excessively high data leakage risks caused by large-scale servers using the same encryption method during the same time period. It also allows for targeted construction of optimization demand servers, reducing both their own latency impact and the severity of latency during the target period, while providing an intelligent solution to the real-world dilemma of "high-risk target backlog." By introducing "target impact overlap analysis" as the final adjudication tool, the method can still guide the system to make prudent update choices that minimize the deterioration of the overall risk landscape even when all simple rules fail. This not only effectively avoids risk stagnation caused by prolonged lack of updates but, more importantly, prevents a sudden increase in risk concentration caused by improper updates. This method ensures that the evolution of the encryption optimization server list is a controlled process that is always centered on controlling systemic security risks and can continuously move forward, providing crucial dynamic governance logic for building a large-scale distributed security system with resilience, scalability, and self-balancing capabilities.

[0162] In a second aspect, according to Embodiment 2, the present invention provides a computer system comprising: a memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, wherein the processor executes the above-described data information security encryption method based on a hash function when running the computer program.

[0163] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0164] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0165] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A data information security encryption method based on a hash function, characterized in that, Specifically, it includes: Based on the request data from the target server, determine the interaction processing delay data of the target server in different time periods. Combined with the interaction data between different servers and the target server in the time periods, determine the encryption optimization requirement period for data information based on the hash function. Based on the interaction period between the server and the target server, and the degree of overlap between the interaction period and the encryption optimization requirement period, determine the encryption optimization server among the servers. Based on the data from the encryption optimization server, and taking into account the latency impact of different servers during the encryption optimization period, an update identification and processing strategy for the potential optimization targets of the encryption optimization server is determined. Based on the aforementioned update identification and processing strategy, potential optimization targets are determined. Based on the degree of correlation between the potential optimization targets and the encryption optimization server in different interaction periods, an update management method for the potential optimization targets is determined.

2. The data information security encryption method based on hash function as described in claim 1, characterized in that, The interaction processing delay data of the target server includes the interaction processing delay process of the target server and the delay duration of the interaction processing delay process.

3. The data information security encryption method based on hash function as described in claim 1, characterized in that, The interaction data between the server and the target server includes the number of historical interaction processes between the server and the target server during the time period.

4. The data information security encryption method based on hash function as described in claim 1, characterized in that, The method for determining the encryption optimization requirement period is as follows: using the interaction processing delay data of the target server in the period, the interaction processing delay process of the target server in the period is determined, and the delay risk period in the period is determined based on the interaction processing delay process data. Based on the interaction data between different servers and the target server during the latency risk period, the historical interaction process between the server and the target server during the latency risk period is determined; based on the historical interaction process between different servers and the target server during the latency risk period, it is determined whether the period belongs to the encryption optimization requirement period.

5. The data information security encryption method based on hash function as described in claim 4, characterized in that, The delay risk period is the period in which the average daily number of interactive processing delay processes exceeds a preset threshold for the number of delay processes.

6. The data information security encryption method based on hash function as described in claim 4, characterized in that, Based on the historical interaction processes between different servers and the target server during the latency risk period, it is determined whether the period belongs to the encryption optimization requirement period. Specifically, this includes: using the historical interaction processes between different servers and the target server during the latency risk period, identifying servers whose daily average number of historical interaction processes is greater than a preset threshold, and using these servers as matching servers. If the number of matching servers is greater than the preset threshold, then the period is determined to belong to the encryption optimization requirement period.

7. The data information security encryption method based on hash function as described in claim 1, characterized in that, The impact of server latency is determined based on the proportion of the number of historical interaction processes during the encryption optimization requirement period to the total number of historical interaction processes across all interaction periods.

8. The data information security encryption method based on hash function as described in claim 1, characterized in that, The method for determining the update management method of the potential optimization targets is as follows: based on the potential optimization target data, determine the number of potential optimization targets; Based on the degree of correlation between the potential optimization target and the encryption optimization server in different interaction periods, the overlap coefficient of the frequent interaction periods between the potential optimization target and the encryption optimization server is determined. Based on the number of potential optimization targets, the overlap coefficient of the frequent interaction periods between the potential optimization targets and the encryption optimization server, and the frequent interaction periods, an update management method for the potential optimization targets is determined.

9. The data information security encryption method based on hash function as described in claim 8, characterized in that, The overlap coefficient is determined based on the proportion of frequent interaction periods of the potential optimization target that include frequent interaction periods of the encryption optimization server.

10. A computer system, comprising: A memory and a processor connected in communication, and a computer program stored in the memory and capable of running on the processor, characterized in that, when the processor runs the computer program, it executes a data information security encryption method based on any one of claims 1-9.

Images