CN106789087B

CN106789087B - Method and system for determining data digest of message and multi-party-based digital signature

Info

Publication number: CN106789087B
Application number: CN201710061691.XA
Authority: CN
Inventors: 张永强
Original assignee: Age Of Security Polytron Technologies Inc
Current assignee: Age Of Security Polytron Technologies Inc
Priority date: 2017-01-26
Filing date: 2017-01-26
Publication date: 2020-01-07
Anticipated expiration: 2037-01-26
Also published as: CN106789087A

Abstract

A method and system for determining a data digest of a message, a digital signature based on multi-party signatures, the method for determining the data digest of the message according to one embodiment includes: acquiring a message to be processed and state quantities of a hash function; initializing operation by adopting an initialization algorithm of the hash function according to the state quantity of the hash function, and initializing the context of the hash function operation; outputting the context of the hash function operation as a hash function state quantity; and executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the summary information of the message to be processed. In the embodiment, the context of hash function operation when the data abstract of the message is determined is output as the state quantity of the hash function, so that other parties or trusted third parties can construct a virtual file based on the state quantity of the hash function to complete the sequential signature process, the finally generated electronic contract file meets the format requirement of the PDF document on multi-party digital signatures, and the fairness of electronic contract signing of a plurality of signers is ensured.

Description

Method and system for determining data digest of message and multi-party-based digital signature

Technical Field

The present invention relates to the field of information security technologies, and in particular, to a method for determining a data digest of a message, a system for determining a data digest of a message, a digital signature method based on multi-party signatures, and a digital signature system based on multi-party signatures.

Background

Fairness is a fundamental principle in business activities. In a business where a contract is signed, a plurality of participants gather together and negotiate a common contract text, and after negotiation is completed, the contract is signed. Each valid contract contains the signatures of all participants to meet legal requirements regarding contract validity. If someone rejects the signatory, the problem can be found on the spot, disputes are solved, and fairness is guaranteed. In the network space, a participant of contract signing, e.g., Bob, may choose to terminate the signing of the contract at some point in time and to override network problems, such as network delay or network packet loss. Other participants cannot verify whether Bob is terminated intentionally or forced to terminate because of an irresistible network problem. This leads to unfairness: bob has the right to terminate the protocol arbitrarily relative to the other participants, which may cause him to be unduly profitable and impair the benefits of the other participants. For example, in a two-party contract signing scheme based on verifiable cryptographic signatures (VES), the participating party Alice sends Bob a VES message that Bob can use to prove to any third party that Alice sent himself a message about some contract text. Although at this point Bob does not get Alice's signature, and perhaps never, Alice's signature, this still means that at some point in time Alice has indeed considered a contract with Bob, or Alice made some commitment. On condition that Bob can negotiate with any third party, it is expected to obtain better benefits. To address these problems, one proposes "abuse-free" fair contract signing, requiring that the parties involved in contract signing cannot prove the behavior of contract signing to any third party using the communication script that signed the contract during contract signing.

Fair contract signing has many solutions and mature solutions, and both parties and parties have good theoretical results. However, in practical applications, there are many constraints, which make the conventional solution unusable. For example, practical applications are based on the following two constraints: (1) adopting a document in a PDF format as a carrier of a contract file; (2) a contract must contain digital signatures of all participants. Although the two requirements appear to be simple, they limit the solutions that can be used conventionally.

First, PDF documents support only RSA and DSA signatures, in other words, a protocol that can extract standard RSA or DSA signatures must be employed in constructing a fair exchange protocol. Verifiable cryptographic signatures (VES) are an extension of ordinary digital signatures, used as a basic module for designing fair exchange protocols. The VES scheme proposed by Atenise supports the extraction of standard RSA signature or DSA signature from VES, and the basic process is as follows:

1. let user Alice randomly select large prime numbers p ', q', construct p ═ 2p '+ 1, q ═ 2 q' +1, and generate n ═ pq. Alice selects the public key e > 2 and computes the private key d to satisfy ed 1mod2p 'q'. When signing the message m, a hash function is usedCalculating digital signature δ ═ h (m)^d。

2. Alice applies for a digital certificate to an authoritative Certificate Authority (CA) to obtain Cert_CA:AAnd means that the digital certificate issued by the CA to Alice contains the public key (e, n) and Alice's identity information.

3. Alice registers with a Trusted Third Party (TTP),submit Cert_CA:A. TTP verifies digital certificates, randomly selects

Computingy＝g^xAnd issues a digital certificate Cert to Alice_TTP:AContaining Alice's identity, public key (e, n), and parameters (g, y). The TTP stores x as the private key to recover Alice's VES signature.

4. The VES signature formally consists of an ElGamal encryption and an exponentially equal non-interactive proof of knowledge. Alice generates a VES signature on message m, calculates c₁＝H(m)^2dy^r，c₂＝g^rRandom selection of

Calculate g^tAnd (y)^e)^tCalculating w₁＝H(m,y^er,g^r,y^e,g,(y^e)^t,g^t)，w₂T-cr. Alice sets the VES signature to φ_Alice＝(c₁,c₂,w₁,w₂). When Alice sends a VES signature to the verifier Bob, Alice sends a message m and the VES signature φ_AliceAnd a digital certificate Cert_TTP:A。

5. VES verification is mainly verification of knowledge proof. After receiving Alice's content, Bob first verifies the digital certificate Cert_TTP:AThen calculate

If w is₁′＝w₁The VES signature is considered correct.

6. The TTP can recover Alice's VES signature. TTP receives (m, phi) from an entity_Alice,Cert_TTP:A) Afterwards, firstly, the correctness of the VES is verified, and the execution is quitted by the verification of the error. Otherwise, the TTP decrypts φ using the stored x for Alice_AliceTo yield H (m)^2dThen H (m) can be recovered using Euclidean algorithm^d. Note, in particular, H (m) recovered by TTP^dThe signature is a standard RSA digital signature, and can be verified only by executing a standard RSA signature verification process without extra operation during verification.

Secondly, the PDF document has format requirements when a digital signature is attached. The structure of a single digital signature is shown in fig. 1, where the content of the hash function is defined by a byte range (ByteRange), divided into two parts, with the digital signature value embedded in the middle. The first part is the document content to be signed and some "metadata" such as font information, digital signature format, etc. The second part is the remaining "metadata" and end-marker, such as timestamp information, the reason the digital signature was attached to, the information entered at the time of the signature, location, etc. In the example of fig. 1, the first portion of data has 840 bytes, the second portion of data has 240 bytes, and the digital signature has 120 bytes. In practice, after PDF version 1.5, RSA signatures of 1024, 2048, and 4096 bit length are supported.

When a plurality of digital signatures are stored in one PDF document, the structure thereof is as shown in fig. 2. An example of a PDF document containing three digital signatures can be seen in fig. 2. The content signed by the first signer includes the original document and "metadata" about the original document and the first digital signature. The content signed by the second signer includes the complete signed document with the first signature, some modified content to the document (e.g., added annotations), and "metadata" about the modified content and the digital signature. The third digital signature is similar in that the content signed by the third signer contains all of the content of the PDF document except for this digital signature.

In legal force, the first digital signature indicates that the signer approves the document content prior to its signing and does not contain approval of subsequent modified content (e.g., annotations) and subsequent digital signatures. The second digital signature indicates the signer's approval of the document content before it signed and the annotations that the signer may add by himself. The third digital signature is similar. The only commonly recognized part of the three signers is the original contract text. Subsequent signer-added annotations are only binding on the signer who added the annotations. According to the PDF specification, the PDF reader can display the digital signature in the PDF file and the protection range thereof, and can clearly indicate the modified content of each signer.

The traditional multiparty fair contract signing scheme is to fairly exchange respective digital signatures for a piece of unanimous text, namely, the signed contents of the respective digital signatures are consistent, which is not in accordance with the format of multi-person signatures of PDF documents.

Disclosure of Invention

Based on this, it is necessary to provide a method for determining a data digest of a message, a system for determining a data digest of a message, a digital signature method based on multi-party signatures, and a digital signature system based on multi-party signatures, in order to solve the problem that the requirements for consistency of content signed by each digital signature in the conventional multi-party fair contract signing scheme do not conform to the format of multi-party signatures of PDF documents.

In order to achieve the above purpose, the embodiment of the technical scheme of the invention is as follows:

a method of determining a data digest of a message, comprising the steps of:

acquiring a message to be processed and state quantities of a hash function;

initializing operation by adopting an initialization algorithm of the hash function according to the state quantity of the hash function, and initializing the context of the hash function operation;

outputting the context operated by the hash function as a hash function state quantity; and executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the summary information of the message to be processed.

A digital signature method based on multi-party signature comprises the following steps:

the current participant acquires or constructs a file to be signed;

determining the state quantity of a hash function corresponding to a file to be signed;

initializing the context of hash function operation according to the hash function state quantity;

executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the data abstract of the file to be signed;

and executing digital signature operation according to the data abstract of the file to be signed to obtain a digital signature result.

A multi-party signature based signature method comprises the following steps:

receiving a second uplink message sent by a previous party, wherein the second uplink message comprises a digital signature result of the previous party;

synthesizing a document digitally signed by the previous participant according to the second uplink message;

after the digital signature of the previous party is verified, calculating the state quantity of the hash function of the document after the digital signature of the previous party;

and sending a downlink message to the next participant, wherein the downlink message comprises the hash function state quantity of the document digitally signed by the previous participant.

A multi-party signature based signature method comprises the following steps:

receiving a second uplink message sent by a previous party, wherein the second uplink message comprises a VES signature result of the previous party;

decrypting the VES signature result of the previous party to obtain the digital signature result of the previous party;

after the digital signature result of the previous party is verified, calculating the hash function state quantity of the document after the digital signature of the previous party;

A multi-party signature based signature method comprises the following steps: receiving a signature message pair sent by the last participant, wherein the signature message pair comprises signature messages of all participants and message signatures of the signature messages of all the participants, and the signature messages of all the participants comprise hash function state quantities of documents after digital signatures of all the participants, VES signature results of all the participants and original file data to be signed;

verifying VES signature results of all participants, and determining the correctness of hash function state quantities of the documents after digital signatures of all participants according to the verification results;

when the hash function state quantity of the document after the digital signature of each participant passes the verification, a protocol execution message is sent to a first participant, the digital signature result of the first participant is sent to a next participant by the first participant, and when the digital signature result of the previous participant is received by each participant, the digital signature result of the previous participant passes the verification, the digital signature result of the current participant is sent to the next participant, and after the digital signature result of the previous participant passes the verification, the final signature composite document is determined, and the final signature composite document is sequentially returned to the previous participants.

A system for determining a data digest of a message, comprising:

the information acquisition module is used for acquiring the information to be processed and the state quantity of the hash function;

the first initialization module is used for initializing operation by adopting an initialization algorithm of the hash function according to the state quantity of the hash function and initializing the context of hash function operation;

the message updating module is used for performing message updating operation on the message to be processed by adopting a message updating algorithm of the hash function based on the state quantity of the hash function to obtain the context of the updated hash function operation;

the state quantity output module is used for outputting the context of the updated hash function operation as the hash function state quantity;

and the ending processing module is used for executing ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the summary information of the message to be processed.

A multi-party signature based digital signature system, comprising:

the file acquisition module is used for acquiring or constructing a file to be signed;

the first state quantity determining module is used for determining the hash function state quantity corresponding to the file to be signed;

the second initialization module is used for initializing the context of hash function operation according to the hash function state quantity;

the digest determining module is used for executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the data digest of the file to be signed;

and the digital signature module is used for executing digital signature operation according to the data abstract of the file to be signed to obtain a digital signature result.

A multi-party signature based signature system, comprising:

the second message receiving module is used for receiving a second uplink message sent by a previous party, wherein the second uplink message comprises a digital signature result of the previous party;

the second document synthesis module is used for synthesizing a document which is digitally signed by the previous participant according to the second uplink message;

the second state quantity determining module is used for calculating the hash function state quantity of the document after the digital signature of the previous party is verified;

and the second message sending module is used for sending a downlink message to the next participant, wherein the downlink message comprises the hash function state quantity of the document digitally signed by the previous participant.

A multi-party signature based signature system, comprising:

a second message receiving module, configured to receive a second uplink message sent by a previous party, where the second uplink message includes a VES signature result of the previous party;

the VES decryption module is used for decrypting the VES signature result of the previous party to obtain the digital signature result of the previous party;

the second state quantity determining module is used for calculating the hash function state quantity of the document digitally signed by the previous party after the digital signature result of the previous party is verified;

A multi-party signature based signature system, comprising:

the second signature message pair receiving module is used for receiving a signature message pair sent by the last participant, wherein the signature message pair comprises each participant signature message and a message signature of each participant signature message, and each participant signature message comprises a hash function state quantity of a document subjected to digital signature of each participant, a VES signature result of each participant and original file data to be signed;

the signature message pair verification module is used for verifying VES signature results of all participants and determining the correctness of the hash function state quantity of the document after digital signature of all participants according to the verification results;

and the execution message sending module is used for sending a protocol execution message to the first participant when the hash function state quantity of the document after the digital signature of each participant passes the verification, sending the digital signature result of the first participant to the next participant by the first participant, and when the digital signature result of the previous participant is received by each participant, sending the digital signature result of the current participant to the next participant after the digital signature result of the previous participant passes the verification, determining a final signature composite document after the digital signature result of the previous participant passes the verification by the last participant, and sequentially returning the final signature composite document to the previous participants.

Based on the scheme of the embodiment, when the data digest of the message is determined, after the context of the hash function operation is obtained, the context of the hash function operation is output as the hash function state quantity, and when the digital signature is performed in the electronic contract signing process, the data digest of the file to be signed can be calculated based on the hash function state quantity by determining the hash function state quantity corresponding to the signed electronic contract file, and the hash function state quantity can also be shared by other participants or a trusted third party, so that the other participants or the trusted third party can construct a virtual file based on the hash function state quantity, thereby completing the sequential signature process, and meeting the format requirement that the finally generated electronic contract file conforms to the multi-party digital signature of the PDF document.

Drawings

FIG. 1 is a diagram illustrating the structure of a single digital signature of a PDF document in one embodiment;

FIG. 2 is a diagram illustrating the structure of a PDF document containing multiple digital signatures according to one embodiment;

FIG. 3 is a flow diagram illustrating a method for determining a data digest of a message, in one embodiment;

FIG. 4 is a flow diagram that illustrates a digital signature method based on multi-party signatures, in one embodiment;

FIG. 5 is a flow diagram of a multi-party signature based digital signature method in another embodiment;

FIG. 6 is a flow diagram of a multi-party signature based digital signature method in another embodiment;

FIG. 7 is a schematic diagram of an interaction flow for electronic contract signing based on a multi-party signature digital signature method in a specific example;

fig. 8 is an interaction flow diagram of electronic contract signing based on the multiparty signature digital signature method in the second specific example;

fig. 9 is an interaction flow diagram of electronic contract signing based on the multiparty signature digital signature method in the third specific example;

fig. 10 is an interaction flow diagram of electronic contract signing based on the multiparty signature digital signature method in the fourth specific example;

fig. 11 is an interaction flow diagram of electronic contract signing based on the multiparty signature digital signature method in the fifth specific example;

FIG. 12 is a block diagram of a system that determines a data digest of a message, in one embodiment;

FIG. 13 is a block diagram that illustrates a multi-party signature based digital signature system, in one embodiment;

FIG. 14 is a block diagram of a multi-party signature based digital signature system in one particular example;

fig. 15 is a schematic structural diagram of a multi-party signature based digital signature system in a second specific example;

fig. 16 is a schematic structural diagram of a multi-party signature based digital signature system in a third specific example;

fig. 17 is a schematic structural diagram of a multi-party signature based digital signature system in a fourth specific example;

fig. 18 is a schematic structural diagram of a multi-party signature based digital signature system in a fifth specific example;

FIG. 19 is a block diagram of a multi-party signature based digital signature system in another embodiment;

FIG. 20 is a block diagram of a multi-party signature based digital signature system in another embodiment;

fig. 21 is a schematic structural diagram of a multi-party signature-based digital signature system in another embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the detailed description and specific examples, while indicating the scope of the invention, are intended for purposes of illustration only and are not intended to limit the scope of the invention.

For the sake of no loss of generality, assuming that there are three users Alice, Bob, Charlie who want to execute a fair contract signing agreement, have negotiated contract text, write into the PDF document, and then execute the fair contract signing agreement, the following description of the embodiments is described in a scenario of a three-party fair contract signing, and those skilled in the art will understand that the solution of the following embodiments can be generalized to a case of a multiple-party fair contract signing. It can be determined based on the following description of the examples that, in general, only the first and last participants may need to perform some exception operations, while the operations of the intervening participants are the same.

In the following embodiments, all are based on an assumed precondition: each participant finds a common Trusted Third Party (TTP). Each participant attaches its signature to the treaty document, hands it to the TTP, and is handed over by the TTP to the other participants. Under this precondition, multiple rounds of interaction are required with the participants greater than 2, in a typical trusted third party based authentication approach. Assume that there are point-to-point links between each entity, if there is p_nA participant, which requires each participant to do p with the TTP_n1 interaction. At least 2p is required for each interaction_nA message, requiring at least 2p in total_n(p_n-1) message. Therefore, due to the complexity of the agreement for multi-party contract signing, the agreement based on multi-round interaction cannot adapt to the service scene situation with higher requirement on real-time performance, and the scheme of the related embodiment of the invention can meet the higher real-time performance requirement under the condition of meeting fair contract signing.

For convenience of describing relevant contents related to the embodiments of the present invention, the following convention is made for relevant contents in the following embodiments: the symbol m represents the contract text, the symbol m' represents the first portion "metadata" after the contract text and before the digital signature field, and the symbol m "represents the second portion" metadata "and the end flag after the digital signature field. The digital signature of user X on message m is simply expressed as

Wherein

Representing the message digest, Sign, calculated on the message m by means of a hash function H_X(. -) represents a digital signature algorithm (e.g., RSA signature), δ_XRepresents a digital signature computation result, also referred to as a digital signature result. The symbol H (-) represents the arithmetic operation of the hash function, not the meter of the hash functionAs a result of the calculation, the parenthesized content in the notation indicates the calculation range of the arithmetic operation. The symbol H (m, m ') indicates that the original texts m, m ', and m ' are sequentially input to H (-) operation to obtain a calculation result. Sign Λ_XAnd VESSing_XRespectively representing the VES signature result of the user X and the process of the user X performing the VES.

In the PDF signing process, any subsequent participant must use the output result of the previous participant as the original text, and calculate a digest information (data digest) through a hash function for generating a digital signature result.

In the VES-based multiparty fair contract signing scheme, since the signature value of a certain party cannot be disclosed before signing of each party is completed, the party cannot calculate the original text summary information required for generating a digital signature according to the PDF original text. In the embodiments described below, this problem is solved by introducing the idea of a distributed computing hash function. First, considering that the calculation of most hash functions H in the existing cryptosystem is iterative, the specific calculation process of the hash function can be described by three algorithms and one state quantity. The state quantity is ψ, representing the intermediate state that needs to be stored in the hash function calculation process. The three algorithms are respectively an initialization algorithm H of a hash function_iMessage updating algorithm H of (zeta) hash function_u(. cndot.) and end algorithm H for Hash function_f(. cndot.). Initialization algorithm H_iInput parameter ζ of (ζ) is a hash function type, such as H_i(MD5) represents the initialization operation of MD5 algorithm, H_i(SHA1) represents the initialization operation of the SHA1 algorithm. Message update Algorithm H_u(. and end algorithm H)_fThe input parameters of (are) represent the original text participating in the operation, both operations having to be based on a state quantity psi of a hash function operation, e.g. psi. H_fIndicating that the end algorithm H is executed with the state quantity psi as an intermediate state_f(. here, the left side of the symbol ". cndot.. For simplicity of description, multiple hash operations may be combined, such as

The process of calculating the message digest of the original text m by adopting the hash function zeta is expressed, and the three operations of initialization, updating and ending are sequentially executed.

To further clarify the above expression rule, assuming that the message to be hashed is (m, m', m "), the actual calculation process may be to first calculate H_i(ζ), the state quantity ψ is initialized, and then H is calculated_u(m), then calculating H_u(m ', m') and finally calculating H_fThe output of the hash function is obtained, and the calculation process can be expressed as

In the process of H_uAt the time of calculation, the state quantity ψ is updated. In the process of calculating the hash function, once H is executed_fThe state quantity psi is discarded when the hash calculation result is obtained, and the discarded state quantity psi cannot be reversely derived from the output hash calculation result. Based on the above limitation, the basic idea of the distributed computing hash function of each of the following embodiments of the present invention is to share the state quantity ψ between each participant of a multi-party fairness contract, and to complete the computation of the hash function once by causing a plurality of entities to cooperate together by passing the state quantity ψ. This method of computing hash functions is supported by most implementations of hash functions, such as OpenSSL libraries, NTRU libraries, and so on.

Based on the above-mentioned preset preconditions, the following detailed description will be given with reference to several embodiments thereof.

A flow diagram of a method of determining a data digest of a message in one embodiment is shown in fig. 3. As shown in fig. 3, the method for determining the data digest of the message in this embodiment includes:

step S301: acquiring a message to be processed and state quantities of a hash function;

step S302: initializing operation by adopting an initialization algorithm of the hash function according to the state quantity of the hash function, and initializing the context of the hash function operation;

step S303: outputting the context of the hash function operation as a hash function state quantity; and executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the summary information of the message to be processed.

Based on the scheme of the embodiment, when the data digest of the message is determined, after the context of the hash function operation is obtained, the context of the hash function operation is output as the hash function state quantity, so that when the digital signature is performed in the electronic contract signing process, by determining the hash function state quantity corresponding to the signed electronic contract file, the data digest of the file to be signed can be calculated based on the hash function state quantity, and the hash function state quantity can also be shared by other participants or trusted third parties, so that the other participants or the trusted third parties can construct a virtual file based on the hash function state quantity, thereby completing the sequential signature process, and meeting the format requirement of the finally generated electronic contract file for the multi-party digital signature of the PDF document.

The state quantity of the hash function may include: information of the register set of the hash operation, and information of the last unused input data chunk.

In a specific example, between the step S302 and the step S303, the method may further include:

step S3023: and based on the state quantity of the hash function, performing message updating operation on the message to be processed by adopting a message updating algorithm of the hash function to obtain the context of the updated hash function operation.

In this case, in step S303, the context of the hash function operation after updating is output as the hash function state quantity.

In a specific example, when the message update operation is performed in step S3023, the message update operation may be performed on at least one data fragment of the message to be processed by using a message update algorithm of a hash function.

The method for determining the data digest of the message can be applied to a process of digital signature based on multi-party signature, so as to output the state quantity of the hash function in the process of calculating the data digest of the message, further perform digital signature based on the output state quantity of the hash function, and further perform signing of the multi-party electronic contract based on the multi-party signature.

Fig. 4 is a flow chart illustrating a method for digital signature based on multi-party signature in an embodiment, which is described by taking a process of one participant as an example. As shown in fig. 4, the method of digital signature based on multi-party signature in this embodiment includes:

step S401: the current participant acquires or constructs a file to be signed;

a step S402; determining the state quantity of a hash function corresponding to a file to be signed;

step S403; initializing the context of hash function operation according to the hash function state quantity;

step S404; executing the ending operation of the hash function by adopting an ending algorithm of the hash function to obtain the data abstract of the file to be signed;

step S405; and executing digital signature operation according to the data abstract of the file to be signed to obtain a digital signature result.

The hash function state quantity obtained in the above embodiment scheme can be transmitted to other parties, or transmitted to other parties based on other information, so as to complete information transmission, and thus, the signing of the electronic contract based on multi-party signature is completed.

In a specific application example, before the hash function state quantity corresponding to the file to be signed is determined, additional data of the current participant to the file to be signed may also be acquired. At this time, the file to be signed comprises the added data; the hash function state quantity is obtained by calculating the file to be signed including the added data.

In an application example, when the current participant is the first participant, the document to be signed may be the original document data to be signed. At this time, the hash function state quantity corresponding to the file to be signed may be a hash function state quantity corresponding to the original file data to be signed, which is calculated from the original file data to be signed (in order to distinguish the hash function state quantity corresponding to the file having the added data of the current participant, it is referred to as a first hash function state quantity in the following embodiments). At this time, the hash function state quantity corresponding to the file to be signed is the first hash function state quantity.

On the other hand, when the current participant is the first participant and the current participant adds the related data to the original document data to be signed, the document to be signed includes the original document data to be signed and the added data of the current participant. In this case, when determining the hash function state quantity corresponding to the file to be signed, the following procedure may be adopted: calculating to obtain a first hash function state quantity corresponding to original file data to be signed; and determining a second hash function state quantity according to the first hash function state quantity and the added data. At this time, the hash function state quantity corresponding to the file to be signed is the second hash function state quantity. In the context of the above initialization hash function operation, the initialization may be performed according to the second hash function state quantity.

After determining to obtain the data digest of the file to be signed and obtain the digital signature result based on the hash function state quantity, the related hash function state quantity or the related information based on the hash function state quantity can be transmitted to the next participant based on the trusted third party TTP or directly transmitted to the next participant. Different ways, such as VES signatures, can also be incorporated during the transfer.

In an application example, when the current party is the first party, the digital signature result may be further added to the file to be signed to obtain a current party digitally signed document, and the current party digitally signed document is sent to the trusted third party.

In an application example, when the current participant is not the first participant, a second upstream message may be further sent to the trusted third party, where the second upstream message includes the digital signature result. In a case that the current participant adds data, the second uplink message may further include the added data of the current participant, that is, the second uplink message includes the digital signature result and the added data of the current participant.

In one application example, a final signed composite document sent by a trusted third party after verification of the last participant is also received. The final signed composite document may thus be determined by a trusted third party to ensure that each participant has the same signed document in the end.

In an application example, when the current participant is not the first participant, the current participant may further receive a downstream message sent by the TTP of the trusted third party, where the downstream message includes the hash function state quantity. In the case that each previous participant adds data, the downstream message may include the above hash function state quantity and the added data of the file to be signed by each previous participant. The hash function state quantity is a hash function state quantity corresponding to the file to be signed after the last participant signs, and each previous participant comprises a previous participant.

At this time, the file to be signed may be a file to be signed conceptually constructed according to the downlink message, and the file to be signed is a virtual file.

In an application example, the file to be signed may also be encrypted by using a shared key negotiated by each participant, so as to obtain the encrypted file to be signed. At this time, a first uplink message may also be sent to the trusted third party, where the first uplink message includes the encrypted file to be signed, the state quantity of the first hash function, and the digital signature result. When the current participant adds data, the first uplink message may further include the added data of the current participant, that is, the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the digital signature result, and the added data of the current participant.

In one application example, an initial signed composite document sent by the trusted third party after the last participant is verified may also be received, the initial signed composite document being a composite document determined by the trusted third party based on the digital signature results for the participants. At this time, the current participant synthesizes a final signature synthesis document according to the original file data to be signed and the initial signature synthesis document stored by the current participant.

In an application example, when the current participant is not the first participant, a downlink message sent by the trusted third party may also be received, where the downlink message includes the hash function state quantity and the first hash function state quantity. In the case that each previous participant adds data, the downlink message may further include the added data of each previous participant, that is, the downlink message includes the hash function state quantity, the first hash function state quantity, and the added data of each previous participant to the file to be signed.

At this time, the current participant can also verify the state quantity of the first hash function in the downlink message according to the original file data to be signed stored by the current participant.

In an application example, the current participant may further perform VES signature processing on the digital signature result to obtain a VES signature result.

When the current participant is the first participant, the current participant may further send a first uplink message to the trusted third party, where the first uplink message includes the VES signature result and the original to-be-signed file data. In the case that the current participant adds data, the first uplink message may further include the added data of the current participant, that is, the first uplink message includes the VES signature result, the original file data to be signed, and the added data of the current participant.

On the other hand, when the current participant is not the first participant, the current participant may further send a second uplink message to the trusted third party, where the second uplink message includes the VES signature result. In the case that the current participant adds data, the second uplink message may further include the added data of the current participant, that is, the second uplink message includes the VES signature result and the added data of the current participant.

In an application example, when the current participant is a first participant, the current participant may further send a first uplink message to the trusted third party, where the first uplink message includes the encrypted file to be signed, the first hash function state quantity, and the VES signature result. When the current participant adds data, the first uplink message may further include the added data of the current participant, that is, the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the VES signature result, and the added data of the current participant.

In an application example, the current participant may further add the digital signature result to the file to be signed to obtain a digitally signed document of the current participant, and determine a hash function state quantity of the digitally signed document of the current participant.

In one application example, the current participant further constructs a current participant signature message based on the hash function state quantity of the current participant digitally signed document, the VES signature result, and the original to-be-signed file data. In one particular application, where the current participant adds data, the current participant signature message may also include the current participant's added data.

On the other hand, the current participant may also construct a signed message pair and send the signed message pair to the next participant. Wherein the signed message pair comprises a first signed message pair of the current participant, the first signed message pair comprising the current participant signed message, a message signature of the current participant signed message. When the current participant is not the first participant, the signed message pair may further include signed message pairs of previous participants.

In an application example, the current participant may further receive a signed message pair sent by a previous participant, where the signed message pair sent by the previous participant includes: the signature message pairs of the participants before the current participant comprise the signature messages of the previous participants and the message signatures of the signature messages of the previous participants. And the previous signing message of each participant comprises the hash function state quantity of the document after the digital signature of each participant, the VES signing result of each previous participant and the original file data to be signed. In one application example, where previous participants added data, previous participant signature messages may also include the added data of previous participants.

On the basis, after receiving the signed message pair sent by the previous party, the current party can verify the message signature and the VES signature result of each previous party contained in the signed message pair sent by the previous party.

In an application example, when the current participant is the first participant, the current participant may further receive a protocol execution message returned by the trusted third party after receiving the message signature pair sent by the last participant; and sending the digital signature result of the current participant to the next participant according to the protocol execution message.

In an application example, when the current participant is not the first participant, the current participant can also receive the digital signature results of previous participants sent by the previous participant; and after the digital signature results of the previous participants are verified, sending the digital signature result of the current participant to the next participant.

In an application example, when the current participant is the last participant, the current participant may determine a final signature composite document after the digital signature results of the previous participants are verified, and send the final signature composite document to the previous participant.

In one application example, when the current participant is not the first participant, the current participant may also receive a final signed composite document sent by the next participant; and sending the final signed composite document to the previous party if the current party is not the first party.

Fig. 5 is a schematic flow chart of a digital signature method based on multi-party signatures in another embodiment, which is described by taking a processing procedure of a trusted third party TTP as an example, and each participant sends a digital signature result of itself to the trusted third party TTP. As shown in fig. 5, the method in this embodiment includes:

step S501: receiving a second uplink message sent by a previous party, wherein the second uplink message comprises a digital signature result of the previous party;

step S502: synthesizing a document digitally signed by the previous participant according to the second uplink message;

step S503: after the digital signature of the previous party is verified, calculating the state quantity of the hash function of the document after the digital signature of the previous party;

step S504: and sending a downlink message to the next participant, wherein the downlink message comprises the hash function state quantity of the document digitally signed by the previous participant.

In an application example, the TTP of the trusted third party may further receive a first digitally signed document sent by the first party, where the first digitally signed document includes the original document data to be signed and a digital signature of the first party.

In this case, the trusted third party TTP may further calculate the hash function state quantity of the document digitally signed by the first participant after verifying the digital signature of the first participant in the document digitally signed by the first participant.

At this time, the TTP of the trusted third party may also send a downstream message to the next participant, where the downstream message includes the hash function state quantity of the document digitally signed by the first participant.

In an application example, the trusted third party TTP may further receive a first upstream message sent by the first party, where the first upstream message includes: the method comprises the steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a digital signature result of the first participant.

On the basis, the trusted third party TTP can also conceptually synthesize the digitally signed document of the first party according to the first upstream message.

At this time, the TTP of the trusted third party may also calculate the hash function state quantity of the document digitally signed by the first party after verifying the digital signature of the first party.

On this basis, the trusted third party TTP may also send a downstream message to the next participant, where the downstream message includes: a hash function state quantity of the document after the digital signature of the first participant, and the first hash function state quantity.

In an application example, when the last participant is the last participant, the TTP of the trusted third party may further synthesize a final signature synthesis document according to the second uplink message; and after the digital signature of the last participant is verified to pass, sending the final signature composite document to each participant.

In an application example, when the previous party is the last party, the TTP of the trusted third party may further conceptually synthesize a document digitally signed by the previous party according to the second uplink message, verify that the digital signature of the last party passes the verification according to the document digitally signed by the previous party, synthesize an initial signature synthesized document according to the digital signature result of each party, and send the initial signature synthesized document to each party, and each party synthesizes a final signature synthesized document according to the original to-be-signed document data stored by itself and the initial signature synthesized document.

Fig. 6 is a schematic processing flow diagram of a multi-party signature-based digital signature method of a trusted third party TTP in another embodiment, which is performed based on VES signatures, and each participant sends a VES signature result to the trusted third party TTP, so as to transfer a hash function state quantity of a document signed by the participant to a next participant via the trusted third party TTP. As shown in fig. 6, the method in this embodiment includes:

step S601: receiving a second uplink message sent by a previous party, wherein the second uplink message comprises a VES signature result of the previous party; in the case that the previous party added data, the second uplink message may further include the added data of the previous party;

step S602: decrypting the VES signature result of the previous party to obtain the digital signature result of the previous party;

step S603: after the digital signature result of the previous party is verified, calculating the hash function state quantity of the document after the digital signature of the previous party;

step S604: and sending a downlink message to the next participant, wherein the downlink message comprises the hash function state quantity of the document digitally signed by the previous participant, and the downlink message can also comprise the added data of the previous participants under the condition that the data is added by the previous participants.

In an application example, the trusted third party TTP may further receive a first upstream message sent by the first party, where the first upstream message includes: the original document data to be signed, and the VES signature result of the first party. In the case where the first participant has added data, the first upstream message may also include the added data of the first participant.

At this time, the TTP of the trusted third party may also decrypt the VES signature result of the first party to obtain the digital signature result of the first party. In the case where the first party has added data, the digitally signed document of the first party may also include the added data of the first party

In an application example, the TTP of the trusted third party may further synthesize the document digitally signed by the first party according to the original document data to be signed and the digital signature result of the first party. And after the digital signature of the first participant is verified, calculating the hash function state quantity of the document after the digital signature of the first participant. In this case, a downlink message may also be sent to the next participant, the downlink message including: the hash function state quantity of the document after the digital signature of the first participant.

In an application example, the trusted third party TTP may further receive a first upstream message sent by the first party, where the first upstream message includes: the method comprises the steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a VES signature result of the first participant.

At this time, the TTP of the trusted third party may also decrypt the VES signature result of the first party to obtain the digital signature result of the first party.

In one application example, the trusted third party TTP may also conceptually synthesize the first party digitally signed document based on the digital signature result of the first party. The hash function state quantity of the digitally signed document of the first party may also be calculated after verifying the digital signature of the first party.

In an application example, when the previous participant is the first participant, the trusted third party TTP may further send a downstream message to the next participant, where the downstream message includes: the hash function state quantity of the document after the digital signature of the first participant, and the first hash function state quantity.

In an application example, the TTP of the trusted third party may further synthesize a final signature synthesis document according to the second uplink message when the previous party is the last party; and after the digital signature of the last party is verified to pass, the final signature composite document is sent to each party.

In an application example, the TTP of the trusted third party may further, when the previous party is the last party, conceptually synthesize a document digitally signed by the previous party according to the second uplink message, verify that the digital signature of the last party passes the verification according to the document digitally signed by the previous party, synthesize an initial signature synthesized document according to the digital signature result of each party, send the initial signature synthesized document to each party, and synthesize a final signature synthesized document by each party according to the original to-be-signed file data and the initial signature synthesized document stored by each party.

In another embodiment, when the current participant directly sends information based on the hash function state quantity to the next participant, the trusted third party TTP may perform a processing process once when receiving a message sent by the last participant, and at this time, the trusted third party TTP may receive a signature message pair sent by the last participant, where the signature message pair includes each participant signature message and a message signature of each participant signature message, and each participant signature message includes the hash function state quantity of the document after each participant digital signature, the VES signature result of each participant, and the original file data to be signed.

In this case, the TTP of the trusted third party may also verify the VES signature result of each participant, and determine the correctness of the hash function state quantity of the digitally signed document of each participant according to the verification result.

At this time, the TTP of the trusted third party may also send a protocol execution message to the first party when the hash function state quantity of the digitally signed document of each party passes verification, the first party sends the digital signature result of the first party to the next party, and each party receives the digital signature result of the previous party, and after the digital signature result of the previous party passes verification, the last party sends the digital signature result of the current party to the next party, and after the digital signature result of the previous party passes verification, determines a final signature composite document, and sequentially returns the final signature composite document to the previous parties.

Based on the embodiments described above, according to different ways of delivering related information based on the state quantity of the hash function (for example, based on the TTP of the trusted third party to be delivered to the next participant or directly delivered to the next participant), and different ways of processing in the delivery process, such as encryption of the shared key of each participant, VES signature, and the like, the following detailed description is made in conjunction with the process of completing the signing of the electronic contract through the interaction process between each participant and the TTP of the trusted third party based on a few specific examples thereof.

In the following description of each specific example, a message sent by a first party to a trusted third party TTP is referred to as a first uplink message, a message sent by another party to the trusted third party TTP is referred to as a second uplink message, and a message sent by the trusted third party to each party is referred to as a downlink message.

Specific example 1

In this specific example, after each participant transfers relevant information based on the state quantity of the hash function to the trusted third party, the trusted third party TTP transfers the relevant information to the next participant.

In this particular example, the multiparty fair contract signing process is accomplished by introducing an "Inline" TTP. The meaning of inline TTP, i.e. each signature of each signer, requires TTP assistance. TTP assistance here, has two layers of implications: (1) the TTP assists a certain participant to verify the correctness of the digital signature result output by the previous participant; (2) based on the idea of calculating the hash function in a distributed manner, the TTP calculates the state quantity of the hash function of the output result of a certain participant, and then sends the state quantity to the subsequent participant, so that the subsequent participant can generate a digital signature of the subsequent participant without obtaining a PDF file output by the previous participant.

Suppose that users Alice, Bob and Charlie ensure that all parties hold the same PDF document m through other channels (e.g., E-mail, etc.)₀. In this specific example, the processing of the user Alice represents the processing of the first participant, the processing of the user Bob represents the processing of the middle participants, and the processing of the user Charlie represents the processing of the last participant. Fig. 7 is a schematic flow chart illustrating an interaction process between each participant and a trusted third party TTP in the process of signing an electronic contract by the multi-party signature-based digital signature method in this specific example.

As shown in fig. 7, in this specific example, in order to achieve fair contract signing, in the signing process of the electronic contract, the users Alice, Bob, Charlie perform the following protocol:

step S701: alice signs PDF document m₀(original file data to be signed), first determine the content m 'that needs to be added'_AAnd m ″)_A(adding data of the current participant with Alice as the current participant), and calculating the message digest

Then calculating the digital signature

Alice generates PDF document D based on digital signature_A＝(m₀,m′_A,δ_Alice,m″_A) And is sent to the trusted third party TTP over a secure channel.

Step S702: trusted third party TTP store document D_AVerify Alice signature delta_AliceIf the verification fails, quitting; if the signature delta is verified_AliceEfficient, TTP computation document D_ACorresponding state quantity (hash function state quantity) ψ_A＝H_i(ζ).H_u(D_A) Then the message (m ') is transmitted through the secure channel'_A,m″_A,ψ_A) (downstream message) to Bob.

Step S703: bob checks m'_AAnd m ″)_A(addition data of the last participant), content m 'that needs to be added by itself is determined'_BAnd m ″)_B(addition data of the current participant with Bob as the current participant). At this time, Bob may conceptually synthesize the PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Since Bob does not obtain delta_AliceThus, D cannot be actually synthesized_A. However, although Bob did not obtain δ_AliceAnd D cannot be actually synthesized_ABut Bob obtained document D from TTP_ACorresponding state quantity psi_ASo that a hash value can be calculated

Then executing digital signature operation to obtain the digital signature of Bob

Bob sends the message (m ') through a secure channel'_B,δ_Bob,m″_B) (second upstream message) is handed over to the TTP.

Step S704: synthesis of TTP D_B＝(D_A,m′_B,δ_Bob,m″_B) Verification of Bob signature delta_BobIf the verification fails, quitting; if the signature delta is verified_BobValid, TTP for document D_BCalculating the quantity of state psi_B＝H_i(ζ).H_u(D_B) Then the message (m ') is transmitted through the secure channel'_A,m″_A,m′_B,m″_B,ψ_B) And sending the information to Charlie.

Step S705: charlie inspection m'_A、m″_A、m′_B、m″_BThen determines the content m 'which is required to be added by itself'_CAnd m ″)_C. At this point, Charlie may conceptually synthesize PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B) Although Charlie does not obtain delta_BobAnd D cannot be actually synthesized_BBut Charlie obtained document D from TTP_BCorresponding state quantity psi_BThereby calculating a hash value

Then, performing digital signature operation to obtain a digital signature of Charlie

Charlie sends a message (m 'over a secure channel'_C,δ_Charlie,m″_C) Handed over to TTP.

Step S706: synthesis of TTP D_C＝(D_B,m′_C,δ_Charlie,m″_C) Verifying the signature delta of Charlie_Charlie. After the verification is passed, D_CAnd sending the information to Alice, Bob and Charlie to finish contract signing, and otherwise, quitting.

Thus, in this particular example, each participant is able to form a consistent signed PDF document in the event that each participant only needs to interact once with the TTP. Since the TPP assists in calculating the state quantity ψ of the hash function, the post-signed entities (parties) can generate digital signatures that conform to the PDF document specification without knowing the previous signature during the multiparty fair contract signing process.

The process in the specific example above achieves the goal of fair contract signing. For each participant, the final D is obtained_CBefore, the digital signature information of other parties is not obtained, so that the early exit of the contract signing process has no influence on all the parties. Because D_CIs sent by TTP to each party if one party gets D_COther parties must also obtain D_C. In addition, the above protocol may be extended to the case where the participants are greater than 3. For p_nIndividual participants, each of whom sends a message to the TTP substantially once, receives two messages (one of which is the final contract), the total number of communications being substantially 3p_nNext, the process is carried out.

Here, the hash function state quantity ψ is essentially a state quantity in the hash function calculation process and data of less than one block. Taking the SHA-1 algorithm as an example, the size of each block is 512 bits, i.e. 64 bytes, the state quantity size is 20 bytes, and the total size is 92 bytes by adding two pieces of length information. By interpreting the PDF specification and observing the binary file of the actual PDF document, it can be seen that the ancillary information m "after the digital signature field is typically larger than 64 bytes. After testing in conjunction with a certain number of PDF documents, the m "portion is about 600 bytes small and as large as about 10 kbytes. It follows that the signature value of the previous digital signature field is obtained by sniffing the state quantity ψ, so that in practice the probability of an attack on the signature value of the previous signer due to leakage of the state quantity ψ is extremely small, which also ensures security in the electronic contract signing process.

Specific example 2

In this specific example, after each participant transmits the relevant information based on the state quantity of the hash function to the trusted third party, the TTP of the trusted third party is transmitted to the next participant, and the original file data to be signed is encrypted based on the shared key of each participant.

Based on the scheme of the specific example, the content of the contract text can be obtained by the trusted third party TTP in the participation process. It is assumed that the trusted third party TTP participates in the multiparty fair contract signing agreement honestly, but it is desirable that the TTP does not obtain the contents of the contract text. To achieve this goal, there are many possible solutions. For example, a PDF file built-in mechanism can be used to encrypt critical data in a file, and a user is required to input a password to correctly open and read the file at the file loading stage of a PDF reader. Since the signing object executed in the above exemplary scheme process is a PDF file to which an access password is added, there is no influence on the execution of the above protocol.

In one specific application implementation of this specific example, to achieve fair contract signing, the contract text m is signed by₀Encryption is performed and a multiparty fair contract signing agreement is executed.

In this particular example, assume that Alice, Bob, and Charlie ensure that each party holds the same PDF document m through other channels (e.g., E-mail, etc.)₀. Fig. 8 is a schematic flow chart illustrating an interaction process between each participant and a trusted third party TTP in the process of signing an electronic contract by the multi-party signature-based digital signature method in this specific example.

As shown in fig. 8, in this specific example, in the process of fair signing of the electronic contract, Alice, Bob, Charlie perform the following protocol:

step S800: a multi-party key agreement protocol (such as a group key agreement protocol based on the DH protocol) is performed between Alice, Bob and Charlie, so that each party holds the same shared key K_pre。

Step S801: alice signs PDF document m₀First, the content m 'which needs to be added is determined'_AAnd m ″)_ACalculating the state quantity psi₀＝H_i(ζ).H_u(m₀) Go forward toStep calculation state quantity psi_A＝H_i(ζ).H_u(m₀).H_u(m', m ") and then computes a message digest

And digital signature

Alice then uses the shared secret K_preEncrypting the original text to obtain a ciphertext c₀＝Encrypt(m₀,K_pre) Any shared secret key K may be used here_preMatched encryption algorithms (e.g., DES, 3DES, AES, SM4, etc.). Alice then sends the message (c)₀,ψ₀,m′_A,δ_Alice,m″_A) Handed over to the TTP over the secure channel.

Step S802: TTP conceptually synthesizes PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Then verify the Alice signature delta_AliceThe effectiveness of (c). To verify the signature delta_AliceValidity of (TTP) the summary information must be calculated

Since the TTP does not hold the shared secret K_preTherefore, it is impossible for the TTP to obtain the original text m by decryption₀And calculate out

However, the TTP can indeed be based on the psi transmitted by Alice₀Reinitializing the state of the local hash function and then computing

Thereby verifying the signature delta_AliceThe effectiveness of (c). If the signature delta is verified_AliceIf the failure happens, quitting; if the signature delta is verified_AliceEfficient, TTP computation document D_A＝(m₀,m′_A,δ_Alice,m″_A) Corresponding state quantity psi_A＝ψ₀.H_u(m′_A,δ_Alice,m″_A) Then the message (m ') is transmitted through the secure channel'_A,m″_A,ψ₀,ψ_A) Sent to Bob.

Step S803: bob checks m'_AAnd m ″)_AAnd check psi₀And the original text m₀And (4) whether the signals are matched or not, and if not, exiting. If psi₀And the original text m₀Matching, Bob determines m 'of content that Bob needs to add'_BAnd m ″)_B. At this time, Bob may conceptually synthesize the PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Although Bob does not obtain delta_AliceAnd D cannot be actually synthesized_ABut Bob obtained document D from TTP_ACorresponding state quantity psi_AThereby calculating a hash valueThen executing digital signature operation to obtain the digital signature of Bob

Bob sends the message (m ') through a secure channel'_B,δ_Bob,m″_B) Handed over to TTP.

Step S804: TTP conceptually synthesizes PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B) Then verify Bob signature delta_BobThe effectiveness of (c). To verify the signature delta_BobValidity of (TTP) the summary information must be calculated

Thereby verifying the signature delta_BobThe effectiveness of (c). If the signature delta is verified_BobIf the failure happens, quitting; if the signature delta is verified_BobEfficient, TTP computation document D_BCorresponding state quantity psi_B＝ψ₀.H_u(m′_A,δ_Alice,m″_A,m′_B,δ_Bob,m″_B) Then the message (m ') is transmitted through the secure channel'_A,m″_A,m′_B,m″_B,ψ_B) And sending the information to Charlie.

Step S805: charlie inspection m'_A、m″_A、m′_B、m″_BAnd check psi₀And the original text m₀And (4) whether the signals are matched or not, and if not, exiting. If psi₀And the original text m₀Charlie then determines the content m 'that it needs to be added to'_CAnd m ″)_C. At this point, Charlie may conceptually synthesize PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B) Although Charlie does not obtain delta_BobAnd D cannot be actually synthesized_BBut Charlie obtained document D from TTP_BCorresponding state quantity psi_BThereby calculating a hash value

Step S806: TTP conceptually synthesizes PDF document D_C＝(D_B,m′_C,δ_Charlie,m″_C) Then verify the Charlie signature delta_CharlieThe effectiveness of (c). To verify the signature delta_CharlieValidity of (TTP) the summary information must be calculatedSince the TTP does not hold the shared secret K_preTherefore, it is impossible for the TTP to obtain the original text m by decryption₀And calculate out

Thereby verifying the signature delta_CharlieThe effectiveness of (c). If the signature delta is verified_CharlieIf the failure happens, quitting; if the signature delta is verified_CharlieSuccessfully, TTP composite document T ═ m'_A,δ_Alice,m″_A,m′_B,δ_Bob,m″_B,m′_C,δ_Charlie,m″_C) The document T is then sent to Alice, Bob and Charlie, respectively, over a secure channel.

Step S807: alice, Bob and Charlie respectively synthesize a final document D_C＝(m₀T), contract signing is completed.

Based on the scheme in this particular example, each participant is able to form a consistent signed PDF document in the event that each participant only needs to interact once with the TTP. Since the TPP assists in calculating the state quantity ψ of the hash function, the post-signed entities (parties) can generate digital signatures that conform to the PDF document specification without knowing the previous signature during the multiparty fair contract signing process.

The above protocol in this particular example achieves the goal of fair contract signing. For each participant, the final D is obtained_CBefore, the digital signature information of other parties is not obtained, so that the early exit of the contract signing process has no influence on all the parties. Because D_CIs sent by TTP to each party if one party gets D_COther parties must also obtain D_C. Furthermore, it will be appreciated that the above protocol may be extended to a situation where the participants are greater than 3. For p_nEach takes part inPeople, each participant sending a message to the TTP approximately once, receiving two messages (one of which is the final contract), the total number of communications being approximately 3p_nNext, the process is carried out.

On the other hand, in this particular example, the first party Alice is the ciphertext m₀And the encrypted data is sent to the trusted third party TTP, so that the trusted third party TTP cannot acquire the content of the original text. All subsequent participants check the state quantity psi of the hash function corresponding to the original text₀And the original text m₀Whether they match or not, to avoid the first party Alice or the trusted third party TTP sending a false original text hash function state quantity psi₀. In this specific example, the target of fair contract signing is cooperatively completed based on the idea of a distributed computing hash function by sharing the state quantity ψ between the trusted third party TTP and each party.

Specific example III

In this specific example, after each participant transmits the relevant information based on the hash function state quantity to the trusted third party, the information is transmitted to the next participant by the trusted third party TTP, and the VES signature is performed as an example.

In the scheme of the specific example one, the digital signature result δ is transferred in the interaction between each participant and the TTP_XIf the attacker obtains delta by means of network sniffing or the like_XOr delta_XMalicious exposure by background management personnel of the TTP may destroy the target of fair contract signing.

Accordingly, in this particular example, the delivery of the digital signature result δ in each participant's interaction with the TTP is addressed by introducing a verifiable cryptographic signature (VES)_XTo have further improved security in the fair signing process of electronic contracts.

In this particular example, assume that users Alice, Bob, and Charlie ensure that each party holds the same PDF document m through other channels (e.g., E-mail, etc.)₀. Fig. 9 is a schematic flow chart illustrating an interaction process between each participant and a trusted third party TTP in the process of signing an electronic contract by the multi-party signature-based digital signature method in this specific example。

As shown in fig. 9, in the specific example, in the process of fair signing of the electronic contract, Alice, Bob, Charlie perform the following protocol for the purpose of fair contract signing:

step S901: alice signs the original document m₀First, the content m 'which needs to be added is determined'_AAnd m ″)_AAnd computes a message digest

Then calculating the digital signatureThen calculate VES signature resultAnd transmits the message (m) through a secure channel₀,m′_A,Λ_Alice,m″_A) And sending to the TTP.

Step S902: trusted third party TTP uses its stored VES private key to sign Λ from Alice's VES_AliceThe common signature delta of Alice is obtained by medium decryption_AliceThen synthesizing the document D_A＝(m₀,m′_A,δ_Alice,m″_A) And stored. TTP verifies Alice signature delta_AliceIf the verification fails, quitting; if the signature delta is verified_AliceEfficient, TTP computation document D_ACorresponding hash function state quantity psi_A＝H_i(ζ).H_u(D_A) Then the message (m ') is transmitted through the secure channel'_A,m″_A,ψ_A) Sent to Bob.

Step S903: bob checks m'_AAnd m ″)_ADetermining content m 'that needs to be added by itself'_BAnd m ″)_B. At this point, Bob may conceptually compose document D_A＝(m₀,m′_A,δ_Alice,m″_A) Although Bob does not obtain delta_AliceAnd D cannot be actually synthesized_ABut Bob obtained document D from TTP_ACorresponding state quantity psi_AThereby calculating a hash value

Then calculate VES signature result

And transmits the message (m ') through the secure channel'_B,Λ_Bob,m″_B) And sending to the TTP.

Step S904: TTP signs Λ from Bob's VES with its stored VES private key_BobTo obtain the generic signature delta of Bob_BobThen synthesizing the document D_B＝(D_A,m′_B,δ_Bob,m″_B) Verification of Bob signature delta_BobIf the verification fails, quitting; if the signature delta is verified_BobValid, TTP for document D_BCalculating the quantity of state psi_B＝H_i(ζ).H_u(D_B) Then the message (m ') is transmitted through the secure channel'_A,m″_A,m′_B,m″_B,ψ_B) And sending the information to Charlie.

Step S905: charlie inspection m'_A、m″_A、m′_B、m″_BThen determines the content m 'which is required to be added by itself'_CAnd m ″)_C. At this point, Charlie may conceptually synthesize document D_B＝(D_A,m′_B,δ_Bob,m″_B) Although Charlie does not obtain delta_BobAnd D cannot be actually synthesized_BBut Charlie obtained document D from TTP_BCorresponding state quantity psi_BThereby calculating a hash value

Then, performing digital signature operation to obtain a digital signature of CharlieThen calculate VES signature result

And transmits the message (m ') through the secure channel'_C,Λ_Charlie,m″_C) And sending to the TTP.

Step S906: TTP signs Λ from Charlie's VES with its stored VES private key_CharlieThe common signature delta of Charlie is obtained by medium decryption_CharlieThen synthesizing the document D_C＝(D_B,m′_C,δ_Charlie,m″_C) Verifying the signature delta of Charlie_Charlie. After the verification is passed, D_CAnd sending the information to Alice, Bob and Charlie to finish contract signing, and otherwise, quitting.

In the execution process of the specific example, each participant sends the VES signature result to the trusted third party TTP, and the trusted third party TTP decrypts the VES signature to obtain the signature original text δ_XAnd verifying the validity of the signature original text. Meanwhile, the trusted third party TTP assists each participant in calculating the state quantity psi and transmits the state quantity psi to the next participant, and the distributed computing hash function is realized. In this particular example, δ is signed since the signature text is not transmitted over the secure channel_XTherefore, even if the attacker obtains δ by means of network sniffing or the like_XThe ciphertext can not damage the object of fair contract signing, so that the safety of the electronic contract signing process is further improved, and the fairness of the electronic contract signing process is ensured.

In an application example of the specific example, the trusted third party TTP may store a private key (VES private key) for extracting the VES signature in a security device such as a cryptographic machine, and implement a reasonable permission control measure in the TTP, so that a background manager with a higher security level can operate the security device, thereby further reducing the risk of an attack from the inside of the TTP, and further improving the security in the electronic contract signing process.

Specific example No. four

In this particular example, it is on the basis of the particular example one that each participant will be based onAfter the relevant information of the hash function state quantity is transmitted to the credible third party, the credible third party TTP transmits the relevant information to the next party, and the original contract text m is processed₀Encryption is carried out, and meanwhile, the description is given by taking a Verifiable Encryption Signature (VES) as an example, so that the trusted third party is prevented from obtaining contract text content, and meanwhile, the digital signature result delta is prevented from being transmitted in the interaction between each participant and the TTP_XTo further provide security and fairness in the electronic contract signing process.

In this particular example, assume that users Alice, Bob, and Charlie ensure that each party holds the same PDF document m through other channels (e.g., E-mail, etc.)₀. Fig. 9 is a schematic flow chart illustrating an interaction process between each participant and a trusted third party TTP in the process of signing an electronic contract by the multi-party signature-based digital signature method in this specific example.

As shown in fig. 10, in this specific example, in the process of fair signing of the electronic contract, the users Alice, Bob, Charlie perform the following protocol:

step S1000: a multi-party key agreement protocol (such as a group key agreement protocol based on the DH protocol) is performed between Alice, Bob and Charlie, so that each party holds the same shared key K_pre。

Step S1001: alice signs PDF document m₀First, the content m 'which needs to be added is determined'_AAnd m ″)_ACalculating the state quantity psi₀＝H_i(ζ).H_u(m₀) Further calculating the state quantity psi_A＝H_i(ζ).H_u(m₀).H_u(m', m ") and then computes a message digestAnd digital signature

Then calculate VES signature result

Then Alice uses the shared secretKey K_preEncrypting the original text to obtain a ciphertext c₀＝Encrypt(m₀,K_pre) Any shared secret key K may be used here_preMatched encryption algorithms (e.g., DES, 3DES, AES, SM4, etc.). Alice sends the message (c) through a secure channel₀,ψ₀,m′_A,Λ_Alice,m″_A) And sending to the TTP.

Step S1002: TTP uses its stored VES private key to sign Λ from Alice's VES_AliceThe common signature delta of Alice is obtained by medium decryption_AliceThen conceptually synthesizing the PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Then verify the Alice signature delta_AliceThe effectiveness of (c). To verify the signature delta_AliceValidity of (TTP) the summary information must be calculated

Step S1003: bob checks m'_AAnd m ″)_AAnd check psi₀And the original text m₀Whether are matched or notAnd if not, exiting. If psi₀And the original text m₀Matching, Bob determines m 'of content that Bob needs to add'_BAnd m ″)_B. At this time, Bob may conceptually synthesize the PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Although Bob does not obtain delta_AliceAnd D cannot be actually synthesized_ABut Bob obtained document D from TTP_ACorresponding state quantity psi_AThereby calculating a hash value

Then calculate VES signature result

And transmits the message (m ') through the secure channel'_B,Λ_Bob,m″_B) Handed over to TTP.

Step S1004: TTP signs Λ from Bob's VES with its stored VES private key_BobTo obtain the generic signature delta of Bob_BobThen conceptually synthesizing the PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B) Then verify Bob signature delta_BobThe effectiveness of (c). To verify the signature delta_BobValidity of (TTP) the summary information must be calculated

Step S1005: charlie inspection m'_A、m″_A、m′_B、m″_BAnd check psi₀And the original text m₀And (4) whether the signals are matched or not, and if not, exiting. If psi₀And the original text m₀Charlie then determines the content m 'that it needs to be added to'_CAnd m ″)_C. At this point, Charlie may conceptually synthesize PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B) Although Charlie does not obtain delta_BobAnd D cannot be actually synthesized_BBut Charlie obtained document D from TTP_BCorresponding state quantity psi_BThereby calculating a hash value

Then calculate VES signature result

And transmits the message (m ') through the secure channel'_C,Λ_Charlie,m″_C) Handed over to TTP.

Step S1006: TTP signs Λ from Charlie's VES with its stored VES private key_CharlieThe common signature delta of Charlie is obtained by medium decryption_CharlieThen conceptually synthesizing the PDF document D_C＝(D_B,m′_C,δ_Charlie,m″_C) Then verify the Charlie signature delta_CharlieThe effectiveness of (c). To verify the signature delta_CharlieValidity of (TTP) the summary information must be calculated

Step S1007: alice, Bob and Charlie respectively synthesize a final document D_C＝(m₀T), contract signing is completed.

In the solution of this specific example, each participant is able to form a consistent signed PDF document in case that each participant only needs to interact once with the TTP. Since the TPP assists in calculating the state quantity ψ of the hash function, the post-signed entities (parties) can generate digital signatures that conform to the PDF document specification without knowing the previous signature during the multiparty fair contract signing process.

The scheme in this particular example achieves the goal of fair contract signing and, for each participant, the final document D is being obtained_CBefore, the digital signature information of other participants is not obtained, so the contract signing process is quitted in advance and each participant is signedNone of the participants had an impact. Because of the final document D_CIs sent by the trusted third party TTP to the participants, so that if one participant gets the final document D_CThe other participants must also obtain the final document D_C. On the other hand, the approach in this specific example may also be extended to the case where the participants are larger than 3. For p_nIndividual participants, each of whom sends a message to the TTP substantially once, receives two messages (one of which is the final contract), the total number of communications being substantially 3p_nNext, the process is carried out.

In addition, in this specific example, the first participant Alice is a new text m₀And the encrypted data is sent to the trusted third party TTP, so that the trusted third party TTP cannot acquire the content of the original text. Subsequent parties all need to check the state quantity psi₀And the original text m₀Whether it matches to avoid the first party Alice or the trusted third party TTP sending a false state quantity psi₀So as to further improve the security in the electronic contract signing process.

Accordingly, the scheme in this specific example synergistically achieves the objective of fair contract signing based on the idea of a distributed computing hash function by sharing the state quantity ψ between the trusted third party TTP and each participant.

On the other hand, in the scheme of this specific example, each participant sends the VES signature result to the trusted third party TTP, and the trusted third party TTP decrypts the VES signature to obtain the signature original δ_XAnd verifying the signature original delta_XThe effectiveness of (c). Meanwhile, the trusted third party TTP assists each participant in calculating the state quantity psi and transmits the state quantity psi to the next participant, and the distributed computing hash function is realized. Since the signature text delta is not transmitted over a secure channel_XEven if the attacker obtains delta by means of network sniffing and the like_XThe ciphertext of the method can not damage the object of fair contract signing, and the security of fair signing of the electronic contract is further improved.

In an application example of the specific example, the trusted third party TTP may store the private key extracted with the VES signature in a security device such as a cryptographic machine, and implement a reasonable permission control measure in the TTP, so that a background manager with a higher security level can operate the security device, thereby further reducing the risk of an attack from the inside of the TTP.

Concrete example five

In this specific example, after each participant directly transfers the relevant information based on the state quantity of the hash function to the next participant, the TTP of the trusted third party only needs to receive the message sent by the last participant to perform the verification process.

In the schemes of the specific example one to the specific example four, the description is given based on an inline TTP as an example, and in the scheme based on the inline TTP, a trusted third party TTP interacts with each participant, and as the number of participants increases, the number of interactions also increases. In the scheme of the specific example, the number of interactions between a signer (participant) and a trusted third party TTP is reduced by introducing an Online (Online) TTP. The "Online" TTP, i.e., each signature of each signer, does not require the assistance of a trusted third party TTP, and each contract signing only requires the interaction of the last signer (the last participant) with the trusted third party TTP once.

Accordingly, in the approach of this particular example, by reducing the number of signers interacting with the TTP, only the last signer needs to interact with the TTP once per contract signing, and at the same time, a consistent PDF document signed by parties can be formed between the signers.

In this particular example, assume that users Alice, Bob, and Charlie ensure that each party holds the same PDF document m through other channels (e.g., E-mail, etc.)₀. Fig. 11 is a flow chart illustrating an interaction process between each participant and a trusted third party TTP in the process of signing an electronic contract by the multi-party signature-based digital signature method in this specific example.

As shown in fig. 11, in the specific example, in the process of fair signing of the electronic contract, in order to achieve the purpose of fair contract signing, the users Alice, Bob, Charlie execute the following protocol:

step S1101: alice signs the original PDF document m₀First, the content m 'which needs to be added is determined'_AAnd m ″)_AAnd computes a message digest

Then calculating the digital signature

Composite PDF document D_A＝(m₀,m′_A,δ_Alice,m″_A) Then to document D_ACalculating the quantity of state psi_A＝H_i(ζ).H_u(D_A). Then Alice calculates the VES signature resultConstructing a message m_A＝(m₀,m′_A,Λ_Alice,m″_A,ψ_A) Calculate m_ADigital signature of

Sending message signature pairs

To Bob.

Step S1102: bob verifies Alice's digital signatureAnd VES signature Λ_Alice. And if the verification fails, exiting the execution protocol. If the verification is successful, Bob determines that it needs the added content m'_BAnd m ″)_B. At this time, Bob may conceptually synthesize the PDF document D_B＝(D_A,m′_B,δ_Bob,m″_B). Although Bob cannot actually synthesize this D_BBut Bob can indeed transmit according to Alice_AReinitializing the state of the local hash function and then calculating psi_B＝ψ_A.H_u(m′_B,m″_B)＝H_i(ζ).H_u(D_A).H_u(m′_B,m″_B) To obtain the state quantity psi of Bob_B. At the same time, Bob can also calculate the hash value

Bob then computes the VES signature resultConstructing a message m_B＝(m₀,m′_B,Λ_Bob,m″_B,ψ_B) Calculate m_BDigital signature of

Sending message signature pairs

To Charlie.

Step S1103: charlie verifies Alice's digital signature

And VES signature Λ_AliceVerifying Bob's digital signatureAnd VES signature Λ_Bob. Note that for verification purposes, Λ_BobCharlie requires computation

This is required according to the state quantity psi_AThe calculation process is the same as that of Bob. And if the verification fails, exiting the execution protocol. If the verification is successful, Charlie determines that it needs the added content m'_CAnd m ″)_C. At this point, Charlie may conceptually synthesize a PDF document

Although Charlie cannot actually synthesize this D_CHowever, Charlie can indeed be based on the psi sent by Bob_BReinitializing the state of the local hash function and then calculating psi_C＝ψ_B·H_u(m′_C,m″_C)＝H_i(ζ).H_u(D_A,D_B).H_u(m′_C,m″_C) To obtain the state quantity psi of Charlie_C. At the same time, Charlie can also calculate hash values

Charlie then computes the VES signature result

Constructing a message m_C＝(m₀,m′_C,Λ_Charlie,m″_C,ψ_C) Calculate m_CDigital signature ofSending message signature pairsTo the TTP.

Step S1104: TTP authentication

Whether the VES signatures of all the participants contained in the software are correct or not, if so, the protocol is continuously executed, and if not, the software exits. The hash operation required when the TTP verifies the VES signature is completed according to the similar process of each signer. The TTP then uses its stored VES private key to sign Λ from Alice's VES_AliceThe common signature delta of Alice is obtained by medium decryption_AliceD 'of structure'_A＝(m₀,m′_A,δ_Alice,m″_A) To obtainD′_AState quantity of ψ'_A＝H_i(ζ).H_u(D′_A) Then comparing ψ'_AAnd m_APhi in_AIf they are consistent, verify psi_AThe correctness of the operation. By analogy, verify psi_BAnd psi_CThe correctness of the operation. If all are correct, the TTP indicates Alice and the protocol can continue to be executed, i.e. a protocol execution message is sent to the first participant. After the TTP obtains, the TTP stores the received script in a database.

Step S1105: alice sends the digital signature result delta of itself_AliceTo Bob.

Step S1106: bob verifies delta_AliceVerifying the digital signature results delta of each participant before transmission after passing_AliceAnd its own digital signature result delta_BobGiving Charlie, otherwise, requiring arbitration.

Step S1107: digital signature delta of each participant before Charlie verification_Alice、δ_BobAnd synthesizing a final contract after the verification is passed, and returning the final contract to the last participant Bob, otherwise, requiring arbitration.

Step S1108: and after receiving the final contract returned by the Charlie, Bob verifies the final contract, forwards the final contract to the previous participant Alice after passing the verification, and otherwise, requires arbitration.

Step S1109: alice receives Bob and returns the final contract, verifies the final contract, and requests arbitration if verification is in error.

As noted above, in the implementation of the specific example above, any participant may require arbitration at any time. In one example of an application, the arbitration protocol may be set as follows.

Assuming that party X requires arbitration, party X submits the original contract text m to the TTP when arbitration is required₀Request arbitration. The trusted third party TTP checks the entry in the database if m does exist₀The common signature is recovered from the VES signatures of each message, all participants are contacted, and the final PDF document containing the signatures of each party is sent to all participants.

On the other hand, the trusted third party TTP may set a maximum duration of contract subscription, for example, one month, and store the communication script corresponding to the contract in the database. When the communication script exceeds the time limit, the trusted third party can automatically delete the script to avoid the infinite increase of the database.

Based on the multiparty fair contract signing agreement based on the 'online' TTP in the specific example, the efficiency and the fairness are well balanced, and even if the number of the participants is larger than three, the execution process of the agreement can be expanded trivially.

In a specific application example, the messages sent by each participant to the TTP of the trusted third party may also include the original text m₀But rather contains the original text m₀Corresponding state quantity psi₀. At this time, the trusted third party TTP and other participants need to utilize the state quantity ψ₀To calculate summary information. When a participant requests arbitration, the participant should submit a state quantity ψ corresponding to an original text to the TTP₀。

In another application of this specific example, after the step S1104, the trusted third party TTP may recover the VES signatures of all the participants, construct a complete document containing the signatures of all the participants, and send the complete document to all the participants. Therefore, all the participants can be prevented from executing the second round of interaction, and the efficiency of executing the protocol is further improved.

In another application manner of this specific example, when a broadcast channel is allowed, each participant may also need to broadcast a message only once, wait for a signal of the trusted third party TTP, and when receiving the signal of the trusted third party TTP, each participant broadcasts its own true signature value again, and then the trusted third party may synthesize a final contract text, so as to further improve execution efficiency.

In another application example, it may not be necessary to obtain the original text δ containing the signature in the service scenario_X(e.g., using a custom PDF reader to verify the validity of the VES signature without obtaining a standard format PDF document), the trusted third party TTP may be only one party involvedRecovery of signature text delta when party initiates arbitration flow_XWhile the use of the private key to recover the signature text is not allowed in the phase of performing fair contract signing. Under the condition, the TTP of the trusted third party can implement stricter authority control measures, the private key for recovering the signature original text is limited to be used only in an arbitration process, and the attack from internal management personnel is further avoided.

Based on the scheme of determining the data digest of the message, the scheme of digital signature based on multiparty signature, and the scheme of fair signing of the electronic contract based on the above-described specific examples, the hash function state quantity ψ corresponding to the electronic contract file is calculated by the participants or TTPs and shared to the other participants or TTPs so that each participant or TTP can construct a virtual file, and the digest information of the file to be signed is calculated by means of the hash function state quantity ψ, thereby completing the process of sequential signing. Based on the mechanism of the distributed computing hash function, the TTP can store the digital signature of the participant and does not send the digital signature to the subsequent participants, so that the fair signing of the electronic contract is realized. And fair signing can be completed by using VES signatures among all the participants, and each participant can complete the self signing process under the condition that other participant digital signature original texts are not obtained, so that the goal of fair signing of the electronic contract is achieved. Based on the mechanism of the distributed hash calculation function, the electronic contract original data can be encrypted, and the TTP can assist all the participants to complete fair signing of the electronic contract under the condition that the electronic contract original data is unknown, so that the privacy of the electronic contract file is ensured. All the processes of electronic contract encryption and fair signing can ensure that the generated electronic contract file conforms to the format requirements of the PDF document for multi-party digital signatures.

Based on the same idea as the method, the embodiment of the invention also provides a system for determining the data abstract of the message and a digital signature system based on the multi-party signature, and the electronic contract fair signing based on the multi-party signature is realized according to the digital signature system based on the multi-party signature.

FIG. 12 illustrates a block diagram of a system that determines a data digest for a message, in one embodiment. As shown in fig. 12, the system for determining a data digest of a message in this embodiment includes:

an information obtaining module 121, configured to obtain a message to be processed and a state quantity of a hash function;

a first initialization module 122, configured to perform initialization operation by using an initialization algorithm of the hash function according to the state quantity of the hash function, and initialize a context of hash function operation;

a state quantity output module 123, configured to output a context of hash function operation as a hash function state quantity;

and an ending processing module 124, configured to execute an ending operation of the hash function by using an ending algorithm of the hash function, so as to obtain the digest information of the message to be processed.

In a specific example, as shown in fig. 12, the system in this embodiment may further include:

and the message updating module 1223 is configured to perform a message updating operation on the to-be-processed message by using a message updating algorithm of the hash function based on the state quantity of the hash function, so as to obtain an updated context of the hash function operation.

In this case, the state quantity output module 123 outputs the context of the updated hash function operation as the hash function state quantity.

In a specific example, the message update module 1223 may perform the message update operation on at least one data segment of the message to be processed by using a message update algorithm of a hash function.

The system for determining the data digest of the message as described above can be applied to a system for digital signatures based on multi-party signatures, so as to output the state quantity of the hash function in the process of calculating the data digest of the message, and then perform digital signatures based on the output state quantity of the hash function, and then perform signing of multi-party electronic contracts based on multi-party signatures.

Fig. 13 is a schematic structural diagram of a digital signature system based on multi-party signature in an embodiment, which is described by taking a system of a participant application as an example. As shown in fig. 13, the multi-party signature based digital signature system in this embodiment includes;

the file acquisition module 131 is used for acquiring or constructing a file to be signed;

a first state quantity determining module 132, configured to determine a hash function state quantity corresponding to the file to be signed;

a second initialization module 133, configured to initialize a context of hash function operation according to the hash function state quantity;

the digest determining module 134 is configured to execute a hash function ending operation by using a hash function ending algorithm to obtain a data digest of the file to be signed;

the digital signature module 135 is configured to perform a digital signature operation according to the data digest of the file to be signed, so as to obtain a digital signature result.

The hash function state quantity obtained in the above embodiment scheme can be transmitted to other parties based on a document or message transmission manner to complete information transmission, so as to complete signing of the electronic contract based on multi-party signature.

In an application example, when the current participant is the first participant, the document to be signed may be the original document data to be signed. At this time, the hash function state quantity corresponding to the file to be signed determined by the first state quantity determination module 132 may be a hash function state quantity corresponding to the original file data to be signed, which is calculated from the original file data to be signed (in order to distinguish the hash function state quantities corresponding to the file having the added data of the current participant, it is referred to as a first hash function state quantity in the following embodiments). At this time, the hash function state quantity corresponding to the file to be signed is the first hash function state quantity. That is, the first state quantity determining module 132 obtains a first hash function state quantity corresponding to the original document data to be signed by calculation according to the original document data to be signed; the hash function state quantity corresponding to the file to be signed is the first hash function state quantity.

In a specific application example, as shown in fig. 13, the multi-party signature based signature system may further include: an adding data obtaining module 1311, configured to obtain adding data of the current participant to the file to be signed.

At this time, the file to be signed includes the added data acquired by the added data acquisition module 1311. And when the current participant is the first participant, the file to be signed comprises the original file data to be signed and the added data.

In this case, the hash function state quantity determined by the first state quantity determination module 132 is a hash function state quantity calculated for the file to be signed including the added data.

When the current participant is the first participant, the first state quantity determining module 132 calculates and obtains a first hash function state quantity corresponding to the original file data to be signed; and determining a second hash function state quantity according to the first hash function state quantity and the added data. In this case, the hash function state quantity corresponding to the file to be signed is the second hash function state quantity, and the second initialization module 133 may initialize the context of hash function operation according to the second hash function state quantity.

After determining to obtain the data digest of the file to be signed and obtain the digital signature result based on the hash function state quantity, the related hash function state quantity or the related information based on the hash function state quantity can be transmitted to the next participant based on the trusted third party TTP or directly transmitted to the next participant. Different ways, such as encryption of the shared key of each participant, VES signature, can also be combined in the transfer process. The following is illustrative of several specific examples thereof.

Fig. 14 is a schematic structural diagram of a multi-party signature based digital signature system in a specific example. In this specific example, a system used by the participant (or an application, a system provided at the participant) is taken as an example for explanation, and after each participant transfers relevant information based on the state quantity of the hash function to the trusted third party, the trusted third party TTP transfers the relevant information to the next participant.

As shown in fig. 14, the system in this example may further include, on the basis of the system shown in fig. 13;

the document generating module 141 is configured to, when the current party is the first party, add the digital signature result to the file to be signed to obtain a document with a digital signature of the current party, and send the document with the digital signature of the current party to a trusted third party.

In an application example, as shown in fig. 14, the system in this specific example may further include:

a first message sending module 142, configured to send a second uplink message to the trusted third party when the current party is not the first party, where the second uplink message includes the digital signature result, or the second uplink message includes the digital signature result and the addition data of the current party.

and the first document receiving module 143 is configured to receive a final signature composite document sent by the trusted third party after the last party is authenticated.

a first message receiving module 144, configured to receive a downlink message sent by a TTP of a trusted third party, where the downlink message includes the hash function state quantity when the current participant is not a first participant, or the downlink message includes the hash function state quantity and data added to the file to be signed by each previous participant, where the hash function state quantity is a hash function state quantity corresponding to the file to be signed by a previous participant after being signed by the previous participant, and each previous participant includes the previous participant.

At this time, the file obtaining module 131 may construct the file to be signed according to the downlink message, and at this time, the file to be signed is a virtual file.

Fig. 15 is a schematic structural diagram showing a multi-party signature based digital signature system in a second specific example. The specific example is described by taking a system used by the participants (or an application, a system set at the participants) as an example, and after each participant transmits the relevant information based on the state quantity of the hash function to the trusted third party, the relevant information is transmitted to the next participant by the trusted third party TTP, and the original file data to be signed is encrypted based on the shared key of each participant.

As shown in fig. 15, the system in this example may further include, on the basis of the system shown in fig. 13;

a shared key encryption module 151, configured to encrypt the to-be-signed file by using a shared key negotiated by each participant when the current participant is a first participant, so as to obtain an encrypted to-be-signed file;

a first message sending module 152, configured to send a first uplink message to the trusted third party when the current party is the first party, where the first uplink message includes the encrypted file to be signed, the first hash function state quantity, and the digital signature result, or the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the digital signature result, and the added data of the current party.

At this time, when the current participant is the first participant, the first state quantity determining module 132 calculates and obtains the first hash function state quantity corresponding to the original file data to be signed; and determining a second hash function state quantity according to the first hash function state quantity and the added data.

In an application example, as shown in fig. 15, the system in this specific example may further include:

a second document receiving module 153, configured to receive an initial signature synthesized document sent by a trusted third party after the last party is verified, where the initial signature synthesized document is a synthesized document determined by the trusted third party based on a digital signature result of each party;

and the first final document synthesis module 154 is configured to synthesize a final signature synthesis document according to the original to-be-signed document data and the initial signature synthesis document stored in the first final document synthesis module.

the first message receiving module 155 is configured to receive a downlink message sent by a trusted third party, where the downlink message includes the hash function state quantity and a first hash function state quantity when the current participant is not a first participant, or the downlink message includes the hash function state quantity, the first hash function state quantity, and data added to the file to be signed by each previous participant, where the hash function state quantity is a state quantity of a hash function corresponding to the file signed by the previous participant, the first hash function state quantity is a state quantity of a hash function corresponding to the original file data to be signed, and each previous participant includes the previous participant.

In this case, as shown in fig. 15, the system in this specific example may further include:

and the state quantity verification module 156 is configured to verify the state quantity of the first hash function in the downlink message according to the original file data to be signed stored in the state quantity verification module.

Fig. 16 is a schematic structural diagram of a multi-party signature based digital signature system in a third specific example. In this specific example, a system used by the participant (or an application, a system set at the participant) is taken as an example for explanation, and VES signature is performed in the information transfer process to improve security.

As shown in fig. 16, the system in this example may further include, on the basis of the system shown in fig. 13;

and the VES signature module 161 is configured to perform VES signature processing on the digital signature result to obtain a VES signature result.

In an application example, as shown in fig. 16, the system in this specific example may further include a first message sending module 162.

When the current participant is the first participant, the first message sending module 162 is configured to send a first uplink message to the trusted third party, where the first uplink message includes the VES signature result and the original file data to be signed. In the case that the current participant adds data, the first uplink message may further include the added data of the current participant, that is, the first uplink message includes the VES signature result, the original file data to be signed, and the added data of the current participant.

On the other hand, when the current party is not the first party, the first message sending module 162 is configured to send a second uplink message to the trusted third party, where the second uplink message includes the VES signature result. In the case that the current participant adds data, the second uplink message may further include the added data of the current participant, that is, the second uplink message includes the VES signature result and the added data of the current participant.

In an application example, as shown in fig. 16, the system in this specific example may further include:

the first document receiving module 163 is configured to receive a final signed composite document sent by the trusted third party after the last participant is authenticated.

the first message receiving module 164 is configured to receive a downlink message sent by a trusted third party, where the downlink message includes the hash function state quantity when the current participant is not the first participant, or the downlink message includes the hash function state quantity and data added to the file to be signed by each previous participant, where the hash function state quantity is a hash function state quantity corresponding to the file to be signed after the previous participant signs, and each previous participant includes the previous participant.

At this time, the file obtaining module 131 may conceptually construct the file to be signed according to the downlink message, where the file to be signed is a virtual file.

Fig. 17 is a schematic structural diagram of a multi-party signature based digital signature system in a fourth specific example. In this specific example, a system used by a participant (or a system applied to or set at the participant) is taken as an example for explanation, the original document data to be signed is encrypted based on the shared key of each participant, and VES signature is performed in the information transfer process to improve security.

As shown in fig. 17, the system in this example may further include, on the basis of the system shown in fig. 13;

the VES signature module 171 is configured to perform VES signature processing on the digital signature result to obtain a VES signature result when the current participant is the first participant;

and the shared key encryption module 172 is configured to encrypt the to-be-signed file by using the shared key negotiated by each participant when the current participant is the first participant, so as to obtain the encrypted to-be-signed file.

In an application example, as shown in fig. 17, the system in this specific example may further include a first message sending module 173.

When the current participant is the first participant, the first message sending module 173 is configured to send a first uplink message to the trusted third party, where the first uplink message includes the encrypted file to be signed, the first hash function state quantity, and the VES signature result. When the current participant adds data, the first uplink message may further include the added data of the current participant, that is, the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the VES signature result, and the added data of the current participant.

When the current participant is not the first participant, the first message sending module 173 is configured to send a second uplink message to the trusted third party, where the second uplink message includes the VES signature result. In the case that the current participant adds data, the second uplink message may further include the added data of the current participant, that is, the second uplink message includes the VES signature result and the added data of the current participant.

In an application example, as shown in fig. 17, the system in this specific example may further include:

a second document receiving module 174, configured to receive an initial signature synthesized document sent by a trusted third party after the last party is verified, where the initial signature synthesized document is a synthesized document determined by the trusted third party based on a digital signature result of each party;

and the first final document synthesis module 175 is configured to synthesize a final signature synthesis document according to the original to-be-signed document data and the initial signature synthesis document stored in the first final document synthesis module.

the first message receiving module 176 is configured to receive a downlink message sent by a trusted third party, where the downlink message includes the hash function state quantity and a first hash function state quantity when the current participant is not a first participant, or the downlink message includes the hash function state quantity, the first hash function state quantity and data added to the file to be signed by each previous participant, the hash function state quantity is a state quantity of a hash function corresponding to the file signed by the previous participant, the first hash function state quantity is a state quantity of a hash function corresponding to the original file data to be signed, and each previous participant includes the previous participant.

In this case, as shown in fig. 17, the system in this example may further include:

and the state quantity verification module 177 is configured to verify the state quantity of the first hash function in the downlink message according to original file data to be signed stored in the state quantity verification module.

Fig. 18 shows a schematic structural diagram of a multi-party signature based digital signature system in a fifth specific example. In this specific example, a system used by the participants (or a system applied to and set in the participants) is taken as an example for explanation, and after each participant directly transfers related information based on the state quantity of the hash function to the next participant, the TTP of the trusted third party only needs to receive a message sent by the last participant for verification processing.

As shown in fig. 18, the system in this example may further include, on the basis of the system shown in fig. 13;

and the document generating module 181 is configured to add the digital signature result to the file to be signed to obtain a document after the current participant digital signature.

And the document state quantity determining module 182 is configured to determine a hash function state quantity of the digitally signed document of the current participant.

And the VES signature module 183 is configured to perform VES signature processing on the digital signature result to obtain a VES signature result.

A message constructing module 184, configured to construct a current participant signature message based on the hash function state quantity of the document after the current participant digital signature, the VES signature result, and the original to-be-signed file data; in one particular application, where the current participant adds data, the current participant signature message may also include the current participant's added data.

A message signature calculation module 185 for calculating a message signature of the current participant signature message.

A signed message pair sending module 186, configured to send a signed message pair to a next participant, where the signed message pair includes a first signed message pair of the current participant, and the first signed message pair includes a current participant signed message and a message signature of the current participant signed message. When the current participant is not the first participant, the signed message pair may further include signed message pairs of previous participants.

In an application example, as shown in fig. 18, the system in this specific example may further include:

first signed-message-pair receiving module 187 is configured to receive the signed-message pair sent by the previous participant, where the signed-message pair sent by the previous participant includes: and the signature message pair of each participant before the current participant comprises the signature message of each previous participant and the message signature of each previous participant signature message, and each previous participant signature message comprises the hash function state quantity of the document after the digital signature of each previous participant, the VES signature result of each previous participant and the original file data to be signed. In one application example, where previous participants added data, previous participant signature messages may also include the added data of previous participants.

On this basis, the system in this specific example may further include:

and a signature verification module 188, configured to verify the message signatures and VES signature results of previous participants included in the signed message pair sent by the previous participant after the first signed message pair receiving module receives the signed message pair sent by the previous participant.

a first message receiving module 189, configured to receive, when the current participant is a first participant, a protocol execution message returned by a trusted third party after receiving a message signature pair sent by a last participant; and sending the digital signature result of the current participant to the next participant according to the protocol execution message.

a digital signature receiving and verifying module 1810, configured to receive, when the current participant is not the first participant, a digital signature result of each previous participant sent by a previous participant; and after the digital signature results of the previous participants are verified, sending the digital signature result of the current participant to the next participant.

a second final document composition module 1811, configured to determine a final signature composition document after the digital signature result of each previous participant is verified when the current participant is the last participant, and send the final signature composition document to the previous participant.

a final document returning module 1812, configured to receive a final signature composite document sent by a next participant when the current participant is not the first participant; and sending the final signed composite document to the previous party if the current party is not the first party.

Fig. 19 is a schematic structural diagram of a digital signature system based on multi-party signature in another embodiment, which is described by taking a system applied by a trusted third party TTP, or a system application or setting in the trusted third party TTP as an example, and each participant sends its own digital signature result to the trusted third party TTP.

As shown in fig. 19, the multi-party signature based signature system in this embodiment includes:

a second message receiving module 191, configured to receive a second uplink message sent by a previous participant, where the second uplink message includes a digital signature result of the previous participant;

a second document synthesis module 192, configured to synthesize a document digitally signed by the previous participant according to the second uplink message;

a second state quantity determining module 193, configured to calculate a hash function state quantity of the digitally signed document of the previous party after verifying the digital signature of the previous party;

and a second message sending module 194, configured to send a downstream message to a next participant, where the downstream message includes a hash function state quantity of a document digitally signed by the previous participant.

In a specific application example, the second message receiving module 192 is further configured to receive a first participant digitally signed document sent by a first participant, where the first participant digitally signed document includes original document data to be signed and a digital signature of the first participant.

In a specific application example, the second state quantity determining module 193 is further configured to calculate a hash function state quantity of the document after the digital signature of the first participant is verified in the document after the digital signature of the first participant is digitally signed.

In a specific application example, the second message sending module 194 is further configured to send a downlink message to a next participant, where the downlink message includes a hash function state quantity of the document digitally signed by the first participant.

In a specific application example, the second message receiving module 191 is further configured to receive a first uplink message sent by a first participant, where the first uplink message includes: the method comprises the steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a digital signature result of the first participant.

On this basis, in an application example, the second document synthesis module 192 is further configured to conceptually synthesize the digitally signed document of the first participant according to the first uplink message.

At this time, the second state quantity determining module 193 is further configured to calculate a hash function state quantity of the document digitally signed by the first participant after verifying the digital signature of the first participant.

On this basis, the second message sending module 194 is further configured to send a downlink message to the next participant, where the downlink message includes: a hash function state quantity of the document after the digital signature of the first participant, and the first hash function state quantity.

In an application example, as shown in fig. 19, the system in this specific example may further include:

a third final document synthesis module 195, configured to synthesize a final signature synthesis document according to the second uplink message when the previous party is the last party; and after the digital signature of the last party is verified to pass, sending the final signature composite document to each party.

and an initial document synthesis module 196, configured to, when the previous party is the last party, conceptually synthesize a document digitally signed by the previous party according to the second uplink message, verify that the digital signature of the last party passes the verification according to the document digitally signed by the previous party, synthesize an initial signature synthesis document according to the digital signature result of each party, send the initial signature synthesis document to each party, and synthesize a final signature synthesis document according to the original to-be-signed document data and the initial signature synthesis document stored by each party.

Fig. 20 is a schematic structural diagram of a digital signature system based on multi-party signature in another embodiment, which is described by taking a system applied by a trusted third party TTP, or a system application or setting up on the trusted third party TTP as an example, and each participant performs VES signature.

As shown in fig. 20, the multi-party signature based signature system in this embodiment includes:

a second message receiving module 201, configured to receive a second uplink message sent by a previous party, where the second uplink message includes a VES signature result of the previous party; in the case that the previous party added data, the second uplink message may further include the added data of the previous party;

the VES decryption module 202 is configured to decrypt the VES signature result of the previous party to obtain a digital signature result of the previous party;

the second state quantity determining module 203 is configured to calculate a hash function state quantity of the document digitally signed by the previous party after verifying the digital signature result of the previous party;

a second message sending module 204, configured to send a downstream message to a next participant, where the downstream message includes a hash function state quantity of a document digitally signed by the previous participant, and where, in a case where data is added by previous participants, the downstream message may further include added data of the previous participants.

In an application example, the second message receiving module 201 is further configured to receive a first uplink message sent by a first participant, where the first uplink message includes: the original document data to be signed, and the VES signature result of the first party. In the case where the first party has added data, the first upstream message may also include the added data of the first party.

At this time, the VES decryption module 202 is further configured to decrypt the VES signature result of the first party to obtain the digital signature result of the first party. In the case where the first party has added data, the digitally signed document of the first party may also include the added data of the first party

In an application example, as shown in fig. 20, the system in this specific example may further include;

and the second document synthesis module 205 is configured to synthesize the document digitally signed by the first party according to the original document data to be signed and the digital signature result of the first party.

In this case, the second state quantity determining module 203 is further configured to calculate a hash function state quantity of the document after the digital signature of the first participant is verified.

At this time, the second message sending module 204 is further configured to send a downlink message to the next participant, where the downlink message includes: the hash function state quantity of the document after the digital signature of the first participant.

In an application example, the second message receiving module 201 is further configured to receive a first uplink message sent by a first participant, where the first uplink message includes: the method comprises the steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a VES signature result of the first participant.

At this time, the VES decryption module 202 is further configured to decrypt the VES signature result of the first party to obtain the digital signature result of the first party.

At this time, the second document synthesis module 205 is further configured to conceptually synthesize the document digitally signed by the first party according to the digital signature result of the first party;

the second state quantity determining module 203 is further configured to calculate a hash function state quantity of the document after the digital signature of the first party is verified;

the second message sending module 204 is further configured to send a downlink message to the next participant, where the downlink message includes: the hash function state quantity of the document after the digital signature of the first participant, and the hash function state quantity of the first hash function state quantity.

In an application example, as shown in fig. 20, the system in this specific example may further include:

a third final document synthesis module 206, configured to synthesize a final signature synthesis document according to the second uplink message when the previous party is the last party; and after the digital signature of the last party is verified to pass, sending the final signature composite document to each party.

and an initial document synthesis module 207, configured to, when the previous party is the last party, conceptually synthesize a document digitally signed by the previous party according to the second uplink message, verify that the digital signature of the last party passes the verification according to the document digitally signed by the previous party, synthesize an initial signature synthesis document according to the digital signature result of each party, send the initial signature synthesis document to each party, and synthesize a final signature synthesis document by each party according to the original to-be-signed document data stored by each party and the initial signature synthesis document.

Fig. 21 shows a schematic structural diagram of a multi-party signature based signature system in another embodiment, which is illustrated by taking the example of a system applied by, or provided in, a trusted third party TTP, and the trusted third party interacts with only the last party in the electronic contract signing process.

As shown in fig. 21, the system in this embodiment includes:

a second signature message pair receiving module 211, configured to receive a signature message pair sent by the last participant, where the signature message pair includes each participant signature message and a message signature of each participant signature message, and each participant signature message includes a hash function state quantity of a document after digital signature of each participant, a VES signature result of each participant, and original file data to be signed;

the signature message pair verification module 212 is configured to verify VES signature results of each participant, and determine correctness of hash function state quantities of the digitally signed documents of each participant according to the verification results;

an execution message sending module 213, configured to send a protocol execution message to a first participant when the hash function state quantity of the digitally signed document of each participant passes verification, where the first participant sends the digital signature result of the first participant to a next participant, and each participant receives the digital signature result of a previous participant, and after the digital signature result of each previous participant passes verification, the last participant sends the digital signature result of the current participant to the next participant, and after the digital signature result of each previous participant passes verification, determines a final signature composite document, and returns the final signature composite document to each previous participant in sequence.

It is to be understood that other features not described in detail in the embodiments of the system described above may be the same as in the embodiments of the method described above, for reasons of space.

It can be understood by those skilled in the art that based on the above descriptions of the application examples, the above embodiments can be combined in any possible way to obtain a suitable scheme for digitally signing and electronically signing the document for application to practical technical applications, and therefore, any combination of schemes that can be obtained based on the above embodiments and the schemes in the following specific examples should be included in the protection scope of the present invention.

The technical features of the embodiments described above may be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the embodiments described above are not described, but should be considered as being within the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above-mentioned embodiments only express several embodiments of the present invention, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the inventive concept, which falls within the scope of the present invention. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A digital signature method based on multi-party signature is characterized by comprising the following steps:

the current participant acquires or constructs a file to be signed;

executing digital signature operation according to the data abstract of the file to be signed to obtain a digital signature result; when the current participant is the first participant,

the file to be signed comprises original file data to be signed and added data;

the mode for determining the hash function state quantity corresponding to the file to be signed comprises the following steps: calculating to obtain a first hash function state quantity corresponding to the original file data to be signed; determining a second hash function state quantity according to the first hash function state quantity and the added data;

the hash function state quantity corresponding to the file to be signed is the second hash function state quantity;

and initializing the context of hash function operation according to the second hash function state quantity.

2. The multi-party signature based digital signature method as claimed in claim 1, further comprising the steps of, after obtaining the digital signature result when the current party is the first party:

adding the digital signature result to the file to be signed to obtain a current participant digital signature document, and sending the current participant digital signature document to a trusted third party;

or

Performing VES signature processing on the digital signature result to obtain a VES signature result;

and sending a first uplink message to a trusted third party, wherein the first uplink message comprises the VES signature result and the original file data to be signed, or the first uplink message comprises the VES signature result, the original file data to be signed and the added data of the current participant.

3. The multi-party signature based digital signature method as claimed in claim 1, further comprising the steps of, when the current party is the first party:

encrypting the file to be signed by adopting a shared secret key negotiated by each participant to obtain the encrypted file to be signed; sending a first uplink message to a trusted third party, wherein the first uplink message comprises the encrypted file to be signed, the first hash function state quantity and the digital signature result, or the first uplink message comprises the encrypted file to be signed, the first hash function state quantity, the digital signature result and the added data of the current participant;

or

encrypting the file to be signed by adopting a shared secret key negotiated by each participant to obtain the encrypted file to be signed;

and sending a first uplink message to a trusted third party, wherein the first uplink message comprises the encrypted file to be signed, the first hash function state quantity and the VES signature result, or the first uplink message comprises the encrypted file to be signed, the first hash function state quantity, the VES signature result and the added data of the current participant.

4. The multi-party signature based digital signature method as claimed in claim 2, further comprising the steps of, after obtaining the digital signature result, when the current party is not the first party:

sending a second uplink message to the trusted third party, wherein the second uplink message comprises the digital signature result, or the second uplink message comprises the digital signature result and the adding data of the current participant;

or

and sending a second uplink message to a trusted third party, wherein the second uplink message comprises the VES signature result, or the second uplink message comprises the VES signature result and the adding data of the current participant.

5. The multi-party signature based digital signature method of claim 4, wherein:

when the current participant is not the first participant, before the current participant constructs the document to be signed, the method further comprises the following steps: receiving a downlink message sent by the trusted third party, where the downlink message includes the hash function state quantity, or the downlink message includes the hash function state quantity and data added to the file to be signed by each previous party, where the hash function state quantity is a hash function state quantity corresponding to the file to be signed after being signed by the previous party, and each previous party includes the previous party;

and the current participant conceptually constructs the file to be signed according to the downlink message, wherein the file to be signed is a virtual file.

6. The multi-party signature based digital signature method as claimed in claim 5, wherein before the current party constructs the document to be signed when the current party is not the first party, further comprising the steps of:

receiving a downlink message sent by a trusted third party, where the downlink message includes the hash function state quantity and a first hash function state quantity, or the downlink message includes the hash function state quantity, the first hash function state quantity and data added to the file to be signed by each previous participant, where the hash function state quantity is a state quantity of a hash function corresponding to the file signed by the previous participant, the first hash function state quantity is a state quantity of a hash function corresponding to the original file data to be signed, and each previous participant includes the previous participant.

7. The multi-party signature based digital signature method as claimed in claim 6, further comprising the steps of, after receiving said downstream message:

and verifying the state quantity of the first hash function according to the original file data to be signed stored in the first hash function.

8. The multi-party signature based digital signature method as claimed in claim 7, further comprising the steps of: and receiving a final signature composite document sent by the trusted third party after the last participant is verified.

9. The multi-party signature based digital signature method as claimed in claim 8, further comprising the steps of:

receiving an initial signature synthetic document sent by a trusted third party after the last party is verified, wherein the initial signature synthetic document is a synthetic document determined by the trusted third party based on digital signature results of all parties;

and synthesizing a final signature synthesized document according to the original document data to be signed and the initial signature synthesized document stored in the self.

10. The multi-party signature based digital signature method as claimed in claim 1, further comprising the steps of, after obtaining the digital signature result:

adding the digital signature result to the file to be signed to obtain a current participant digital signature document;

determining the state quantity of a hash function of the document after the digital signature of the current participant;

constructing a current participant signature message based on the hash function state quantity of the document after the current participant digital signature, the VES signature result and the original document data to be signed;

calculating a message signature of the current participant signature message;

sending a signed message pair to a next participant, the signed message pair comprising a first signed message pair for the current participant, the first signed message pair comprising the current participant signed message, a message signature for the current participant signed message.

11. The multi-party signature based digital signature method as claimed in claim 10, further comprising the steps of, before the current party constructs the document to be signed, when the current party is not the first party:

receiving the signed message pair sent by the previous party, wherein the signed message pair sent by the previous party comprises: and the signature message pair of each previous participant comprises the signature message of each previous participant and the message signature of the signature message of each previous participant, and each previous participant signature message comprises the hash function state quantity of the document after the digital signature of each previous participant, the VES signature result of each previous participant and the original file data to be signed.

12. The multi-party signature based digital signature method of claim 11, comprising any one or any combination of the following:

the current participant signature message further includes the add data of the current participant;

when the current participant is not the first participant, the signed message pair further comprises signed message pairs of previous participants;

the signature message of each previous participant also comprises the adding data of each previous participant;

after receiving the signed message pair sent by the previous participant, the method further comprises the following steps: verifying the message signature and VES signature results of each previous party;

when the current participant is the first participant, further comprising the steps of: receiving a protocol execution message returned by the trusted third party after receiving the message signature pair sent by the last participant; sending the digital signature result of the current participant to the next participant according to the protocol execution message;

when the current participant is not the first participant, further comprising the steps of: receiving the digital signature result of each previous participant sent by the previous participant; after the digital signature result of each previous participant passes verification, sending the digital signature result of the current participant to the next participant;

when the current participant is the last participant, further comprising the steps of: receiving the digital signature result of each previous participant sent by the previous participant; after the digital signature result of each previous participant passes verification, determining a final signature composite document, and sending the final signature composite document to the previous participant;

when the current participant is not the first participant and not the last participant, further comprising the steps of: receiving a final signature composite document sent by the next participant; sending the final signed composite document to an upper party;

when the current participant is the first participant, further comprising the steps of: the final signed composite document sent by the next participant is received.

13. A digital signature method based on multi-party signature is characterized by comprising the following steps:

a trusted third party receives a second uplink message sent by a previous party, wherein the second uplink message comprises a digital signature result of the previous party;

14. A digital signature method based on multi-party signature is characterized by comprising the following steps:

a trusted third party receives a second uplink message sent by a previous party, wherein the second uplink message comprises a VES signature result of the previous party;

15. The multi-party signature based digital signature method according to claim 13 or 14, wherein:

before the trusted third party receives the second uplink message sent by the previous party, the method further comprises the following steps:

receiving a document which is sent by a first participant and is digitally signed by the first participant, wherein the document which is digitally signed by the first participant comprises original document data to be signed and a digital signature of the first participant;

after the digital signature of the first participant in the document subjected to the digital signature of the first participant is verified, calculating the state quantity of a hash function of the document subjected to the digital signature of the first participant;

sending a downlink message to a next participant, wherein the downlink message comprises the hash function state quantity of the document after the digital signature of the first participant;

or

receiving a first uplink message sent by a first participant, the first uplink message comprising: the method comprises the following steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a digital signature result of the first participant;

conceptually synthesizing the document after the digital signature of the first participant according to the first uplink message;

after the digital signature of the first participant is verified, calculating the state quantity of a hash function of the document after the digital signature of the first participant is verified;

sending a downstream message to a next participant, the downstream message comprising: the hash function state quantity of the document after the digital signature of the first participant and the first hash function state quantity;

or

receiving a first uplink message sent by a first participant, the first uplink message comprising: original document data to be signed and VES signature result of the first participant;

decrypting the VES signature result of the first party to obtain a digital signature result of the first party;

synthesizing a document digitally signed by a first participant according to the original document data to be signed and the digital signature result of the first participant;

sending a downstream message to a next participant, the downstream message comprising: the hash function state quantity of the document after the digital signature of the first participant;

or

receiving a first uplink message sent by a first participant, the first uplink message comprising: the method comprises the following steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a VES signature result of the first participant;

conceptually synthesizing the document after the digital signature of the first party according to the digital signature result of the first party;

sending a downstream message to a next participant, the downstream message comprising: a hash function state quantity of the document after the digital signature of the first participant, and the first hash function state quantity.

16. The multiparty signature based digital signature method of claim 15, comprising at least one of:

the second uplink message further comprises the adding data of the previous party;

the downlink message also comprises the added data of each previous participant;

the document after the digital signature of the first party also comprises the added data of the first party;

the first upstream message further comprises the add data of the first party.

17. The multi-party signature based digital signature method as recited in claim 16, wherein:

further comprising the steps of:

when the last participant is the last participant, the trusted third party synthesizes a final signature synthesis document according to the second uplink message;

after the digital signature of the last participant is verified to pass, sending the final signature composite document to each participant;

or

Further comprising the steps of:

when the last participant is the last participant, the trusted third party conceptually synthesizes the document digitally signed by the last participant according to the second uplink message,

and after the digital signature of the last participant passes the verification of the digital signature of the document which is digitally signed by the previous participant, synthesizing an initial signature synthesized document according to the digital signature result of each participant, sending the initial signature synthesized document to each participant, and synthesizing the final signature synthesized document by each participant according to the original document data to be signed and the initial signature synthesized document stored by each participant.

18. A digital signature method based on multi-party signature is characterized by comprising the following steps: receiving a signature message pair sent by the last participant, wherein the signature message pair comprises signature messages of all participants and message signatures of the signature messages of all the participants, and the signature messages of all the participants comprise hash function state quantities of documents after digital signatures of all the participants, VES signature results of all the participants and original file data to be signed;

19. A multi-party signature based digital signature system, comprising:

the digital signature module is used for executing digital signature operation according to the data abstract of the file to be signed to obtain a digital signature result;

the added data acquisition module is used for acquiring added data of the current participant to the file to be signed;

when the current party is a first party, the file to be signed comprises original file data to be signed and the added data;

the first state quantity determining module is used for calculating and obtaining a first hash function state quantity corresponding to the original file data to be signed; determining a second hash function state quantity according to the first hash function state quantity and the added data;

and the second initialization module initializes the context of hash function operation according to the second hash function state quantity.

20. The multi-party signature based digital signature system of claim 19, further comprising:

the document generation module is used for adding the digital signature result to the file to be signed to obtain a document with a digital signature of the current participant when the current participant is the first participant, and sending the document with the digital signature of the current participant to a trusted third party;

or

The shared key encryption module is used for encrypting the file to be signed by adopting a shared key negotiated by all the participants when the current participant is the first participant to obtain the encrypted file to be signed;

a first message sending module, configured to send a first uplink message to a trusted third party when the current party is a first party, where the first uplink message includes the encrypted file to be signed, the first hash function state quantity, and the digital signature result, or the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the digital signature result, and the added data of the current party;

or

The VES signature module is used for performing VES signature processing on the digital signature result to obtain a VES signature result;

a first message sending module, configured to send a first uplink message to a trusted third party when the current party is a first party, where the first uplink message includes the VES signature result and original to-be-signed file data, or the first uplink message includes the VES signature result, the original to-be-signed file data, and added data of the current party;

or

The VES signature module is used for performing VES signature processing on the digital signature result to obtain a VES signature result when the current participant is the first participant;

and the first message sending module is configured to send a first uplink message to the trusted third party when the current participant is a first participant, where the first uplink message includes the encrypted file to be signed, the first hash function state quantity, and the VES signature result, or the first uplink message includes the encrypted file to be signed, the first hash function state quantity, the VES signature result, and the added data of the current participant.

21. The multi-party signature based digital signature system of claim 20, further comprising:

a first message sending module, configured to send a second uplink message to the trusted third party when the current party is not the first party, where the second uplink message includes the digital signature result, or the second uplink message includes the digital signature result and the added data of the current party;

or

The VES signature module is used for performing VES signature processing on the digital signature result to obtain a VES signature result when the current participant is not the first participant;

and the first message sending module is configured to send a second uplink message to a trusted third party when the current party is not the first party, where the second uplink message includes the VES signature result, or the second uplink message includes the VES signature result and the addition data of the current party.

22. The multi-party signature based digital signature system as recited in claim 20, wherein:

the file signing method comprises a first message receiving module and a second message receiving module, wherein the first message receiving module is used for receiving a downlink message sent by the trusted third party, and when the current participant is not a first participant, the downlink message comprises the hash function state quantity, or the downlink message comprises the hash function state quantity and the added data of each previous participant to the file to be signed, the hash function state quantity is a hash function state quantity corresponding to the file to be signed after the previous participant signs, and each previous participant comprises the previous participant;

the file acquisition module is used for conceptually constructing the file to be signed according to the downlink message, and the file to be signed is a virtual file;

or

The file signing method comprises a first message receiving module and a second message receiving module, wherein the first message receiving module is used for receiving a downlink message sent by a trusted third party, when the current participant is not a first participant, the downlink message comprises the hash function state quantity and a first hash function state quantity, or the downlink message comprises the hash function state quantity, the first hash function state quantity and the added data of the file to be signed of each previous participant, the hash function state quantity is the state quantity of a hash function corresponding to the file signed by the previous participant, the first hash function state quantity is the state quantity of the hash function corresponding to the original file data to be signed, and each previous participant comprises the previous participant.

23. The multi-party signature based digital signature system of claim 22, further comprising:

and the state quantity verification module is used for verifying the state quantity of the first hash function in the downlink message according to the original file data to be signed stored in the state quantity verification module.

24. The multi-party signature based digital signature system of claim 20, further comprising:

and the first document receiving module is used for receiving a final signature synthesized document sent by the trusted third party after the last party is verified.

25. The multi-party signature based digital signature system of claim 20, further comprising:

the second document receiving module is used for receiving an initial signature synthetic document sent by a trusted third party after the last party is verified, wherein the initial signature synthetic document is a synthetic document determined by the trusted third party based on the digital signature result of each party;

and the first final document synthesis module is used for synthesizing a final signature synthesis document according to the original file data to be signed and the initial signature synthesis document stored by the first final document synthesis module.

26. The multi-party signature based digital signature system of claim 22, further comprising:

the document generation module is used for adding the digital signature result into the file to be signed to obtain a current participant digital signature document;

the document state quantity determining module is used for determining the hash function state quantity of the document after the digital signature of the current participant;

the message construction module is used for constructing a current participant signature message based on the hash function state quantity of the document after the current participant digital signature, the VES signature result and the original file data to be signed;

the message signature calculation module is used for calculating the message signature of the current participant signature message;

a signed message pair sending module, configured to send a signed message pair to a next participant, where the signed message pair includes a first signed message pair of the current participant, and the first signed message pair includes the current participant signed message and a message signature of the current participant signed message.

27. The multi-party signature based digital signature system of claim 26, further comprising:

a first signed message pair receiving module, configured to receive a signed message pair sent by a previous participant, where the signed message pair sent by the previous participant includes: and the signature message pair of each previous participant comprises the signature message of each previous participant and the message signature of the signature message of each previous participant, and each previous participant signature message comprises the hash function state quantity of the document after the digital signature of each previous participant, the VES signature result of each previous participant and the original file data to be signed.

28. The multi-party signature based digital signature system of claim 27, comprising any one or any combination of the following:

the signature verification module is used for verifying the message signature and VES signature result of each previous participant after the first signature message pair receiving module receives the signature message pair sent by the previous participant;

the first message receiving module is used for receiving a protocol execution message returned by a trusted third party after receiving a message signature pair sent by the last party when the current party is the first party; sending the digital signature result of the current participant to the next participant according to the protocol execution message;

the digital signature receiving and verifying module is used for receiving the digital signature result of each previous participant sent by the previous participant when the current participant is not the first participant; after the digital signature result of each previous participant passes verification, sending the digital signature result of the current participant to the next participant;

the second final document synthesis module is used for determining a final signature synthesis document after the digital signature result of each previous participant passes verification when the current participant is the last participant, and sending the final signature synthesis document to the previous participant;

a final document returning module, configured to receive a final signature composite document sent by a next participant when the current participant is not the first participant; and sending the final signed composite document to the previous party if the current party is not the first party.

29. A digital signature system based on multi-party signature is applied to a trusted third party and comprises the following components:

30. A digital signature system based on multi-party signature is applied to a trusted third party and comprises the following components:

31. The multi-party signature based digital signature system as claimed in claim 29 or 30, wherein:

the second message receiving module is further configured to receive a document sent by a first participant after the digital signature of the first participant, where the document after the digital signature of the first participant includes original document data to be signed and a digital signature of the first participant;

the second state quantity determining module is further used for calculating the hash function state quantity of the document after the digital signature of the first participant is verified in the document after the digital signature of the first participant;

the second message sending module is further configured to send a downlink message to a next participant, where the downlink message includes a hash function state quantity of the document digitally signed by the first participant;

or

The second message receiving module is further configured to receive a first uplink message sent by the first participant, where the first uplink message includes: the method comprises the following steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a digital signature result of the first participant;

the second document synthesis module is also used for conceptually synthesizing the document after the digital signature of the first participant according to the first uplink message;

the second state quantity determining module is further used for calculating the hash function state quantity of the document after the digital signature of the first participant is verified;

a second message sending module, further configured to send a downlink message to a next participant, where the downlink message includes: the hash function state quantity of the document after the digital signature of the first participant and the first hash function state quantity;

or

The second message receiving module is further configured to receive a first uplink message sent by the first participant, where the first uplink message includes: original document data to be signed and VES signature result of the first participant;

the VES decryption module is also used for decrypting the VES signature result of the first participant to obtain a digital signature result of the first participant;

the second document synthesis module is used for synthesizing the document which is digitally signed by the first participant according to the original document data to be signed and the digital signature result of the first participant;

a second message sending module, further configured to send a downlink message to a next participant, where the downlink message includes: the hash function state quantity of the document after the digital signature of the first participant;

or

The second message receiving module is further configured to receive a first uplink message sent by the first participant, where the first uplink message includes: the method comprises the following steps that a first participant encrypts a file to be signed by adopting a shared key negotiated by all participants to obtain an encrypted file to be signed, a first hash function state quantity corresponding to original file data to be signed and a VES signature result of the first participant;

the second document synthesis module is used for conceptually synthesizing the document which is digitally signed by the first participant according to the digital signature result of the first participant;

a second message sending module, further configured to send a downlink message to a next participant, where the downlink message includes: the hash function state quantity of the document after the digital signature of the first participant, and the hash function state quantity of the first hash function state quantity.

32. The multi-party signature based digital signature system of claim 31, comprising at least one of:

the first upstream message further comprises the add data of the first party.

33. The multi-party signature based digital signature system of claim 32, further comprising:

a third final document synthesis module, configured to synthesize a final signature synthesis document according to the second uplink message when the previous party is the last party; after the digital signature of the last participant passes the verification, the final signature composite document is sent to each participant;

or

And the initial document synthesis module is used for conceptually synthesizing a document digitally signed by the previous party according to the second uplink message when the previous party is the last party, synthesizing an initial signature synthesis document according to the digital signature result of each party after the digital signature verification of the last party is passed according to the document digitally signed by the previous party, sending the initial signature synthesis document to each party, and synthesizing a final signature synthesis document by each party according to the original file data to be signed and the initial signature synthesis document stored by each party.

34. A multi-party signature based digital signature system, comprising: