Digital signature method based on uniform standard interface

By introducing a unified standard interface into the ECDSA and SM2 digital signature algorithm library, the code complexity and development cost problems caused by inconsistent APIs are solved, and higher code universality and scalability are achieved.

CN119519976APending Publication Date: 2025-02-25GCSOFT CO LTD
View PDF 0 Cites 0 Cited by

Patent Information

Application Number
CN202411302671.3
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2024-09-18
Publication Date
2025-02-25

AI Technical Summary

Technical Problem

The APIs of the existing ECDSA and SM2 digital signature algorithm libraries are not unified, resulting in applications that need to be compatible with the two sets of algorithms that need to provide different calling codes, which increases code complexity and development costs.

Method used

Using a digital signature method based on a unified standard interface, a common EC standard interface is provided to realize compatibility of different signature algorithms by configuring the cryptography algorithm library and basic application components.

Benefits of technology

Reduces the code complexity of the application, improves the universality and scalability of the code, and reduces the cost and complexity of development and maintenance work.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN119519976A_ABST
    Figure CN119519976A_ABST
Patent Text Reader

Abstract

The invention discloses a digital signature method based on a unified standard interface, which belongs to the technical field of secure communication, and comprises the following steps: configuring a cryptographic algorithm library and a basic application component oriented to the cryptographic algorithm library, and providing a universal and standardized consistent EC standard interface for application programming, and the plurality of basic application components carry out interface-oriented programming compatible with different signature algorithms through the EC standard interface so as to complete configuration of the uniform standard interface. According to the method and the device, the uniform standard interface is established, so that the specific Villinus standard form elliptic curve signature algorithm is transparent to the application program, the code complexity of the application program is reduced, the universality and the expansibility of the code of the application program are improved, and the learning cost of application program developers is reduced; the workload of application program development and maintenance work is reduced, and the interactivity of application programs is improved.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention belongs to the technical field of secure communications, and in particular relates to a digital signature method based on a unified standard interface. Background Art

[0002] In the research and development of blockchain or other fields involving secure communications, a set of secure and reliable cryptographic algorithms is always needed, including digital signature algorithms, such as the current international mainstream ECDSA algorithm. At present, in order to strengthen information security management, China is promoting the SM series of algorithms, among which SM2 provides a digital signature algorithm based on the Weierstrass standard form elliptic curve.

[0003] Various programming languages ​​provide ECDSA or SM2 algorithm libraries. The elliptic curve used by SM2 is the same as the NIST curve used by ECDSA. They should have the same interface specifications. However, most ECDSA and SM2 algorithm libraries currently provide different APIs, which are incompatible with each other. The method names, parameter lists, parameter types, and return value types of the signature and verification interfaces are not unified. Many ECDSA or SM2 algorithm libraries only provide signature interfaces on private keys but do not provide verification interfaces on public keys. The algorithm parameter structures of signatures or verifications are not unified. The specific implementations of ECDSA and SM2 signature algorithms are different. Some configurations that need to be specified by parameters are not the same. The encoding / decoding standards of signature values ​​are not unified.

[0004] The above phenomenon results in some applications that need to be compatible with SM2 and ECDSA signature algorithms. It is necessary to provide different calling codes for the two sets of digital signature algorithms during development. This undoubtedly brings additional costs and risks to the application code engineering, increases code complexity, reduces the versatility and scalability of the code, increases the learning cost of developers, and increases the work of development and maintenance. Therefore, there is room for improvement. Summary of the invention

[0005] The purpose of the present invention is to propose a digital signature method based on a unified standard interface in order to solve the problem that different calling codes need to be provided for the two sets of digital signature algorithms during development of certain applications that need to be compatible with SM2 and ECDSA signature algorithms.

[0006] In order to achieve the above object, the present invention adopts the following technical solutions:

[0007] A digital signature method based on a unified standard interface, comprising:

[0008] Configure cryptographic algorithm libraries and basic application components, and provide universal and standardized EC standard interfaces for application programming;

[0009] The plurality of basic application components are programmed to be compatible with different signature algorithms through the EC standard interface to complete the configuration of the unified standard interface;

[0010] After the cryptographic algorithm library establishes the public and private keys, multiple basic object components sign or verify signatures through compatible EC standard interfaces.

[0011] As a further description of the above technical solution:

[0012] The EC standard interface includes:

[0013] EcSigner elliptic curve signature interface, used to obtain the public key corresponding to EcSigner and then digitally sign the signature subject;

[0014] EcVerifier elliptic curve signature verification interface, used to provide a signature verification function and perform signature verification on the public key of the elliptic curve;

[0015] EcSignerOpts elliptic curve signature parameter interface, used to provide signature parameters for different elliptic curve signature algorithms;

[0016] ECSignature elliptic curve signature structure, used to define the signature value structure.

[0017] As a further description of the above technical solution:

[0018] The specific steps for an application to perform signature verification through a compatible EC standard interface include:

[0019] The first application configured with the EC standard interface calls the GenerateKey function of the cryptographic algorithm library to create public and private keys, and the cryptographic algorithm library creates the public and private keys and returns them to the first application;

[0020] The first application EcSigner elliptic curve signature interface prepares the signature body;

[0021] The first application defines signature parameters and provides signature parameters and signature verification parameters through the EcSignerOpts elliptic curve signature parameter interface;

[0022] Through private key signing, the cryptographic algorithm library uses the private key to sign and returns the sign signature value to the first application;

[0023] The first application encodes the returned private key sign signature value through the ECSignature elliptic curve signature structure to obtain signStr, and transmits signStr, the digest signature body and the PublicKey public key to the second application;

[0024] The second application configured with the EC standard interface decodes signStr through the ECSignature elliptic curve signature structure;

[0025] The second application defines the signature parameters of signStr transmitted by the first application through the signature parameters and signature verification parameters provided by the EcSignerOpts elliptic curve signature parameter interface;

[0026] PublickKey.Verify uses the public key and cryptographic algorithm library to verify the signStr issued by the first application to complete the signature verification.

[0027] As a further description of the above technical solution:

[0028] The EcSigner elliptic curve signature interface includes a Public function for obtaining the public key corresponding to the EcSigner and a Sign function for digitally signing the signature subject.

[0029] As a further description of the above technical solution:

[0030] The signature body is the signature content, the type of which is a byte array, and also includes whether to perform hash processing on the signature content based on the parameter configuration of the specific algorithm.

[0031] As a further description of the above technical solution:

[0032] The EcVerifier elliptic curve signature verification interface includes a signature verification function Verify, and performs signature verification through the public key of the elliptic curve.

[0033] As a further description of the above technical solution:

[0034] The EcSignerOpts elliptic curve signature parameter interface includes:

[0035] HashFunc function, used to obtain a specific hash function or hash instance, used within the signing / verification algorithm;

[0036] NeedLowS function is used to configure whether to perform low-s processing in ECDSA signature and verification processing;

[0037] ForceZa function, used to define whether the signature content is ZA mixed hashed;

[0038] ZaUid function, used to provide a unique identifier for ZA calculation;

[0039] By providing signature parameters for different elliptic curve signature algorithms, the defined functions are used to obtain the parameters required in the signature and verification algorithms.

[0040] As a further description of the above technical solution:

[0041] The ECSignature elliptic curve signature structure is used to define the structure of the signature value and provide a general encoding and decoding method through a standard agreement.

[0042] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are:

[0043] In the present invention, by establishing a unified standard interface, the specific Weierstrass standard form elliptic curve signature algorithm is made transparent to the application, thereby reducing the code complexity of the application, improving the versatility and extensibility of the application code, reducing the learning cost of application developers, reducing the workload of application development and maintenance work, and helping to improve the interactivity of the application. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Figure 1 This is a schematic diagram of the overall structure of the EC standard interface of a digital signature method based on a unified standard interface proposed by the present invention;

[0045] Figure 2 The invention proposes a digital signature method based on a unified standard interface and a process of using a digital signature algorithm. DETAILED DESCRIPTION

[0046] The following will be combined with the drawings in the embodiments of the present invention to clearly and completely describe the technical solutions in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0047] See also Figure 1 and Figure 2 The present invention provides a technical solution: a digital signature method based on a unified standard interface, comprising:

[0048] Use object-oriented interface programming to configure the basic application components of the cryptographic algorithm library, and provide a universal and standardized EC standard interface for application programming;

[0049] The plurality of basic application components are programmed to be compatible with different signature algorithms through the EC standard interface to complete the configuration of the unified standard interface.

[0050] After the cryptographic algorithm library establishes the public and private keys, multiple basic object components sign or verify signatures through compatible EC standard interfaces.

[0051] Among them, digital signature is a concept similar to traditional handwritten physical signature, but it is impossible to use handwritten signature in the information field, so people use encryption technology to achieve it and verify the validity of digital information. The digital signature is a string of numbers generated by the sender of the information, that is, the application in the embodiment of the present application. This string of numbers cannot be forged by others and is also a valid proof of the authenticity of the information. A set of digital signatures usually defines two complementary operations, one for signing and the other for verifying the signature;

[0052] The EC standard interface includes:

[0053] EcSigner elliptic curve signature interface, used to obtain the public key corresponding to EcSigner and then digitally sign the signature subject;

[0054] Among them, the interface provides two functions and implements them on the private key of the elliptic curve:

[0055] Public function and Sign function;

[0056] Furthermore, if a certain algorithm library already has a similar signature interface, the existing interface can be inherited or directly used to improve compatibility with the algorithm library.

[0057] Furthermore, the Public function is used to obtain the public key corresponding to EcSigner. The interface definition is as follows:

[0058] Public()EcVerifier

[0059] Among them, the embodiment of the present application uses the golang language to illustrate the specific definition of the EC standard interface, but the design is universal and can also be replaced with other languages, which should not be regarded as a limitation on the embodiment of the present application;

[0060] The return value type EcVerifier is an interface defined for the public key. For details, see the public key interface defined in the EcVerifier elliptic curve signature verification interface.

[0061] The Sign function is used to digitally sign the signature subject. The interface definition is as follows:

[0062] Sign(randio.Reader,digest[]byte,optsSignerOpts)(signature[]byte,errerror)

[0063] The Sign function is described as follows:

[0064] Input parameter rand: random number generator. It is recommended to use a cryptographically secure random number generator, such as the random number generator based on the / dev / urandom system entropy value on Linux;

[0065] Input parameter digest: signature body, that is, signature content, type is byte array. Whether to do hashing in advance depends on the specific algorithm. Generally speaking, in order to avoid the signature being too long, ECDSA needs to hash the signature content in advance, while SM2 decides whether to do ZA hashing inside the signature algorithm based on the parameter configuration in the input parameter opts, so hashing does not need to be done in advance. The encoding method (such as character set) of converting the signature body from other structures (such as text strings) to byte arrays adopts the default method of each language, and the signature and verification can be kept consistent.

[0066] Hashing is a technique for converting input into a fixed-size string or numeric value, which is usually used to quickly access data or verify the integrity of data. In computer science, a hash function maps input to a hash value, which is usually a smaller number that is a "fingerprint" of the original data.

[0067] Input parameter opts: elliptic curve signature parameters, generated by the subsequent EcSignerOpts elliptic curve signature parameter interface.

[0068] Return value: When the signature is successful, the signature value and an empty error are returned. The signature value signature is a byte array, and it is agreed here that the ASN1 standard is used for encoding. If an error or exception occurs, an empty signature value and error information are returned.

[0069] Error is a feature of golang. Other languages ​​also have similar features, so I won’t go into details.

[0070] EcVerifier elliptic curve signature verification interface, used to provide a signature verification function and perform signature verification on the public key of the elliptic curve;

[0071] The interface provides a signature verification function Verify and implements it on the public key of the elliptic curve. The interface definition is as follows:

[0072] typeEcVerifierinterface{

[0073] Verify(digest[]byte, sig[]byte, optsEcSignerOpts)(bool, error)

[0074] }

[0075] The Verify function is described as follows:

[0076] Input parameter digest: signature body, that is, signature content, type is byte array. Make sure it is consistent with the input parameter digest during signing, such as whether it is hashed in advance, whether the hash algorithm is the same, whether the encoding method is consistent, etc.

[0077] Input parameter sig: signature value. Note that the Verify function should use the same encoding standard as the Sign function, i.e. ASN1, for decoding.

[0078] Input parameter opts: elliptic curve signature parameters, which are described in the subsequent section EcSignerOpts elliptic curve signature parameter interface.

[0079] Return value: Returns true and an empty error if the signature verification succeeds; returns false and the error reason through error if the signature verification fails; returns false and error information if an error or exception occurs;

[0080] EcSignerOpts elliptic curve signature parameter interface, used to provide signature parameters for different elliptic curve signature algorithms;

[0081] The following functions are provided to provide signature parameters for different elliptic curve signature algorithms:

[0082] HashFunc function

[0083] NeedLowS function

[0084] ForceZa function

[0085] ZaUid Function

[0086] The functions defined by this interface are used to obtain some parameters required in the signature and verification algorithms. For example, the HashFunc function is used to obtain a hash function used in the signature and verification algorithms.

[0087] This interface is implemented on a signature parameter structure or signature parameter class and is used as the input parameter opts of the signature and verification interface.

[0088] Different implementations of the Weierstrass standard form elliptic curve signature algorithm may require additional parameters. In this case, you can inherit or extend the EcSignerOpts interface and add the corresponding acquisition function of the required parameters.

[0089] The HashFunc function is used to obtain a specific hash function or hash instance, which is used within the signature / verification algorithm and is defined as follows:

[0090] HashFunc()Hash

[0091] The return value Hash type has corresponding definitions in different algorithm libraries in different languages ​​and does not need to be customized.

[0092] The Hash type will have a null value (or zero value). When this value is returned, the signature and verification algorithms use the default hash algorithm internally. For example, ECDSA uses the SHA256 hash algorithm by default, and SM2 uses the SM3 hash algorithm by default.

[0093] NeedLowS function

[0094] The ECDSA signature is two integers (r, s), where the s value corresponds to an inverse s value on the curve, and the s and inverse s values ​​are symmetrical, one is a high value and the other is a low value. In the ECDSA signature verification logic, if the inverse s value is used, a valid signature (r, inverse s value) can also be created.

[0095] This feature may cause ECDSA signatures to be exploited by replay attacks and double-spending attacks, because attackers can use the same r value and inverse s value to forge different messages.

[0096] One way to solve this problem is to add low-s processing to the signature: after signing, determine whether the s value is a high value. If so, replace it with a low value (low-s). Then, during signature verification, it is necessary to additionally check whether the signature s value is a low value. This avoids the possibility of attackers using the inverse s value to forge messages.

[0097] The NeedLowS function is used to configure whether to perform low-s processing in the ECDSA signature and verification process. It is defined as follows:

[0098] NeedLowS()bool

[0099] ForceZa function

[0100] In the SM2 signature algorithm, you can choose whether to do ZA mixed hashing on the digest before signing. The Sm2ForceZA function is used to define whether to do ZA mixed hashing. The definition is as follows:

[0101] ForceZa()bool

[0102] ZaUid Function

[0103] In the SM2 signature algorithm, if you choose to perform ZA mixed hashing on the digest before signing, then when performing ZA mixed hashing, you need to provide a unique identifier for ZA calculation, which is defined as follows:

[0104] ZaUid()[]byte

[0105] This UID can use a custom default value or a random number generator. The following example uses the default value:

[0106] vardefaultUID=[]byte{0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38}

[0107] The ECSignature elliptic curve signature structure is used to define the signature value structure, as shown below:

[0108] typeECSignaturestruct{

[0109] R,S*big.Int

[0110] }

[0111] The R value and S value are two large integers generated by the signature algorithm. In actual use, two layers of encoding are often required:

[0112] First encode the signature value into a byte array;

[0113] If network transmission or storage is required, use Hex or Base64 to encode the byte array into a string to avoid information loss during transmission or storage;

[0114] The first step is encoding into a byte array. The EC standard interface agrees to use the ASN1 standard and provides a general encoding and decoding method for ECSignature:

[0115] The following is an example of the MarshalECSignature signature encoding method:

[0116] funcMarshalECSignature(r, s*big.Int)([]byte, error){

[0117] returnasn1.Marshal(ECSignature{r,s})

[0118] }

[0119] An example of the UnmarshalECSignature signature decoding method is as follows:

[0120] funcUnmarshalECSignature(raw[]byte)(*big.Int,*big.Int,error){ / / Unmarshalsig:=new(ECSignature)

[0121] _,err:=asn1.Unmarshal(raw,sig)

[0122] iferr!=nil{

[0123] returnnil,nil,fmt.Errorf("failedunmashallingsignature[%s]",err)

[0124] }

[0125] / / Validatesig

[0126] ifsig.R==nil{

[0127] returnnil,nil,errors.New("invalidsignature,Rmustbedifferent fromnil")

[0128] }

[0129] ifsig.S==nil{

[0130] returnnil,nil,errors.New("invalidsignature,Smustbedifferent fromnil")

[0131] }

[0132] ifsig.R.Sign()!=1{

[0133] returnnil,nil,errors.New("invalidsignature,Rmustbelarger thanzero")

[0134] }

[0135] ifsig.S.Sign()!=1{

[0136] returnnil,nil,errors.New("invalidsignature,Smustbelarger

[0137] thanzero")

[0138] }

[0139] returns sig.R, sig.S, nil

[0140] }

[0141] The digital signature algorithm is based on public key cryptography theory and requires a pair of public and private keys. The private key is used to sign and the public key is used to verify the signature.

[0142] For public and private keys based on elliptic curves, the public key is generated by the private key, so the structure definitions of public and private keys in various languages ​​are often as follows:

[0143] / / PublicKey public key structure

[0144] typePublicKeystruct{

[0145] elliptic.Curve / / Elliptic curve

[0146] X, Y*big.Int / / Public key coordinates

[0147] }

[0148] / / PrivateKey private key structure

[0149] typePrivateKeystruct{

[0150] PublicKey / / Public key

[0151] D*big.Int / / private key, random number in the interval [1, n-1]

[0152] }

[0153] The private key is essentially a random number D, and the public key is the coordinates on the curve obtained by calculating the points on the elliptic curve based on the random number D. The structure of the private key will include the random number D and the corresponding public key. Mathematically, the private key cannot be reversed based on the public key, but the public key can be calculated based on the private key.

[0154] The structures of the public and private keys PublicKey and PrivateKey have been defined in the cryptographic algorithm libraries of various languages, so the EC standard interface can directly implement the signing and verification methods on these structures (structures or classes);

[0155] Example 2

[0156] See also Figure 2 , when the cryptographic algorithm library implements the EC standard interface, the process of using the digital signature algorithm by the application is as follows:

[0157] 1. GenerateKey creates public and private keys based on the signature algorithm and curve. GenerateKey is provided by the cryptographic algorithm library. This is a simple factory that supports Weierstrass standard form elliptic curves such as ECDSA and SM2.

[0158] 2. Prepare the signature content, encode it into a byte array, and optionally: hash it. The signature body received by the EC standard interface is a byte array, and each language provides a method to convert a text string or other structure into a byte array;

[0159] In addition, depending on the specific signature algorithm, you can choose whether to perform hashing. For example, in the case of the ECDSA algorithm cryptographic library, the signature content should be hashed before signing to avoid the signature being too long;

[0160] In the case of the SM2 algorithm cryptographic library, you can choose to do ZA hashing internally. In this case, you can choose not to hash the signature content before signing.

[0161] 3. Define signature parameters and use the cryptographic algorithm library to implement a structure or class of the EcSignerOpts interface, which has four attributes by default.

[0162] Hasher: The hash algorithm used internally by the signature and verification algorithms;

[0163] LowS: Whether to enable low-s processing for ECDSA signature and verification;

[0164] ForceZA: Whether SM2 signature and verification should perform ZA hashing on the signature content;

[0165] UID: Unique identifier for ZA calculation used when SM2 signature and verification are selected for ZA hashing.

[0166] 4.PrivateKey.Sign uses a private key to sign. After the EC standard interface is implemented, the returned sign signature value is an ASN1-encoded byte array.

[0167] 5. Encode sign to get signStr, and transmit it to application-2 together with digest and PublicKey. In the process of network transmission and storage, in order to avoid data being misinterpreted or damaged during transmission and to ensure the integrity and readability of data, Hex or Base64 encoding methods are often used to encode byte arrays.

[0168] 6. Decode signStr. Note that the same encoding method is used as in step 5.

[0169] 7. Define the signature parameters, making sure they are consistent with the parameters created in step 3 of Application-1.

[0170] 8.PublickKey.Verify uses the public key to verify the signature.

[0171] In the above process, the EC standard interface Sign and Verify interfaces are used for signing and verification, and EcSignerOpts is used as the signature and verification parameters. The signature value is the ASN1 encoding result of ECSignature. These calling codes for the cryptographic algorithm library can realize the above functions for all Weierstrass standard form elliptic curves, thus achieving compatibility with ECDSA and SM2 cryptographic algorithm libraries;

[0172] The simulation code for the above process is as follows:

[0173] / / ----------Simulation application-1 processing----------

[0174] / / 1.GenerateKey creates public and private keys based on the signature algorithm and curve

[0175] privateKey, err:=GenerateKey(alg.ECDSA, elliptic.P256(), rand.Reader)

[0176] / / 2. Prepare signature content, encoded as byte array, optional: hash

[0177] msg:="This is a text that needs to be signed..."

[0178] / / Convert and hash the signature content into a byte array to get the signature body

[0179] digest:=sha256.Sum256([]byte(msg))

[0180] / / 3. Define signature parameters

[0181] / / EcSignerOptsStruct implements the interface EcSignerOpts

[0182] opts:=&EcSignerOptsStruct{

[0183] Hasher: 0, / / 0 represents the use of the default hash algorithm

[0184] LowS: true,

[0185] UID: defaultUID,

[0186] ForceZA: true,

[0187] }

[0188] / / 4.PrivateKey.Sign uses private key signature

[0189] sign, err: = privateKey.Sign(rand.Reader, digest[:], opts)

[0190] / / 5. Encode sign to get signStr, and transmit it to the application together with digest and PublicKey -2

[0191] / / Hex encode the signature

[0192] signStr:=hex.EncodeToString(sign)

[0193] fmt.Printf("signhex:%s\n",signStr)

[0194] / / Get the public key (simulate transmitting the public key to application-2)

[0195] pubKey, ok:=privateKey.Public()

[0196] / / ----------Simulation application-2 processing----------

[0197] / / Simulate receiving signStr, digest, and PublicKey.

[0198] / / If the digest is hashed, the plaintext before hashing should be transmitted here, and then the digest should be calculated again using the same hash algorithm. / / Because it is a simulation, the digest plaintext is not hashed again here, and the previously hashed digest is used directly

[0199] / / 6. Decode signStr

[0200] signAfterTransfer, err:=hex.DecodeString(signStr)

[0201] / / 7. Define signature parameters, keep them consistent with those created in step 3 of application-1

[0202] / / Because it is a simulation, the previously defined opts are used directly here

[0203] / / 8.PublickKey.Verify uses the public key to verify the signature

[0204] validated, err:=pubKey.Verify(digest[:], signAfterTransfer, opts).

[0205] Specific: Related terms explanation:

[0206] ECC Elliptic Curve Cryptography

[0207] ECC is Elliptic Curve Cryptography, which is a set of cryptographic theories mainly used in key negotiation, digital signature, asymmetric encryption and other scenarios. Based on the elliptic curve, cryptographically secure public and private key pairs can be generated, that is, it is almost impossible to reverse the private key from the public key.

[0208] By using public-private key pairs, cryptographically secure key negotiation, digital signatures, asymmetric encryption and other algorithms can be implemented.

[0209] For example, digital signature is a private key signature and public key signature verification

[0210] Weierstrass standard form elliptic curve

[0211] An elliptic curve is a set of points defined by y^2=x^3+ax+b and satisfying the formula 4a^3+27b^2! = 0. These points are connected to form an elliptic curve.

[0212] y^2=x^3+ax+b is called the Weierstrass Curve, and the restriction of 4a^3+27b^2!=0 is to ensure that the curve does not contain singularities.

[0213] In addition to the Weierstrass curve, there are actually other types of elliptic curves, such as the Montgomery Curve, the Twisted Edwards Curve, etc. Their equations are different from those of the Weierstrass curve, but mathematically they can all be written in the Weierstrass standard form. When certain conditions are met, the Weierstrass standard form can be converted to these special elliptic curve forms.

[0214] The public and private key generation algorithms and digital signature algorithms of these special elliptic curves are different from the corresponding algorithms of the Weierstrass standard form elliptic curve. The EC standard interface is only designed for the Weierstrass standard form elliptic curve, and does not include special forms of elliptic curves such as Montgomery Curve and Twisted Edwards Curve;

[0215] In the Weierstrass standard form of elliptic curve, an elliptic curve is a set of points defined by y^2=x^3+ax+b and satisfying the formula 4a^3+27b^2!=0. These points are connected to form an elliptic curve.

[0216] y^2=x^3+ax+b is called the Weierstrass Curve, and the restriction of 4a^3+27b^2!=0 is to ensure that the curve does not contain singularities.

[0217] In addition to the Weierstrass curve, there are actually other types of elliptic curves, such as the Montgomery Curve, the Twisted Edwards Curve, etc. Their equations are different from those of the Weierstrass curve, but mathematically they can all be written in the Weierstrass standard form. When certain conditions are met, the Weierstrass standard form can be converted to these special elliptic curve forms.

[0218] The public and private key generation algorithms and digital signature algorithms of these special elliptic curves are different from the corresponding algorithms of the Weierstrass standard form elliptic curve. The EC standard interface is only designed for the Weierstrass standard form elliptic curve, and does not include special forms of elliptic curves such as Montgomery Curve and Twisted Edwards Curve.

[0219] In the present invention, the terms "first" and "second" are used for descriptive purposes only and should not be understood as indicating or implying relative importance; the term "plurality" refers to two or more, unless otherwise clearly defined. The terms "installed", "connected", "connected", "fixed" and the like should be understood in a broad sense. For example, "connected" can be a fixed connection, a detachable connection, or an integral connection; "connected" can be a direct connection or an indirect connection through an intermediate medium. For those of ordinary skill in the art, the specific meanings of the above terms in the present invention can be understood according to specific circumstances.

[0220] The above description is only a preferred specific implementation manner of the present invention, but the protection scope of the present invention is not limited thereto. Any technician familiar with the technical field can make equivalent replacements or changes according to the technical scheme and inventive concept of the present invention within the technical scope disclosed by the present invention, which should be covered by the protection scope of the present invention.

Claims

1. A digital signature method based on a unified standard interface, characterized in that: include: Configure cryptographic algorithm libraries and basic application components, and provide universal and standardized EC standard interfaces for application programming; The plurality of basic application components are programmed to be compatible with different signature algorithms through the EC standard interface to complete the configuration of the unified standard interface; After the cryptographic algorithm library establishes the public and private keys, multiple basic object components sign or verify signatures through compatible EC standard interfaces.

2. According to claim 1, a digital signature method based on a unified standard interface is characterized in that: The EC standard interface includes: EcSigner elliptic curve signature interface, used to obtain the public key corresponding to EcSigner and then digitally sign the signature subject; EcVerifier elliptic curve signature verification interface, used to provide a signature verification function and perform signature verification on the public key of the elliptic curve; EcSignerOpts elliptic curve signature parameter interface, used to provide signature parameters for different elliptic curve signature algorithms; ECSignature elliptic curve signature structure, used to define the signature value structure.

3. A digital signature method based on a unified standard interface according to claim 2, characterized in that: The specific steps for an application to perform signature verification through a compatible EC standard interface include: The first application configured with the EC standard interface calls the GenerateKey function of the cryptographic algorithm library to create public and private keys, and the cryptographic algorithm library creates the public and private keys and returns them to the first application; The first application EcSigner elliptic curve signature interface prepares the signature body; The first application defines signature parameters and provides signature parameters and signature verification parameters through the EcSignerOpts elliptic curve signature parameter interface; Through private key signing, the cryptographic algorithm library uses the private key to sign and returns the sign signature value to the first application; The first application encodes the returned private key sign signature value through the ECSignature elliptic curve signature structure to obtain signStr, and transmits signStr, the digest signature body and the PublicKey public key to the second application; The second application configured with the EC standard interface decodes signStr through the ECSignature elliptic curve signature structure; The second application defines the signature parameters of signStr transmitted by the first application through the signature parameters and signature verification parameters provided by the EcSignerOpts elliptic curve signature parameter interface; PublickKey.Verify uses the public key and cryptographic algorithm library to verify the signStr issued by the first application to complete the signature verification.

4. A digital signature method based on a unified standard interface according to claim 3, characterized in that: The EcSigner elliptic curve signature interface includes a Public function for obtaining the public key corresponding to the EcSigner and a Sign function for digitally signing the signature subject.

5. A digital signature method based on a unified standard interface according to claim 4, characterized in that: The signature body is the signature content, the type of which is a byte array, and also includes whether to perform hash processing on the signature content based on the parameter configuration of the specific algorithm.

6. A digital signature method based on a unified standard interface according to claim 1, characterized in that: The EcVerifier elliptic curve signature verification interface includes a signature verification function Verify, and performs signature verification through the public key of the elliptic curve.

7. A digital signature method based on a unified standard interface according to claim 1, characterized in that: The EcSignerOpts elliptic curve signature parameter interface includes: HashFunc function, used to obtain a specific hash function or hash instance, used within the signing / verification algorithm; NeedLowS function is used to configure whether to perform low-s processing in ECDSA signature and verification processing; ForceZa function, used to define whether the signature content is ZA mixed hashed; ZaUid function, used to provide a unique identifier for ZA calculation; By providing signature parameters for different elliptic curve signature algorithms, the defined functions are used to obtain the parameters required in the signature and verification algorithms.

8. A digital signature method based on a unified standard interface according to claim 1, characterized in that: The ECSignature elliptic curve signature structure is used to define the structure of the signature value and provide a general encoding and decoding method through a standard agreement.