Method for generating cryptographic ciphertext based on xor obfuscation and user-specific encoding mapping

Abstract

The application relates to the technical field of information security, and discloses a password ciphertext generation method based on XOR confusion and user-specific encoding mapping. The method obtains a user identifier and an original password in an identity authentication system, generates a first hash value and a second hash value respectively, extracts a highest significant bit part and a non-overlapping mapping seed input byte segment from the first hash value, XORs the highest significant bit part with a lowest significant bit part of the second hash value to obtain an XOR combination result, generates an intermediate hash value and a user-specific mapping seed in combination with a global fixed salt value independent of a user database, temporarily generates a non-standard encoding mapping rule, converts the intermediate hash value into final password ciphertext, and discards the mapping rule after processing is completed. The application can reduce the risk of forming the same ciphertext from the same original password, analyzing the combination relationship, leaking the unified mapping rule, leading to batch analysis and cross-user attack result reuse, and the like.

Description

Technical Field

[0001] This invention relates to the field of information security technology, and in particular to a method for generating ciphertext based on XOR obfuscation and user-specific base mapping. Background Technology

[0002] In the authentication process of various information systems, users typically complete registration, password reset, or login authentication using a user identifier and their initial password. To avoid storing passwords in plaintext, the system generally converts the password into irreversible ciphertext before writing it into the user database, and then regenerates the ciphertext for comparison during subsequent authentication.

[0003] In existing technologies, common methods include directly performing one-way hash operations on the original password, or combining the username and password through concatenation, salting, XOR, or other processing before hashing. Some schemes also encode the hash result using standard hexadecimal, Base64, fixed encoding tables, or globally unified mapping tables to change the external appearance of the ciphertext.

[0004] However, directly performing one-way hashing on the original password may result in identical or highly similar ciphertext outputs when different users set the same original password. Concatenating the user identifier directly with the original password or performing only a simple combination before hashing still allows for analysis of the combination relationship. When using standard encoding or globally unified encoding rules to change the external form of the ciphertext, different users' ciphertexts usually still follow the same output processing path. Once the user database, encoding rules, or related configurations are illegally obtained, it may lead to centralized comparison and batch analysis of ciphertexts, or even reuse of attack results from some users among other users. Therefore, existing ciphertext generation methods suffer from technical problems such as high correlation of ciphertext outputs, insufficient distinguishability of ciphertext external forms, significant risks of cross-user batch analysis, and difficulty in balancing security between ciphertext storage and subsequent authentication re-enumeration.

[0005] The information disclosed in this background section is intended only to enhance the understanding of the overall background of the invention and should not be construed as an admission or in any way implying that the information constitutes prior art known to those skilled in the art. Summary of the Invention

[0006] The purpose of this invention is to provide a method for generating ciphertext based on XOR obfuscation and user-specific base mapping, in order to solve the problems in existing ciphertext generation methods, such as the same original password easily forming the same or related ciphertext output, the combination relationship between user identifier and original password being easily analyzed, the ciphertext output form depending on standard encoding or globally unified mapping rules, the risk of batch analysis after the persistent mapping rules are leaked, and the difficulty in determining the mapping rules based on user identity-related materials.

[0007] The technical solution of this invention is: a method for generating ciphertext based on XOR obfuscation and user-specific base mapping. The method is applied to an identity authentication system including an authentication server, an independent salt source, and a user database. The method includes: obtaining a user identifier and an initial password; the authentication server performing one-way hashing on the user identifier and the initial password respectively to generate a first hash value and a second hash value; the authentication server obtaining the most significant bit portion and a mapping seed input byte segment within a preset bit range distinct from the most significant bit portion from the first hash value; obtaining the least significant bit portion from the second hash value; performing a bitwise XOR operation on the most significant bit portion and the least significant bit portion to obtain an XOR combination result; and using the independent salt... The value source provides a globally fixed salt value independent of the user database. A secondary one-way hash is performed based on the globally fixed salt value and the XOR combination result to generate an intermediate hash value. The authentication server generates a user-specific mapping seed based on the mapping seed input byte segment and the globally fixed salt value. Based on the user-specific mapping seed, a deterministic pseudo-random permutation is performed on a preset character set that differs from the standard hash output format to generate a non-standard base temporary mapping rule. The intermediate hash value is converted into the final ciphertext according to the non-standard base temporary mapping rule. Based on the authentication request type, the final ciphertext is output to the corresponding ciphertext processing flow. After the ciphertext processing flow is completed, the non-standard base temporary mapping rule is discarded as a temporary memory object during this processing.

[0008] Optionally, obtaining the user identifier and the original password includes: performing format verification on the received authentication request, and extracting the user identifier and the original password from the authentication request when the preset format verification conditions are met; the type of the authentication request includes at least a new user registration request, a password reset request, or a login authentication request.

[0009] Optionally, the step of obtaining the most significant bit portion from the first hash value by the authentication server, and the mapping seed input byte segment within a preset bit range distinct from the most significant bit portion, includes: defining a continuous byte of a preset high-bit width in the first hash value as a first isolation zone, and using the byte content corresponding to the first isolation zone as the most significant bit portion; selecting a preset byte range in the first hash value that does not overlap with the byte range corresponding to the first isolation zone as a second isolation zone, and using the byte content corresponding to the second isolation zone as the mapping seed input byte segment; confirming that the byte range corresponding to the first isolation zone and the byte range corresponding to the second isolation zone do not intersect; when it is confirmed that there is no intersection, using the most significant bit portion as content obfuscation data for XOR combination, and using the mapping seed input byte segment as formal obfuscation data for mapping rule derivation.

[0010] Optionally, the independent salt source includes a hardware security module, and the globally fixed salt is stored in the protected storage area of ​​the hardware security module; the step of performing a secondary one-way hash based on the globally fixed salt and the XOR combination result to generate an intermediate hash value includes: sending the XOR combination result to the hardware security module; the hardware security module performing a secondary one-way hash based on the globally fixed salt and the XOR combination result to generate the intermediate hash value; and returning the intermediate hash value to the authentication server.

[0011] Optionally, the step of generating a user-specific mapping seed by the authentication server based on the mapping seed input byte segment and the global fixed salt value includes: using the global fixed salt value or a parameter derived from the global fixed salt value as a key; using the mapping seed input byte segment as the encrypted message body; calling a hash message authentication code algorithm with message authentication capability to perform calculation, and outputting the user-specific mapping seed that exists only in the lifetime of this identity authentication session.

[0012] Optionally, the step of performing deterministic pseudo-random permutation on a preset character set that differs from the standard hash output form based on the user-specific mapping seed to generate a non-standard base temporary mapping rule includes: using the user-specific mapping seed as the pseudo-random source of a deterministic pseudo-random number generator; within the allocated volatile memory space, employing a deterministic pseudo-random permutation algorithm, relying on the pseudo-random index values ​​generated by the deterministic pseudo-random number generator, to perform element-random swapping operations on the preset character set composed of a mixture of basic letters and extended character sets; and outputting an out-of-order temporary character mapping table as the non-standard base temporary mapping rule.

[0013] Optionally, when the authentication request is a new user registration request or a password reset request, the corresponding ciphertext processing flow includes writing or updating to a unique ciphertext field. Writing or updating the final password ciphertext to a unique ciphertext field includes: writing or updating the final password ciphertext as a normal string to a unique ciphertext field through a persistent relational database engine, without adding any additional table structure for storing the non-standard base temporary mapping rules.

[0014] Optionally, when the authentication request type is a login authentication request, the corresponding ciphertext processing procedure includes retrieving existing ciphertext and performing authentication comparison, and using the final ciphertext for authentication comparison with the existing ciphertext, including: retrieving the existing ciphertext corresponding to the user identifier from the user database; comparing the final ciphertext generated this time with the existing ciphertext using a constant-time comparison method; and outputting an authentication result indicating whether the login authentication is successful based on the comparison result.

[0015] Optionally, the step of discarding the non-standard base temporary mapping rule as a temporary memory object during the current processing after the ciphertext processing is completed includes: when a callback signal indicating that the final ciphertext has been successfully written to the user database or that the comparison is complete is captured, locating the volatile memory segment where the non-standard base temporary mapping rule is stored; releasing or deleting the temporary memory object corresponding to the non-standard base temporary mapping rule; and preventing the non-standard base temporary mapping rule from being written to the non-volatile persistent storage medium.

[0016] Optionally, the method further includes fallback and circuit breaker processing based on abnormal states: when any of the following conditions are detected, including format verification failure, intersection between the first and second isolation zones, or timeout of independent salt source calls, the ciphertext generation pipeline is refused to be started or the current authentication link is terminated; a unified failure response is returned to the request initiator, and the triggering of the saltless degradation comparison mode for the globally fixed salt value is prohibited, as is the generation of a persistent code table file used to replace the non-standard base temporary mapping rule.

[0017] Beneficial effects:

[0018] This invention generates a first hash value and a second hash value for the user identifier and the original password respectively. It then selects non-overlapping bit segments from the first hash value, using a portion of these segments for XOR combination and another portion for mapping seed derivation. This reduces the risk of correlation analysis caused by directly concatenating or simply combining the user identifier and the original password. Furthermore, it generates a user-specific mapping seed by combining the mapping seed input byte segment with a globally fixed salt value independent of the user database, and temporarily generates mapping rules based on this. This ensures that the final ciphertext conversion rules are determined by the user's identity-related materials. By releasing or deleting the temporary mapping rules after writing, updating, or authentication comparison, the user database only stores the final ciphertext and not the mapping rules. This reduces the risk of batch analysis caused by persistent mapping table leakage and increases the difficulty of directly reusing attack results among different users. Attached Figure Description

[0019] Figure 1 This is a schematic diagram of the overall process of the cryptographic ciphertext generation method provided in the embodiments of the present invention;

[0020] Figure 2 This is a schematic diagram of the isolation and XOR combination processing of the non-overlapping bit segments of the first hash value provided in the embodiment of the present invention;

[0021] Figure 3 This is a schematic diagram of user-specific mapping seed generation and non-standard base temporary mapping rule generation provided in the embodiments of the present invention;

[0022] Figure 4 This is a schematic diagram illustrating the final password ciphertext storage, authentication comparison, and lifecycle control of temporary mapping rules provided in the embodiments of the present invention. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only for explaining the invention and are not intended to limit the invention; that is, the described embodiments are merely some embodiments of the invention, and not all embodiments. The components of the embodiments of the invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations.

[0024] Therefore, the following detailed description of the embodiments of the invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but merely to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the invention without inventive effort are within the scope of protection of the invention.

[0025] It should be noted that relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0026] As mentioned earlier, existing information systems typically use one-way hash functions to digest plaintext passwords when protecting user passwords, and then write the resulting digest into the user database in standard hexadecimal or other fixed encoding formats. When different users set the same password, direct hashing may produce the same digest; when usernames and passwords are hashed using direct concatenation or simple salting, analyzable combination relationships may still be preserved between them; when the system uses a globally unified and persistently stored encoding table to change the external form of the ciphertext, once this encoding table is leaked, the related ciphertext obfuscation rules can be easily analyzed.

[0027] Furthermore, if the system uses a globally unified and persistently stored encoding table or mapping table to convert the external form of ciphertext, this encoding table typically lacks a deterministic user-specific binding relationship with a specific user identity. When this encoding table is leaked or subjected to centralized reverse analysis, the ciphertext conversion rules for different users may be restored according to the same rules; moreover, since the global encoding table is not derived in real time from each user's own identity-related materials, it is difficult to prevent the analysis results built for a single user from being reused for other users. Therefore, the existing solution not only faces the risk of correlation analysis at the ciphertext content level, but also the risk of batch analysis brought about by the unification of ciphertext conversion rules.

[0028] To address this, the present invention provides a method for generating ciphertext based on XOR obfuscation and user-specific base mapping. This method is applied to an identity authentication system comprising an authentication server, an independent salt source, and a user database. It drives content obfuscation and formal obfuscation respectively through non-overlapping bit segments in the first hash value, creating two separate processing branches for the same identity-related hash material on the processing side. By using a globally fixed salt value independent of the user database to participate in secondary one-way hashing and mapping seed generation, the intermediate hash value and mapping rules are simultaneously constrained by the independent salt value. By temporarily generating non-standard base temporary mapping rules in volatile memory and discarding them after processing, the user database stores only the final ciphertext and not the mapping rules.

[0029] The following is combined with Figures 1-4 This invention is described in detail.

[0030] Example 1:

[0031] like Figure 1 As shown in the figure, the cryptographic ciphertext generation method based on XOR obfuscation and user-specific base mapping provided by the present invention is applied to an identity authentication system including an authentication server, an independent salt source, and a user database. The method includes the following steps:

[0032] S100. Obtain the user identifier and the original password, and have the authentication server perform one-way hashing on the user identifier and the original password respectively to generate a first hash value and a second hash value.

[0033] S200: The authentication server obtains the most significant bit portion from the first hash value and a mapping seed input byte segment within a preset bit segment interval that is different from the most significant bit portion; obtains the least significant bit portion from the second hash value; and performs a bitwise XOR operation on the most significant bit portion and the least significant bit portion to obtain the XOR combination result.

[0034] S300: A globally fixed salt value, independent of the user database, is provided by the independent salt value source. A secondary one-way hash is performed based on the globally fixed salt value and the XOR combination result to generate an intermediate hash value.

[0035] S400: The authentication server generates a user-specific mapping seed based on the mapping seed input byte segment and the global fixed salt value, and performs deterministic pseudo-random permutation on a preset character set that differs from the standard hash output form according to the user-specific mapping seed to generate a non-standard base temporary mapping rule.

[0036] S500. The intermediate hash value is converted into the final ciphertext according to the non-standard base temporary mapping rule. The final ciphertext is output to the corresponding ciphertext processing flow according to the authentication request type. After the ciphertext processing flow is completed, the non-standard base temporary mapping rule is discarded as a temporary memory object during this processing.

[0037] Based on the above steps, the present invention enables the user identifier and the original password to undergo hash processing respectively, enables different segments in the first hash value to undergo XOR combination and mapping rule derivation respectively, enables the independent salt value source to form a controlled connection with the authentication server and user database, and enables the final password ciphertext to be discarded after writing, updating or authentication comparison is completed by triggering temporary mapping rules, thereby forming a closed-loop processing process between ciphertext generation, storage or authentication re-enactment and rule cleanup.

[0038] Example 2:

[0039] To provide a more detailed explanation of the technical solutions provided in the above embodiments, the present invention also provides another preferred embodiment. In this embodiment, the identity authentication system may include an authentication server, an independent salt source, a user database, and temporary rule lifecycle control logic running in the volatile memory of the authentication server. The independent salt source is independent of the user database and may be provided by a hardware security module, an independent security configuration file, or a security configuration source; the user database is used to store the final password ciphertext, but does not store non-standard base temporary mapping rules, rule indexes, or user-specific code table files.

[0040] In another embodiment of the present invention, step S100 may further include the following steps:

[0041] S110. Perform format verification on the received authentication request, and extract the user identifier and the original password from the authentication request when the preset format verification conditions are met.

[0042] S120, The types of the identity authentication request include at least a new user registration request, a password reset request, or a login authentication request;

[0043] S130. The authentication server performs one-way hashing on the user identifier and the original password respectively to generate a first hash value and a second hash value.

[0044] In this second embodiment, steps S110 to S130 may further include the following:

[0045] The authentication request receiving component or authentication server access interface receives requests from the registration, password reset, or login authentication process. After entering hash processing, all of these different types of authentication requests generate intermediate hash values, user-specific mapping rules, and final password ciphertexts according to the same ciphertext generation main chain. The final password ciphertext is only determined on the execution side based on the request type for database writing, ciphertext field updates, or authentication comparison.

[0046] The preset format verification conditions can be determined by the input specifications of the identity authentication system (e.g., the user identifier length is 6 to 64 characters, the original password length is 8 to 128 characters, and the request type field takes the value of registration, password reset, or login authentication). When the preset format verification conditions are met, the authentication server inputs the user identifier and the original password as the credentials to be hashed, and performs one-way hash operations on each. The one-way hash function can use a system preset algorithm (e.g., SHA-256 outputs a 256-bit hash value, or SM3 outputs a 256-bit hash value), and the one-way hash operation can be expressed by the following formula:

[0047]

[0048] in, This represents the user identifier, which originates from the authentication request that passes the format check in S110. This indicates that the original password originated from the same authentication request. This indicates the one-way hash function used by the authentication server; This represents the first hash value, which is used to subsequently obtain the most significant bit portion and the mapping seed input byte segment; This represents the second hash value, which is used to retrieve the least significant bit portion later. and Enter the bit field isolation and XOR combination process corresponding to S200.

[0049] For example, in this preferred embodiment, the authentication request is a login authentication request, the user identifier is user123, and the original password is pass456. After confirming that the request fields are complete and that the user identifier and the original password meet the preset format verification conditions, the authentication server uses SHA-256 to calculate H1 and H2 respectively. If the authentication request is a new user registration request or a password reset request, S100 still performs the same credential extraction and hashing process, the only difference being that the final password ciphertext enters the storage process in subsequent S500; if the authentication request is a login authentication request, the final password ciphertext enters the authentication comparison process in subsequent S500.

[0050] Furthermore, in this preferred embodiment, the authentication server writes the user identifier user123 and the original password pass456 into the temporary processing context of this authentication session, and establishes a session identifier for this processing context. This session identifier is only used to associate temporary computational objects between subsequent H1, H2, A, B, R, X, M, Seed, Rule, and C, and is not written into the user database as a password ciphertext field. Thus, the structured credential input output by S100 can be transmitted to the hash and bit-field isolation processing of S200 within the same session link.

[0051] In another embodiment of the invention, such as Figure 2 As shown, step S200 may further include the following steps:

[0052] S210. Define the consecutive bytes with a preset high bit width in the first hash value as the first isolation area, and take the byte content corresponding to the first isolation area as the most significant bit part;

[0053] S220. Select a preset byte interval from the first hash value that does not overlap with the byte interval corresponding to the first isolation zone as the second isolation zone, and use the byte content corresponding to the second isolation zone as the mapping seed input byte segment.

[0054] S230. Confirm that the byte range corresponding to the first isolation zone and the byte range corresponding to the second isolation zone do not overlap;

[0055] S240. When it is confirmed that there is no intersection, the most significant bit portion is used as content obfuscation data for XOR combination, and the mapping seed input byte segment is used as formal obfuscation data for mapping rule derivation.

[0056] S250. Obtain the least significant bit portion from the second hash value, and perform a bitwise XOR operation on the most significant bit portion and the least significant bit portion to obtain the XOR combination result.

[0057] In this second embodiment, steps S210 to S250 may further include the following:

[0058] The hash processing module and bit segment isolation module of the authentication server take over H1 and H2 generated by S100. The preset high-bit width can be determined based on the hash output length and system security configuration (for example, when H1 is 256 bits, the high 128 bits are used as the first isolation zone). The preset bit segment interval is determined by the hash output length and the system preset bit segment configuration (for example, when H1 is 256 bits and the first isolation zone is the high 128 bits, the last 16 bytes of H1, bytes 17 to 32 of H1, or bytes 129 to 192 of the high 128 bits are used as candidate bit segment intervals). The mapping seed input byte segment should be located within the preset bit segment interval that is distinct from the first isolation zone, and the byte interval corresponding to this preset bit segment interval should not overlap with the byte interval corresponding to the first isolation zone. The most significant bit portion and the least significant bit portion have the same preset bit width.

[0059] When the second isolation zone and the first isolation zone do not overlap, the authentication server uses the most significant bit portion as content obfuscation data and the mapping seed input byte segment as formal obfuscation data, and sends both to XOR processing and mapping rule derivation processing respectively. The XOR processing and mapping rule derivation processing are expressed by the following formula:

[0060]

[0061] ;

[0062]

[0063] Where A represents the most significant bit portion obtained from H1, originating from the first isolation region; B represents the least significant bit portion obtained from H2, originating from the lower bit range of the second hash value; m represents the preset bit width (e.g., 128 bits) corresponding to A and B; R represents the mapping seed input byte segment selected from H1, originating from the second isolation region that does not overlap with the first isolation region; Range(A) represents the byte range corresponding to A in H1; Range(R) represents the byte range corresponding to R in H1; This indicates that R and A have no intersection; This represents the underlying bitwise XOR arithmetic instruction, where X represents the XOR combination result obtained after performing a bitwise XOR operation on A and B. X enters S300 to participate in the secondary one-way hash, and R enters S400 to participate in the generation of the user-specific mapping seed.

[0064] For example, in this preferred embodiment, H1 is a 256-bit hash value output by SHA-256. The authentication server uses the high 128 bits of H1 as A, the low 128 bits of H2 as B, and the other bytes in H1 that do not overlap with A as R. For the selection of R, the following non-overlapping truncation methods can be adopted: First, when the high 128 bits are used as A, the last 16 bytes are selected from the low 128 bits of H1 as R; Second, when using an intermediate block as R, if the selected interval falls into the 1st to 128th bits of H1, it overlaps with A and is not used as R. The correct intermediate block should be selected from the interval that avoids the high 128 bits, for example, the 129th to 192nd bits; Third, when H1 is represented by byte numbers 0 to 31, bytes 16 to 31 of H1 can be taken as R, where the byte numbering starts from 0. In this case, A corresponds to the index [0:15] bytes, and R corresponds to the index [16:31] bytes, and there is no intersection between the two. After confirming that the byte interval corresponding to R does not overlap with the byte interval corresponding to A, the authentication server performs a bitwise XOR operation on A and B to obtain X, and sends X to the independent salt value corresponding to S300 for processing; at the same time, R is reserved as the message body for subsequent Seed generation. If an intersection is detected between the intended R and A, the interval will not be used, and another preset non-overlapping interval will be selected or the process will be terminated.

[0065] In another embodiment of the present invention, step S300 may further include the following steps:

[0066] S310, The independent salt value source includes a hardware security module, and the globally fixed salt value is stored in the protected storage area of ​​the hardware security module;

[0067] S320. Send the XOR combination result to the hardware security module;

[0068] S330. The hardware security module performs a secondary one-way hash based on the global fixed salt value and the XOR combination result to generate the intermediate hash value.

[0069] S340. Return the intermediate hash value to the authentication server.

[0070] In this second embodiment, steps S310 to S340 may further include the following:

[0071] The independent salt source is not mixed with the user database. The globally fixed salt value can be provided by the protected storage area of ​​the hardware security module, or by an independent security configuration file or security configuration source independent of the user database. The globally fixed salt value is a system-level fixed salt value independent of user records and does not change with individual user identifiers or user database records. When the independent salt value source is implemented using a security configuration file, the security configuration file is stored separately from the user database and participates only as a controlled source of the globally fixed salt value in the generation of secondary one-way hashing or mapping seed derivation parameters.

[0072] The length of the globally fixed salt value can be determined according to the system security configuration (e.g., no less than 256 bits). When the hardware security module is involved in the processing, the authentication server sends X obtained from S200 to the hardware security module. The hardware security module then performs a secondary one-way hash based on the globally fixed salt value and X within the protected processing environment, and returns the resulting intermediate hash value to the authentication server. The secondary hash operation is as follows:

[0073]

[0074] Where S represents a globally fixed salt value, derived from an independent salt value source; X represents the XOR combination result obtained from S200; "||" represents concatenation or a system-preset association method; M represents the secondary one-way hash function; M represents the intermediate hash value, which is the object to be transcoded subsequently by a non-standard base temporary mapping rule. M enters the dynamic transcoding process of S500. If the S call fails, the hardware security module responds and times out, or the secondary one-way hash fails, the saltless degradation comparison mode is not enabled, and the abnormal rollback and circuit breaker handling in S500 are entered.

[0075] For example, in this preferred embodiment, the globally fixed salt value S is 256 bits and stored in the protected storage area of ​​the hardware security module. The authentication server sends X to the hardware security module, which generates M based on S and X and returns it to the authentication server. If SHA-256 is used as the secondary one-way hash function, then M is a 256-bit intermediate hash value; if SM3 is used as the secondary one-way hash function, then M is also returned to the authentication server as the subsequent object to be transcoded. This intermediate hash value is not directly written into the user database as the final ciphertext, but is transcoded in S500 by a user-specific rule.

[0076] When generating user-specific mapping seeds, the authentication server can invoke the independent salt source, which performs HMAC / KDF based on R and S or their derived parameters and returns a Seed or a derived result. When S is not returned to the authentication server, the authentication server does not directly obtain S, but instead receives the Seed or derived result returned by the independent salt source. The authentication server sends the XOR combination result X to the hardware security module, which then invokes S within its protected storage area or protected processing environment, generates an intermediate hash value M based on S and X, and returns it to the authentication server. Thus, the authentication server obtains M required for subsequent transcoding without needing to store S in the user database or the authentication server's ordinary business storage area.

[0077] In another embodiment of the invention, such as Figure 3 As shown, step S400 may further include the following steps:

[0078] S410. The authentication server calls the independent salt source and uses the global fixed salt value or a parameter derived from the global fixed salt value as key material.

[0079] S420. Send or provide the mapping seed input byte segment as the message body;

[0080] S430. The authentication server or the independent salt source calls a hash message authentication code algorithm with message authentication capability under the call of the authentication server to calculate and output a user-specific mapping seed that is only used as a temporary object during this ciphertext generation or authentication process.

[0081] S440. Use the user-specific mapping seed as the pseudo-random source of the deterministic pseudo-random number generator;

[0082] S450. Within the allocated volatile memory space, a deterministic pseudo-random permutation algorithm is used, relying on the pseudo-random index value generated by the deterministic pseudo-random number generator, to perform element random swapping operations on the preset character set composed of a mixture of basic letters and extended character sets.

[0083] S460. Output a temporary character mapping table with disordered characters as the temporary mapping rule for the non-standard base.

[0084] In this second embodiment, steps S410 to S460 may further include the following:

[0085] The authentication server invokes an independent salt source to generate a user-specific mapping seed based on R obtained from S200 and S or parameters derived from S involved in S300. In scenarios where S is not returned to the authentication server, the independent salt source performs the corresponding HMAC / KDF calculation and returns the Seed or its derived result to the authentication server. The preset character set is determined by the system security configuration (e.g., a 62-character set consisting of numbers 0-9, uppercase letters AZ, and lowercase letters az, or a 70-character set formed by adding preset special characters to the 62-character set), used to form a non-standard base temporary mapping rule that differs from the standard hash output format, and its base is greater than hexadecimal. The authentication server allocates temporary space in volatile memory, uses the Seed as the pseudo-random source of a deterministic pseudo-random number generator, and performs deterministic pseudo-random permutation on the preset character set. The specific mapping seed and the non-standard base temporary mapping rule are expressed by the following formula:

[0086]

[0087] Where Seed represents the user-specific mapping seed; KDF represents the key derivation function or hash message authentication code calculation rule; S represents the globally fixed salt value or a parameter derived from it, which comes from an independent salt value source; R represents the mapping seed input byte segment, which comes from a preset byte range in H1 that does not overlap with A; The default character set is represented by: `Shuffle` represents the character set replacement rule driven deterministically by `Seed`; `Rule` represents the temporary mapping rule for non-standard bases.

[0088] The above formula represents the logical relationship between Seed, which is deterministically generated by S or its derived parameters, and R. When S does not return to the authentication server, the KDF or hash message authentication code calculation is performed by an independent salt source, and the authentication server receives Seed or its derived result. In the formula, Seed and Rule are formed in S400.

[0089] For example, in this preferred embodiment, the authentication server provides the last 16 bytes R of H1 as the message body to an independent salt source. The independent salt source performs HMAC / KDF using a globally fixed salt value S or parameters derived from S as key material to generate a 256-bit Seed and returns it to the authentication server. If the system configuration allows the authentication server to obtain the key parameters derived from S, the authentication server can also perform HMAC / KDF based on these derived parameters and R to generate a Seed. Subsequently, the Seed drives a deterministic pseudo-random number generator to perform a reverse-order resettable permutation on the 62-character set. The reverse-order resettable permutation can be implemented using the Fisher-Yates permutation algorithm. Specifically, the authentication server can treat the character set as an array, traversing backward from the end of the array. In each round, it obtains a cursor position within the current commutable range based on the pseudo-random number driven by the Seed, and swaps the character at the current position with the character at the cursor position until all characters are permuted. The out-of-order temporary character mapping table generated in this process is the Rule. Because the permutation is deterministically driven by Seed, the same rule can be reproduced during login authentication under the same user identifier, the same globally fixed salt value, the same R selection rule, and the same character set configuration.

[0090] For example, in another preferred embodiment, H1 and H2 can be generated using SM3. When the independent salt source is the hardware security module, the hardware security module performs HMAC-SM3 calculation on R based on the globally fixed salt value S or parameters derived from S to generate a Seed. The authentication server then generates a Rule using a 70-character set containing special characters based on this Seed. The above hash algorithm, message authentication code algorithm, and character set cardinality are all specific implementation methods and do not change the main processing principle of "R and A do not overlap, Seed is deterministically driven, and Rule is temporarily generated and not persistent".

[0091] Furthermore, in this preferred embodiment, the authentication server provides R as the message body to an independent salt source, or generates a Seed using the derived parameters of S as key material when obtaining the derived parameters of S. After obtaining the Seed, the authentication server binds the Seed to the temporary rule generation object for this session. Subsequently, the character set is exchanged item by item according to the pseudo-random cursor driven by the Seed to obtain the Rule. This Rule is associated with the session identifier and is transmitted to the transcoding processing module of S500 along with M, without establishing a Rule field, Rule index, or Rule file in the user database.

[0092] Through the above processing, the same user can reproduce the same Rule under the same user identifier, the same globally fixed salt value, the same R selection rule, and the same character set configuration. Different users, due to their different user identifiers, generate different H1 values ​​and R values ​​derived from H1, thus causing Seed and Rule to change according to user-related materials. Therefore, each user's final ciphertext is transformed through their corresponding user-specific Rule, achieving the processing effect of "each user corresponding to a different temporary mapping rule" without saving user-specific code table files.

[0093] In another embodiment of the invention, such as Figure 4 As shown, step S500 may further include the following steps:

[0094] S510. Convert the intermediate hash value into the final ciphertext according to the non-standard base temporary mapping rule.

[0095] For example, take M as an unsigned integer N, take the preset character set length q as the base, repeatedly execute Nmodq to get the index value, take the corresponding character in Rule as the output character, update N=floor(N / q) until N is 0, and concatenate in the preset order to get C.

[0096] N is an unsigned integer obtained by converting M according to the preset byte order, q is the number of characters in the Rule, N mod q is the Rule index, floor is the floor function, and the output characters can be concatenated in reverse order to form C.

[0097] S520. When the authentication request is a new user registration request or a password reset request, the final password ciphertext is written as a normal string to the unique ciphertext field through a persistent relational database engine, and no additional table structure is added for storing the non-standard base temporary mapping rules.

[0098] Since the user database only stores the final ciphertext C, and not the Rule, Rule index, or user-specific code table file, this process can complete the ciphertext storage without adding new mapping rule fields for each user or increasing the structure of the mapping table. For existing authentication systems, the fields originally used to store the ciphertext can continue to be used as the storage location for the final ciphertext C, and the non-standard base temporary mapping rules are only generated and used in the volatile memory of the authentication server.

[0099] The process mainly uses hashing, bitwise XOR, deterministic permutation, and string writing, and ultimately saves the final password ciphertext as a plain string. Therefore, it can be integrated into the existing identity authentication process without changing the purpose of the original user database ciphertext field.

[0100] S530. When the type of the identity authentication request is a login authentication request, retrieve the existing password ciphertext corresponding to the user identifier from the user database, compare the final password ciphertext generated this time with the existing password ciphertext in a constant time comparison method, and output the authentication result representing whether the login authentication is successful based on the comparison result.

[0101] S540. When a callback signal indicating that the final ciphertext has been successfully written to the user database or that the comparison has been completed is captured, locate the volatile memory segment where the non-standard base temporary mapping rule is stored.

[0102] S550. Release or delete the temporary memory object corresponding to the non-standard base temporary mapping rule;

[0103] S560, Prevent the non-standard base temporary mapping rule from being written to the non-volatile persistent storage medium;

[0104] S570. When any of the following conditions are detected, including format verification failure, intersection between the first and second isolation zones, or timeout of independent salt source call, the ciphertext generation pipeline is refused to be started or the current authentication link is terminated. A unified failure response is returned to the request initiator, and the triggering of the saltless degradation comparison mode for the global fixed salt value is prohibited, as is the generation of persistent code table files used to replace the non-standard base temporary mapping rules.

[0105] In this second embodiment, steps S510 to S570 may further include the following:

[0106] The encoding module encodes M according to the Rule to obtain the final ciphertext C. C then enters the database storage or authentication comparison process. For new user registration requests or password reset requests, the execution side writes C as a regular string into the unique ciphertext field of the user database. No new supplementary table structure is added for storing the Rule, no user-specific mapping table is saved, and no mapping rule index is saved. For login authentication requests, the authentication server reproduces the process from S100 to S510 to generate C, and retrieves the existing ciphertext D from the user database, then compares it using a constant-time comparison method. This constant-time comparison method can be set to compare all characters from the first character to the last character before outputting the result (e.g., regardless of whether the first character matches, the full-length comparison loop of C and D is completed before outputting the authentication result), to reduce judgment discrepancies caused by premature return during the comparison process.

[0107] After storage or comparison is completed, the user database write success signal, ciphertext comparison completion signal, mapping rule generation status, independent salt source call status, or temporary object cleanup status can be returned as feedback signals to the authentication server's lifecycle control logic. The lifecycle control logic locates the volatile memory segment storing the Rule and releases or deletes the corresponding temporary memory object; for temporary memory areas carrying the original password, hash intermediate state, Seed, or Rule, it can also perform overwriting or zeroing, but the specific cleanup interface name and platform implementation are not necessary limitations of this invention.

[0108] For example, in this preferred embodiment, the C generated by S510 in the registration process is written to the password_cipher field of the user database, and no new rule_table, rule_index, or user_mapping fields are added to the user database; in the password reset process, the new C overwrites the old ciphertext value in the original ciphertext field; in the login authentication process, after generating the current C, the authentication server reads the existing password ciphertext D and outputs the authentication success or failure status through constant-time comparison. Regardless of whether the C is successfully written, the comparison passes, or the comparison fails, the lifecycle control logic locates and releases the Rule object in the current session, and prevents the Rule from being written to files, databases, cached persistent areas, or other non-volatile storage media. For example, when the user identifier is empty, the original password field is missing, there is an intersection between the first and second isolation zones, the independent salt source call times out, KDF derivation fails, the rule cannot be reproduced, database write or read fails, communication fails, or feedback is missing, the authentication server terminates the current process, cleans up the temporary objects that have been formed, and returns a unified failure status; when the salt source is unavailable, saltless degradation is not enabled; when rule generation fails, the global unified mapping table is not used instead; when the database fails, temporary object cleanup is triggered first, and then a failure status is returned.

[0109] In security policy update scenarios, the authentication system can re-derive user-specific mapping seeds using a new global fixed salt value or new key derivation parameters. Based on the updated non-standard base temporary mapping rules, upon successful authentication or password reset and retrieval of the original password, the system regenerates C using the new salt value or new derivation parameters and overwrites the existing storage. During migration, the system can first reproduce the old Rule based on the old global fixed salt value, old derivation parameters, and old character set configuration, and complete the existing user authentication comparison. Then, upon successful authentication or password reset, a new Rule and a new C are generated based on the new global fixed salt value or new key derivation parameters, and the new C is used to update the unique ciphertext field in the user database. After the system's preset migration conditions are met (e.g., the target user completes ciphertext recoding after successful authentication, or the administrator confirms the completion of the batch migration task), the processing path corresponding to the old mapping rule is revoked. This processing does not change the main chain from S100 to S500, and remains based on "non-overlapping bit fields in H1 driving content obfuscation and formal obfuscation respectively, final password ciphertext storage instead of mapping rule storage, and rule discarding after completion."

[0110] In one security analysis method, the length of the first hash value H1 can be denoted as L, the bit width of the most significant bit portion A used for XOR combination can be denoted as m, and the bit width of the input byte segment R used for mapping the seed can be denoted as k. M and K are both determined by the hash output length and the system's preset bit segment configuration (e.g., L is 256 bits, M is 128 bits, K is 128 bits or 16 bytes thereof), and the bit segment interval corresponding to R does not overlap with the bit segment interval corresponding to A. Since A enters bitwise XOR processing and R enters Seed and Rule derivation processing, their source intervals in H1 are different. The authentication server can separate and manage content-obfuscated data and form-obfuscated data at the source. This analysis is used to illustrate the isolation effect of the non-overlapping bit segment configuration on the two processing links, without limiting it to specific attack complexity or cracking time.

[0111] Based on the above specific implementation process, this invention uses A in H1 for content obfuscation and R, which does not overlap with A, for formal obfuscation. This allows different bit segments in the hash value related to the same user identity to enter two processing chains at the source: XOR combination and mapping rule derivation. This reduces the direct correlation between content obfuscated materials and formal obfuscated materials. Furthermore, the non-standard base temporary mapping rule is derived in real time by R combined with a globally fixed salt value and is not persistently stored as a globally unified encoding table. This allows the ciphertext conversion rules for different users to be determined according to their respective identity-related materials. Further still, the final ciphertext is written as a normal string to the user database, while the Rule is released or deleted after storage or comparison, preventing the mapping rules from being exposed simultaneously when the user database is leaked. Therefore, this invention can form a processing method that connects ciphertext content obfuscation, user-specific formal conversion, and temporary rule lifecycle control without adding a new persistent mapping table field for each user.

[0112] Accordingly, this embodiment, through continuous processing from S100 to S500, causes the user identifier and original password obtained by the acquisition side to enter the processing side and generate H1 and H2 respectively. A and R in H1 flow to XOR combination and mapping rule derivation respectively, causing X to generate M with S provided by an independent salt source. The authentication server calls the independent salt source and generates Seed based on R and S or their derived parameters, thereby generating Rule. M is converted to C by Rule and enters the database for storage or authentication comparison. The storage or comparison result is fed back to the lifecycle control logic to trigger Rule discarding. Thus, this invention forms a closed loop within the same identity authentication system between acquisition, processing, transmission / association, output, execution, and feedback / abnormal rollback.

[0113] The above description is merely a preferred embodiment of the technical solution of the present invention and is not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A method for generating ciphertext based on XOR obfuscation and user-specific base mapping, characterized in that, The method is applied to an identity authentication system that includes an authentication server, an independent salt source, and a user database. The method includes: The user identifier and the original password are obtained, and the authentication server performs one-way hashing on the user identifier and the original password respectively to generate a first hash value and a second hash value. The authentication server obtains the most significant bit portion from the first hash value and a mapping seed input byte segment within a preset bit segment interval that is different from the most significant bit portion. It then obtains the least significant bit portion from the second hash value and performs a bitwise XOR operation on the most significant bit portion and the least significant bit portion to obtain the XOR combination result. A globally fixed salt value, independent of the user database, is provided by the independent salt value source. A secondary one-way hash is performed based on the globally fixed salt value and the XOR combination result to generate an intermediate hash value. The authentication server generates a user-specific mapping seed based on the mapping seed input byte segment and the global fixed salt value, and performs deterministic pseudo-random permutation on a preset character set that differs from the standard hash output form according to the user-specific mapping seed to generate a non-standard base temporary mapping rule. The intermediate hash value is converted into the final ciphertext according to the non-standard base temporary mapping rule. Based on the authentication request type, the final ciphertext is output to the corresponding ciphertext processing flow. After the ciphertext processing flow is completed, the non-standard base temporary mapping rule is discarded as a temporary memory object during this processing to reduce the correlation of ciphertext output and the risk of cross-user batch analysis.

2. The method according to claim 1, characterized in that, The process of obtaining the user identifier and the original password includes: The received authentication request is format-validated, and when the preset format validation conditions are met, the user identifier and the original password are extracted from the authentication request. The types of identity authentication requests include at least new user registration requests, password reset requests, or login authentication requests.

3. The method according to claim 1, characterized in that, The step of obtaining the most significant bit portion from the first hash value by the authentication server, and the mapping seed input byte segment within a preset bit segment interval different from the most significant bit portion, includes: The first hash value is divided into a first isolation zone with a preset high-width consecutive bytes, and the byte content corresponding to the first isolation zone is taken as the most significant bit part; Select a preset byte range from the first hash value that does not overlap with the byte range corresponding to the first isolation zone as the second isolation zone, and use the byte content corresponding to the second isolation zone as the mapping seed input byte segment; Confirm that the byte range corresponding to the first isolation zone and the byte range corresponding to the second isolation zone do not overlap; When it is confirmed that there is no intersection, the most significant bit portion is used as content obfuscation data for XOR combination, and the mapping seed input byte segment is used as formal obfuscation data for mapping rule derivation.

4. The method according to claim 1, characterized in that, The independent salt value source includes a hardware security module, and the globally fixed salt value is stored in the protected storage area of ​​the hardware security module; The process of generating an intermediate hash value by performing a secondary one-way hash based on the globally fixed salt value and the XOR combination result includes: The XOR combination result is sent to the hardware security module; The hardware security module performs a secondary one-way hash based on the global fixed salt value and the XOR combination result to generate the intermediate hash value; The intermediate hash value is returned to the authentication server.

5. The method according to claim 1, characterized in that, The generation of a user-specific mapping seed by the authentication server based on the mapping seed input byte segment and the globally fixed salt value includes: Use the global fixed salt value or a parameter derived from the global fixed salt value as the key; The mapping seed input byte segment is used as the message body; The authentication server or the independent salt source, under the call of the authentication server, invokes a hash message authentication code algorithm with message authentication capability to calculate and output the user-specific mapping seed.

6. The method according to claim 5, characterized in that, The step of performing deterministic pseudo-random permutation on a preset character set that differs from the standard hash output format based on the user-specific mapping seed to generate a non-standard base temporary mapping rule includes: The user-specific mapping seed is used as the pseudo-random source for the deterministic pseudo-random number generator; Within the allocated volatile memory space, a deterministic pseudo-random permutation algorithm is used, relying on the pseudo-random index value generated by the deterministic pseudo-random number generator, to perform element random swapping operations on the preset character set composed of a mixture of basic letters and extended character sets; Output a temporary character mapping table in disordered order, as the temporary mapping rule for the non-standard base.

7. The method according to claim 1, characterized in that, When the authentication request is a new user registration request or a password reset request, the corresponding ciphertext processing procedure includes writing or updating to a unique ciphertext field, and writing or updating the final password ciphertext to the unique ciphertext field, including: The final ciphertext is written as a regular string to the unique ciphertext field using a persistent relational database engine, without adding any additional table structure for storing the non-standard base temporary mapping rules.

8. The method according to claim 1, characterized in that, When the authentication request type is a login authentication request, the corresponding ciphertext processing procedure includes retrieving existing ciphertext and performing authentication comparison, and using the final ciphertext for authentication comparison with the existing ciphertext, including: Retrieve the existing password ciphertext corresponding to the user identifier from the user database; The final ciphertext generated this time is compared with the existing ciphertext using a constant-time comparison method; Based on the comparison results, an authentication result indicating whether the login authentication has passed is output.

9. The method according to claim 1, characterized in that, The step of discarding non-standard base temporary mapping rules as temporary memory objects during the current processing after the ciphertext processing is completed includes: When a callback signal indicating that the final ciphertext has been successfully written to the user database or that the comparison has been completed is captured, the volatile memory segment storing the non-standard base temporary mapping rule is located. Release or delete the temporary memory object corresponding to the non-standard base temporary mapping rule; Prevent the non-standard base temporary mapping rules from being written to non-volatile persistent storage media.

10. The method according to claim 1, characterized in that, The method also includes rollback and circuit breaker handling based on abnormal states: When any of the following conditions are detected, including format validation failure, intersection between the first and second isolation zones, or timeout of independent salt source call, the ciphertext generation pipeline will be refused to start or the current authentication link will be terminated. A unified failure response is returned to the request initiator, and the triggering of the saltless degradation comparison mode for the global fixed salt value is prohibited, as is the generation of persistent code table files used to replace the non-standard base temporary mapping rules.

Images