CN115695003A - Key exchange method, system, electronic device and storage medium - Google Patents
Key exchange method, system, electronic device and storage medium Download PDFInfo
- Publication number
- CN115695003A CN115695003A CN202211353419.6A CN202211353419A CN115695003A CN 115695003 A CN115695003 A CN 115695003A CN 202211353419 A CN202211353419 A CN 202211353419A CN 115695003 A CN115695003 A CN 115695003A
- Authority
- CN
- China
- Prior art keywords
- key
- parameter
- curve
- exchange method
- client
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Abstract
The application relates to a key exchange method, a system, an electronic device and a storage medium. The method comprises the following steps: receiving a ClientHello message sent by a client, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and a public key parameter in a key negotiation parameter corresponding to the target curve; forming a premaster secret key based on the random number; encrypting the premaster secret key based on the public key parameter and the target curve to obtain a premaster secret key ciphertext; feeding back a ServerHello message to the client, wherein the ServerHello message contains a pre-master key ciphertext; and the client decrypts the pre-master key ciphertext by using the private key parameter in the key negotiation parameter to obtain the pre-master key plaintext. The scheme provided by the application can support the national secret algorithm, the pre-master key is obtained through efficient negotiation under the condition that the safety is guaranteed, and the complexity of key exchange is reduced.
Description
Technical Field
The present application relates to the field of network security technologies, and in particular, to a method, a system, an electronic device, and a storage medium for exchanging a key.
Background
The cryptographic algorithm is a commercial cryptographic algorithm commonly used in our country, and includes SM2, SM3, and SM4 algorithms. The SM2 is an asymmetric encryption algorithm based on an elliptic curve, the SM3 is a data summarization algorithm, and the SM4 is a symmetric block encryption algorithm with 16 bytes as a group. The disclosure of the national cryptographic algorithm provides the standard of safe application for the commercial cryptographic algorithm of China.
The secure transport layer protocol TLS is a widely used security protocol on the internet to provide privacy and data integrity between two communicating applications, and is the standard for transport layer security. The secure transport layer protocol has two layers, which are the TLS recording protocol and the TLS handshake protocol. TLS1.3 is one of the secure transport layer protocols, which is updated based on the earlier TLS1.2, and the differences from TLS1.2 include: the authentication mechanism and key exchange mechanism of TLS1.3 have been separated from the key suite, etc.
The complete protocol for TLS1.3 is defined in RFC8446, and a key share extension is used in a complete TLS1.3 handshake to calculate a shared key, but RFC8446 does not define how to calculate a shared key based on a cryptographic algorithm. Whereas RFC8998 defines a method for TLS1.3 handshake negotiation based on the national cryptographic algorithm, it still uses the key negotiation algorithm ECDHE to calculate a shared key, and does not use the national cryptographic algorithm to calculate the shared key. In the prior art, the shared key is calculated by modifying the structure of the KeyShare extension and using the algorithm of the key exchange protocol defined by the national cryptographic algorithm, two pairs of temporary key pairs need to be generated at the client and the server respectively, and the implementation is complicated.
In view of the above, it is desirable to provide a TLS1.3 key exchange method supporting the cryptographic algorithm, which reduces the complexity of key exchange while ensuring security.
Disclosure of Invention
In order to overcome the problems in the related art, the application provides a key exchange method, a system, an electronic device and a storage medium, wherein the key exchange method can support a national cryptographic algorithm, efficiently negotiate to obtain a premaster secret key under the condition of ensuring the security, and reduce the complexity of key exchange.
A first aspect of the present application provides a key exchange method, including:
receiving a ClientHello message sent by a client, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and a public key parameter in a key negotiation parameter corresponding to the target curve;
forming a premaster secret key based on the random number;
encrypting the premaster secret key based on the public key parameter and the target curve to obtain a premaster secret key ciphertext;
and feeding back a ServerHello message to the client, wherein the ServerHello message comprises a pre-master key ciphertext.
In one embodiment, the target curve is a SM2 elliptic curve;
encrypting the premaster secret key based on the public key parameter and the target curve comprises:
encrypting the pre-master key by using a public key parameter through an SM2 elliptic curve public key encryption algorithm;
the SM2 elliptic curve public key encryption algorithm is an encryption algorithm taking an SM2 elliptic curve as an algorithm structure.
In one embodiment, constructing the premaster secret based on the random number includes:
the premaster secret is constructed based on a 48 byte random number.
A second aspect of the present application provides a key exchange method, including:
determining a key negotiation parameter corresponding to at least one curve based on the at least one curve in the support curve list; the support curve list comprises a target curve matched with the national cryptographic algorithm; the at least one key negotiation parameter comprises a public key parameter and a private key parameter;
generating a ClientHello message based on the support curve list and a public key parameter in at least one key negotiation parameter;
sending the ClientHello message to a server;
receiving a premaster secret key ciphertext fed back by the server;
and decrypting the pre-master key ciphertext based on the private key parameter to obtain a pre-master key plaintext.
In one embodiment, generating the ClientHello message based on the support curve list and a public key parameter of the at least one key agreement parameter includes:
forming an extension type identifier and extension type information based on a support curve list and a public key parameter in at least one key negotiation parameter;
and generating the ClientHello message based on the extension type identification and the extension type information.
In one embodiment, determining a key agreement parameter corresponding to at least one curve based on at least one curve in the list of supported curves, wherein determining the key agreement parameter corresponding to the target curve comprises:
determining a base point on the target curve;
setting parameters of a private key;
and determining the public key parameters according to the base points and the private key parameters.
A third aspect of the present application provides a key exchange system, including: a server and a client;
the server is used for executing the key exchange method according to any one of the first aspect;
the client is configured to perform the key exchange method according to any one of the second aspect.
A fourth aspect of the present application provides an electronic device, comprising a processor and a memory storing a computer program, wherein the processor implements the steps of the key exchange method according to any one of the first aspect or the second aspect when executing the computer program.
A fifth aspect of the present application provides a non-transitory machine-readable storage medium having stored thereon executable code that, when executed by a processor of an electronic device, performs the steps of the key exchange method of any one of the first aspects or the steps of the key exchange method of any one of the second aspects.
The technical scheme provided by the application can comprise the following beneficial effects:
the server receives a ClientHello message sent by the client, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and public key parameters in key negotiation parameters corresponding to the target curve, the server further forms a pre-master key on the basis of random numbers, and encrypts the pre-master key on the basis of the public key parameters and the target curve to obtain a pre-master key ciphertext. The server side feeds back a ServerHello message containing the pre-master key ciphertext to the client side, when the client side receives the ServerHello message, the client side decrypts the pre-master key ciphertext based on the private key parameter, so that the plaintext of the pre-master key can be efficiently obtained through negotiation, the support of a national cryptographic algorithm can be increased without modifying a KeyShare expanded structure and generating two pairs of temporary key pairs at the client side and the server side, and the complexity of key exchange is reduced under the condition of ensuring the security.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the application.
Drawings
The above and other objects, features and advantages of exemplary embodiments of the present application will become readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings. In the drawings, several embodiments of the present application are illustrated by way of example and not by way of limitation, and like or corresponding reference numerals indicate like or corresponding parts.
Fig. 1 is a schematic flowchart of a key exchange method according to an embodiment of the present application;
fig. 2 is another schematic flow chart of a key exchange method according to an embodiment of the present application;
fig. 3 is a schematic structural diagram of a key exchange system according to an embodiment of the present application;
fig. 4 is a schematic structural diagram of an electronic device shown in an embodiment of the present application.
Detailed Description
Embodiments will now be described with reference to the accompanying drawings. It will be appreciated that for simplicity and clarity of illustration, where considered appropriate, reference numerals may be repeated among the figures to indicate corresponding or analogous elements. In addition, this application sets forth numerous specific details in order to provide a thorough understanding of the embodiments described herein. However, it will be understood by those of ordinary skill in the art that the embodiments described herein may be practiced without these specific details. In other instances, well-known methods, procedures, and components have not been described in detail so as not to obscure the embodiments described herein. Moreover, this description is not to be taken as limiting the scope of the embodiments described herein.
The complete protocol for TLS1.3 is defined in RFC8446, and a key share extension is used in a complete TLS1.3 handshake to calculate a shared key, but RFC8446 does not define how to calculate a shared key based on a cryptographic algorithm. Whereas RFC8998 defines a method for TLS1.3 handshake negotiation based on the national cryptographic algorithm, it still uses the key negotiation algorithm ECDHE to calculate a shared key, and does not use the national cryptographic algorithm to calculate the shared key. In the prior art, by modifying the structure of the KeyShare extension and using the algorithm of the key exchange protocol defined by the cryptographic algorithm to calculate the shared key, two pairs of temporary key pairs need to be generated at the client and the server respectively, which is complicated to implement. In view of the above, it is desirable to provide a TLS1.3 key exchange method supporting cryptographic algorithm, which reduces the complexity of key exchange while ensuring security.
In view of the above problems, embodiments of the present application provide a key exchange method, which can support a cryptographic algorithm, efficiently negotiate to obtain a premaster secret key while ensuring security, and reduce complexity of key exchange.
The technical solutions of the embodiments of the present application are described in detail below with reference to the accompanying drawings.
Fig. 1 is a flowchart of a key exchange method shown in an embodiment of the present application, which is used to illustrate execution steps of a server. Referring to fig. 1, a key exchange method according to an embodiment of the present application may include:
in step 101, a ClientHello message sent by a client is received.
The ClientHello message is a message sent by the client to the server in the TLS1.3 handshake protocol to initiate a handshake request. The ClientHello message comprises a target curve matched with a national cryptographic algorithm and public key parameters in key negotiation parameters corresponding to the target curve. In the embodiment of the present application, the target curve matched with the cryptographic algorithm is an SM2 elliptic curve, and the SM2 elliptic curve public key encryption algorithm is an encryption algorithm using the SM2 elliptic curve as an algorithm structure, so that the key exchange method shown in the embodiment of the present application can support the SM2 elliptic curve public key encryption algorithm. SM2 is an asymmetric encryption algorithm based on an elliptic curve in the cryptographic algorithm.
In step 102, a premaster secret is constructed based on the random number.
In the embodiment of the present application, the random number may be a 48-byte random number, and in practical applications, the random number is determined according to practical application situations, and is not limited herein.
For example, the data structure of the premaster secret may be as follows:
struct{
opaque random[48]；
}PreMasterSecret；
wherein random is a random number, and PreMasterSecret is a premaster secret.
In step 103, the premaster secret is encrypted based on the public key parameters and the target profile.
In the embodiment of the application, the pre-master key is encrypted by using the public key parameter through an SM2 elliptic curve public key encryption algorithm to obtain a pre-master key ciphertext. For example, with the SM2 elliptic curve public key encryption algorithm, the encryption structure for performing encryption operation on the premaster secret key by using the public key parameter may be as follows:
struct{
opaque SM2EncryptedPreMasterSecret<0..2^16-1>；
}SM2CipherEntry；
the SM2EncryptedPreMasterSecret represents a premaster secret key ciphertext obtained by encrypting a premaster secret key by using a public key parameter through an SM2 elliptic curve public key encryption algorithm, and the SM2CipherEntry represents the encryption structure.
Asn.1 of the SM2 algorithm encrypted data format is defined as follows:
wherein asn.1 is Abstract Syntax Notation 1 (asn.1), which is a standard for defining Abstract data type form and depicts a general data structure.
For details of the SM2 encryption algorithm, reference is made to GB/T32918.4-2016 information security technology SM2 elliptic curve public key cryptographic algorithm: public key encryption algorithm.
In step 104, a ServerHello message is fed back to the client, where the ServerHello message includes the premaster secret.
In this embodiment of the present application, the "extension _ data" field of the extension whose "extension _ type" field of the ServerHello message is "key _ share" type contains a KeyShareServerHello value, and when a curve selected by the server from the client _ shares in the ClientHello message is a target curve, that is, a public key parameter corresponding to an SM2 elliptic curve, an exemplary custom structure of the KeyShareServerHello may be as follows:
struct{
SM2CipherEntry server_share<1..2^16-1>；
}KeyShareServerHello；
fig. 2 is a flowchart of a key exchange method shown in this embodiment, which is used to explain execution steps of a client. Referring to fig. 2, a key exchange method according to an embodiment of the present disclosure may include:
in step 201, a key agreement parameter corresponding to at least one curve is determined based on the at least one curve in the list of support curves.
The curve described in the embodiment of the present application is generally an elliptic curve, because TLS1.3 adopts ECDHE to calculate a shared key, which is elliptic curve diffie-hellman key exchange, under this agreement, two interacting parties establish a secure common encrypted data in an insecure channel by using a public key and a private key established by elliptic curve encryption through the diffie-hellman key exchange algorithm. Therefore, the support curve list is an elliptic curve carrying support key exchange, and particularly in the embodiment of the present application, the support curve list includes a target curve matched with the cryptographic algorithm, i.e. an SM2 elliptic curve.
At least one key agreement parameter includes a public key parameter and a private key parameter, taking the key agreement parameter corresponding to the target curve, that is, the SM2 elliptic curve as an example, a point may be selected on the SM2 elliptic curve as a base point, which is denoted by a symbol G, then the client autonomously sets a private key parameter, which is denoted by a symbol k, and then determines the public key parameter according to the base point G and the private key parameter k, which is denoted by a symbol P, where P = kG. It will be appreciated that in an elliptic curve, given k and G, it is easy to calculate P according to the additive rule, but it is difficult to calculate k given P and G.
In step 202, a ClientHello message is generated based on the list of support curves and a public key parameter of the at least one key agreement parameter.
In the embodiment of the application, an extension type identifier and extension type information are first formed based on a support curve list and a public Key parameter in at least one Key negotiation parameter, where the extension type identifier includes a Supported groups extension and a Key Share extension.
The Supported groups extension is a named group of elliptic curves supporting key exchange in the client, and is arranged from a most-preferred elliptic curve to a least-preferred elliptic curve, and the 'extension _ data' field of the Supported groups extension contains a 'NamedGroupList' value, in the embodiment of the application, an SM2 elliptic curve and a parameter value 0x0029 thereof need to be added in the NamedGroupList. Illustratively, the structure of the Supported groups extension may be as follows:
wherein, SM2 Curve Groups is the SM2 elliptic Curve.
In addition, when the Key Share extension is used to carry at least one public Key parameter corresponding to a curve, the structure of the Key Share extension may be as follows:
wherein, group is a naming group of the used elliptic curve, and if the used elliptic curve is SM2 elliptic curve, the naming group uses parameter value 0x0029; key _ exchange represents a Key exchange message, whose field contents are determined by a specified named group and its corresponding definition.
Further, the "extension _ data" field in the Key Share extension contains a "keysharecliengthello" value, and in the embodiment of the present application, the field structure of keysharecliengthello may be as follows:
struct{
KeyShareEntry client_shares<1..2^16-1>；
}KeyShareClientHello；
where client _ shares is a list of KeyShareEntry values provided in descending order of client preference, each KeyShareEntry value must correspond to each named group provided in the Supported groups extension and need to be presented in the same order to achieve a one-to-one correspondence effect, but these KeyShareEntry values may be non-contiguous subsets of the Supported groups extension. The client may provide any number of KeyShareEntry values to form a list of KeyShareEntry values, each representing a set of key exchange parameters, i.e., understandable as public key parameters. The key _ exchange value in each KeyShareEntry value must be generated independently and the client must not provide multiple KeyShareEntry values for the same named group. In the embodiment of the present application, the client _ shares, that is, the list of KeyShareEntry values, must include the KeyShareEntry value corresponding to the SM2 elliptic curve, that is, the public key parameter corresponding to the SM2 elliptic curve.
It is understood that the extension type information may include, but is not limited to, the "extension _ data" field of the Supported groups extension and the "extension _ data" field of the Key Share extension, and further, a ClientHello message is generated based on the extension type identifier and the extension type information, where the extension structure in the ClientHello message is composed of the extension type identifier and the extension type information, and the extension structure of the ClientHello message may be as follows:
the extension _ type is an extension type identifier, and the extension _ data is extension type information.
In step 203, the ClientHello message is sent to the server.
In step 204, the premaster secret key ciphertext fed back by the server is received.
In step 205, the premaster key ciphertext is decrypted based on the private key parameter.
The pre-master key ciphertext is decrypted through the private key parameter to obtain the plaintext of the pre-master key, so that the pre-master key, namely the shared key, can be obtained through negotiation, and the pre-master key is a calculation source of the master key.
And receiving a ClientHello message sent by the client through the server, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and public key parameters in key negotiation parameters corresponding to the target curve, further forming a pre-master key by the server on the basis of random numbers, and encrypting the pre-master key on the basis of the public key parameters and the target curve to obtain a pre-master key ciphertext. The server side feeds back a ServerHello message containing the pre-master key ciphertext to the client side, when the client side receives the ServerHello message, the client side decrypts the pre-master key ciphertext based on the private key parameter, so that the plaintext of the pre-master key can be efficiently obtained through negotiation, the support of a national cryptographic algorithm can be increased without modifying a KeyShare expanded structure and generating two pairs of temporary key pairs at the client side and the server side, and the complexity of key exchange is reduced under the condition of ensuring the security.
Corresponding to the embodiment of the application function implementation method, the application also provides a key exchange system and a corresponding embodiment.
Fig. 3 is a schematic structural diagram of a key exchange system according to an embodiment of the present application, and referring to fig. 3, the key exchange system according to the embodiment of the present application may include: a server 301 and a client 302.
Wherein the server 301 is configured to: receiving a ClientHello message sent by a client, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and a public key parameter in a key negotiation parameter corresponding to the target curve; forming a premaster secret key based on the random number; encrypting the premaster secret key based on the public key parameter and the target curve to obtain a premaster secret key ciphertext; and feeding back a ServerHello message to the client, wherein the ServerHello message comprises a pre-master key ciphertext.
In some embodiments, where the target curve is an SM2 elliptic curve, the server 301 may be configured to: encrypting the pre-master key by using a public key parameter through an SM2 elliptic curve public key encryption algorithm; the SM2 elliptic curve public key encryption algorithm is an encryption algorithm taking an SM2 elliptic curve as an algorithm structure.
In some embodiments, the server 301 may be configured to: the premaster secret is constructed based on a 48 byte random number.
Additionally, client 302 is configured to: determining a key negotiation parameter corresponding to at least one curve based on at least one curve in the support curve list; the support curve list comprises a target curve matched with the national cryptographic algorithm; at least one key negotiation parameter comprises a public key parameter and a private key parameter; generating a ClientHello message based on the support curve list and a public key parameter in at least one key negotiation parameter; sending the ClientHello message to a server; receiving a premaster secret key ciphertext fed back by the server; and decrypting the pre-master key ciphertext based on the private key parameter to obtain a pre-master key plaintext.
In some embodiments, client 302 may be configured to: forming an extension type identifier and extension type information based on a support curve list and a public key parameter in at least one key negotiation parameter; and generating the ClientHello message based on the extension type identifier and the extension type information.
In some embodiments, client 302 may be configured to: determining a base point on the target curve; setting parameters of a private key; and determining the public key parameters according to the base point and the private key parameters.
And receiving a ClientHello message sent by the client through the server, wherein the ClientHello message comprises a target curve matched with a national cryptographic algorithm and public key parameters in key negotiation parameters corresponding to the target curve, further forming a pre-master key by the server on the basis of random numbers, and encrypting the pre-master key on the basis of the public key parameters and the target curve to obtain a pre-master key ciphertext. The server side feeds back a ServerHello message containing the pre-master key ciphertext to the client side, when the client side receives the ServerHello message, the client side decrypts the pre-master key ciphertext based on the private key parameter, so that the plaintext of the pre-master key can be efficiently obtained through negotiation, the support of a national cryptographic algorithm can be increased without modifying a KeyShare expanded structure and generating two pairs of temporary key pairs at the client side and the server side, and the complexity of key exchange is reduced under the condition of ensuring the security.
With regard to the system in the above embodiment, the specific manner in which the server and the client perform the operations has been described in detail in the embodiment related to the method, and will not be elaborated here.
Corresponding to the foregoing embodiment of the application function implementation method, the present application further provides an electronic device executing the key exchange method and a corresponding embodiment.
Fig. 4 shows a block diagram of a hardware configuration of an electronic device 800 that can implement the key exchange method of the embodiment of the present application. As shown in fig. 4, electronic device 800 may include a processor 810 and a memory 820. In the electronic device 800 of fig. 4, only constituent elements related to the present embodiment are shown. Thus, it will be apparent to one of ordinary skill in the art that: the electronic device 800 may also include common constituent elements that are different from those shown in fig. 4, such as: fixed-point arithmetic units, etc.
The electronic device 800 may correspond to a computing device having various processing functions, such as functions for generating a neural network, training or learning a neural network, quantizing a floating-point neural network to a fixed-point neural network, or retraining a neural network. For example, the electronic device 800 may be implemented as various types of devices, such as a Personal Computer (PC), a server device, a mobile device, and so on.
The processor 810 controls all functions of the electronic device 800. For example, the processor 810 controls all functions of the electronic device 800 by executing programs stored in the memory 820 on the electronic device 800. The processor 810 may be implemented by a Central Processing Unit (CPU), a Graphics Processing Unit (GPU), an Application Processor (AP), an artificial intelligence processor chip (IPU), etc., provided in the electronic device 800. However, the present application is not limited thereto.
In some embodiments, processor 810 may include an input/output (I/O) unit 811 and a computing unit 812. The I/O unit 811 may be used to receive various data, such as a ClientHello message sent by a client that a server receives. For example, the computing unit 812 may be configured to encrypt the pre-master key using the public key parameters in the ClientHello message received via the I/O unit 811 to determine a pre-master key ciphertext. This premaster key ciphertext may be output by the I/O unit 811, for example. The output data may be provided to memory 820 for reading by other devices (not shown), such as a device of the client, or may be provided directly to other devices, such as a device of the client.
The memory 820 is hardware for storing various data processed in the electronic device 800. For example, the memory 820 may store processed data and data to be processed in the electronic device 800. Memory 820 may store data involved in the key exchange methodology that processor 810 has processed or is to process. Further, the memory 820 may store applications, drivers, and the like to be driven by the electronic device 800. For example: the memory 820 may store various programs related to a key exchange method to be executed by the processor 810. The memory 820 may be a DRAM, but the present application is not limited thereto. The memory 820 may include at least one of volatile memory or nonvolatile memory. The non-volatile memory may include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), flash memory, phase change RAM (PRAM), magnetic RAM (MRAM), resistive RAM (RRAM), ferroelectric RAM (FRAM), and the like. Volatile memory can include Dynamic RAM (DRAM), static RAM (SRAM), synchronous DRAM (SDRAM), PRAM, MRAM, RRAM, ferroelectric RAM (FeRAM), and the like. In an embodiment, the memory 820 may include at least one of a Hard Disk Drive (HDD), a Solid State Drive (SSD), a high density flash memory (CF), a Secure Digital (SD) card, a Micro-amp digital (Micro-SD) card, a Mini secure digital (Mini-SD) card, an extreme digital (xD) card, a cache (caches), or a memory stick.
In summary, specific functions implemented by the memory 820 and the processor 810 of the electronic device 800 provided in the embodiments of the present disclosure may be explained in comparison with the foregoing embodiments in the present disclosure, and technical effects of the foregoing embodiments may be achieved, and are not described herein again.
In this embodiment, the processor 810 may be implemented in any suitable manner. For example, the processor 810 may take the form of, for example, a microprocessor or processor and a computer-readable medium that stores computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, an embedded microcontroller, and so forth.
It should be understood that the possible terms "first" or "second" etc. in the claims, description and drawings disclosed in this application are used for distinguishing between different objects and not for describing a particular order. The terms "comprises" and "comprising," when used in the specification and claims of this disclosure, specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof.
It is also to be understood that the terminology used in the description of the present disclosure herein is for the purpose of describing particular embodiments only, and is not intended to be limiting of the disclosure. As used in the specification and claims of this disclosure, the singular forms "a", "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should be further understood that the term "and/or" as used in the specification and claims of this disclosure refers to any and all possible combinations of one or more of the associated listed items and includes such combinations.
Although the embodiments of the present application are described above, the descriptions are only examples adopted for facilitating understanding of the present application, and are not intended to limit the scope and application scenarios of the present application. It will be understood by those skilled in the art that various changes in form and details may be made therein without departing from the spirit and scope of the disclosure as defined by the appended claims.
It should also be appreciated that any module, unit, component, server, computer, terminal, or device executing instructions exemplified herein may include or otherwise have access to a computer-readable medium, such as a storage medium, computer storage medium, or data storage device (removable) and/or non-removable), e.g., a magnetic disk, optical disk, or magnetic tape. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information, such as computer readable instructions, data structures, program modules or other data.
Claims (9)
1. A method of key exchange, comprising:
receiving a ClientHello message sent by a client, wherein the ClientHello message comprises a target curve matched with a national secret algorithm and a public key parameter in a key negotiation parameter corresponding to the target curve;
forming a premaster secret key based on the random number;
encrypting the pre-master key based on the public key parameters and the target curve to obtain a pre-master key ciphertext;
and feeding back a ServerHello message to the client, wherein the ServerHello message contains the pre-master key ciphertext.
2. The key exchange method of claim 1,
the target curve is an SM2 elliptic curve;
the encrypting the premaster secret key based on the public key parameter and the target curve comprises:
encrypting the pre-master key by using the public key parameter through an SM2 elliptic curve public key encryption algorithm;
the SM2 elliptic curve public key encryption algorithm is an encryption algorithm taking the SM2 elliptic curve as an algorithm structure.
3. The key exchange method of claim 1,
the forming of the premaster secret based on the random number comprises:
the premaster secret is constructed based on a 48 byte random number.
4. A method of key exchange, comprising:
determining a key negotiation parameter corresponding to at least one curve based on the at least one curve in the support curve list; wherein the support curve list comprises target curves matched with a cryptographic algorithm; the at least one key negotiation parameter comprises a public key parameter and a private key parameter;
generating a ClientHello message based on the support curve list and a public key parameter in at least one key negotiation parameter;
sending the ClientHello message to a server;
receiving a pre-master key ciphertext fed back by the server;
and decrypting the pre-master key ciphertext based on the private key parameter to obtain a pre-master key plaintext.
5. The key exchange method of claim 4,
generating a ClientHello message based on the support curve list and a public key parameter in at least one key negotiation parameter, including:
forming an extension type identifier and extension type information based on the support curve list and a public key parameter in at least one key negotiation parameter;
and generating the ClientHello message based on the extension type identification and the extension type information.
6. The key exchange method of claim 5,
determining a key agreement parameter corresponding to at least one curve based on at least one curve in the supporting curve list, wherein determining the key agreement parameter corresponding to the target curve comprises:
determining a base point on the target curve;
setting the private key parameters;
and determining a public key parameter according to the base point and the private key parameter.
7. A key exchange system, comprising: a server and a client;
the server is used for executing the key exchange method of any one of claims 1-3;
the client is configured to perform the key exchange method according to any one of claims 4 to 6.
8. An electronic device comprising a processor and a memory storing a computer program, characterized in that the processor implements the steps of the key exchange method of any one of claims 1 to 3, or the steps of the key exchange method of any one of claims 4 to 6, when executing the computer program.
9. A non-transitory machine-readable storage medium having stored thereon executable code that, when executed by a processor of an electronic device, performs the steps of the key exchange method of any one of claims 1 to 3, or performs the steps of the key exchange method of any one of claims 4 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353419.6A CN115695003A (en) | 2022-10-31 | 2022-10-31 | Key exchange method, system, electronic device and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202211353419.6A CN115695003A (en) | 2022-10-31 | 2022-10-31 | Key exchange method, system, electronic device and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN115695003A true CN115695003A (en) | 2023-02-03 |
Family
ID=85047449
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202211353419.6A Pending CN115695003A (en) | 2022-10-31 | 2022-10-31 | Key exchange method, system, electronic device and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115695003A (en) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116094714A (en) * | 2023-02-24 | 2023-05-09 | 浙江大华技术股份有限公司 | Code stream encryption and decryption methods, devices, equipment and media |
-
2022
- 2022-10-31 CN CN202211353419.6A patent/CN115695003A/en active Pending
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN116094714A (en) * | 2023-02-24 | 2023-05-09 | 浙江大华技术股份有限公司 | Code stream encryption and decryption methods, devices, equipment and media |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| WO2019174187A1 (en) | Blockchain-based method for message communication between multiple terminals, terminal and storage medium | |
| US10554636B2 (en) | Lightweight encrypted communication protocol | |
| US11706026B2 (en) | Location aware cryptography | |
| US10785019B2 (en) | Data transmission method and apparatus | |
| US9673977B1 (en) | Refreshing public parameters in lattice-based cryptographic protocols | |
| US11784801B2 (en) | Key management method and related device | |
| CN109800584B (en) | Identity or attribute encryption calculation method and system based on Intel SGX mechanism | |
| CN110419194B (en) | Key exchange apparatus and method | |
| EP2792100B1 (en) | Method and device for secure communications over a network using a hardware security engine | |
| CN110391900B (en) | Private key processing method based on SM2 algorithm, terminal and key center | |
| EP3590224B1 (en) | Elliptic curve isogeny based key agreement protocol | |
| CN111492616B (en) | Configurable device for lattice-based cryptography | |
| BR102019015369B1 (en) | systems and method for provisioning a secure connection to an inter-device connection | |
| CN110999203B (en) | Method and system for generating shared secret key | |
| US11599655B1 (en) | Data sharing method | |
| WO2020254177A1 (en) | Authenticated lattice-based key agreement or key encapsulation | |
| US10951652B1 (en) | Communication session resumption | |
| EP3624391A1 (en) | Public/private key system with decreased encrypted message size | |
| WO2021234580A1 (en) | Methods and systems for secure network communication | |
| CN113225371A (en) | Electric power Internet of things terminal control instruction encryption and decryption system and method | |
| Yousif et al. | Enhancing approach for information security in hadoop | |
| CN113726517A (en) | Information sharing method and device | |
| CN115695003A (en) | Key exchange method, system, electronic device and storage medium | |
| CN110572788B (en) | Wireless sensor communication method and system based on asymmetric key pool and implicit certificate | |
| US11108552B1 (en) | Data encryption method and system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |