Digital signature with re-randomized pre-signature - Patent Application 20070123633

Abstract

An embodiment of the present invention relates to a computer-implemented method of performing a digital signature. The implemented method includes the steps of computing a pre-signature, receiving a signature request to perform a digital signature on a message, re-randomizing the pre-signature, and performing a digital signature on the message using the re-randomized pre-signature.

Description

[Technical field]

[0001] The present invention relates to a computer-implemented method for performing digital signatures according to a public key signature scheme, and further aspects relate to a corresponding computing system and a corresponding computer program product. [Background technology]

[0002] Digital signatures are used to sign digital messages and involve asymmetric encryption. Digital signatures can be used to verify the authenticity of a digital message or document.

[0003] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) that is based on elliptic curve cryptography. Compared to DSA, ECDSA offers the advantage that the same level of security can be achieved with a shorter public key and digital signature.

[0004] Some of the values ​​calculated in the ECDSA signature algorithm are independent of the message being signed, so they can be precomputed to simplify and speed up the actual signing of the message. Precomputing such values ​​means signing in advance, and the calculated values ​​can be called presignatures.

[0005] However, such pre-signing may have potential security weaknesses. Summary of the Invention [Problem to be solved by the invention]

[0006] In view of the above, it is an object of one aspect of the present invention to provide a computer-implemented method for performing digital signatures that provides enhanced security, particularly when combined with a pre-signature calculation. [Means for solving the problem]

[0007] An embodiment of a first aspect of the invention provides a computer-implemented method for performing a digital signature, the method comprising the steps of computing a pre-signature, receiving a signature request to perform a digital signature on a message, re-randomizing the pre-signature, and performing a digital signature on the message using the re-randomized pre-signature.

[0008] Such re-randomization of pre-signatures provides increased security over simple pre-signatures, in particular by preventing 4-sum attacks, and the additional cost in terms of latency and computation required by such re-randomization is negligible.

[0009] In some embodiments, the pre-signature includes a random element / random portion, and re-randomizing the pre-signature includes re-randomizing the secret random element / random portion. The random element / random portion may in particular be a secret random element / random portion.

[0010] In one embodiment, computing the pre-signature includes computing a random nonce. Such random nonce establishes a random portion of the pre-signature. In such an embodiment, re-randomizing the pre-signature includes re-randomizing the nonce.

[0011] In one embodiment, re-randomizing the pre-signature comprises performing an algebraic operation on the pre-signature. In some embodiments, the algebraic operation may be a linear operation. Algebraic operations, particularly linear operations, can be implemented in an efficient manner, particularly for threshold signatures.

[0012] In some embodiments, the digital signature may be a threshold signature. Such threshold signatures may be used especially in distributed settings involving multiple signing parties.

[0013] Pre-signing is particularly advantageous in such a distributed setting, since pre-signing involves the computation of some secret random value, such as a nonce, and computing and sharing such a secret value is very costly in terms of communication overhead between the parties. Therefore, by pre-computing the random value, the actual signing can be significantly sped up.

[0014] In some embodiments, re-randomizing the pre-signature includes calculating an unpredictable public re-randomization value and utilizing the public re-randomization value to re-randomize the pre-signature.

[0015] In this regard, unpredictable is understood to be unpredictable before the signing request is determined and / or received. The determination may be made before the respective signing entity receives the signing conditions.

[0016] In such an embodiment, the re-randomization utilizes a public re-randomization value that re-randomizes the pre-signature, for example as a coefficient in an algebraic operation.

[0017] A public re-randomization value is to be understood as a value that does not need to be kept secret. In particular, in some embodiments, the public re-randomization value may be assumed to be given to an adversary as the output of a signature request.

[0018] In such a scheme, the re-randomization is public, which provides a particular advantage to threshold signatures: more specifically, the cost required to perform the re-randomization, especially the computational and communication overhead, is significantly less than that of private randomization.

[0019] In one embodiment, the unpredictable public rerandomization value is generated after receiving the signature request.

[0020] In one embodiment, the method further comprises performing a pseudo-random number generation of the public re-randomization value.

[0021] In one embodiment, the method further includes deriving a public re-randomization value from the random beacon.

[0022] Such a random beacon may be generally defined as any publicly available randomness, such as the randomness provided by the computing system or distributed network on which the method is executed, in particular, In some embodiments, such a random beacon may be implemented using a threshold BLS signature scheme, for example as described in U.S. Patent Application Publication No. 2018 / 146035.

[0023] In one embodiment, the method further comprises deriving a public re-randomization value by applying a hash function to at least the message or a hash of the message.

[0024] In one embodiment, a hash function may optionally be applied to the public key in a digital signature and / or to other inputs such as a random beacon.

[0025] In one embodiment, the digital signature is a digital signature based on a discrete logarithm based signature algorithm. In one embodiment, the digital signature is a digital signature based on an elliptic curve based signature algorithm. In one embodiment, the digital signature is an Elliptic Curve Digital Signature Algorithm (ECDSA) digital signature.

[0026] In one embodiment, the method includes providing a master private key pair including a first master private key and a second master private key, and providing a master public key pair including a first master public key and a second master public key, The method further includes deriving a sub private key from the master private key pair, and deriving a sub public key from the master public key pair.

[0027] On the one hand, the derivation of such keys from a master public key pair and the corresponding master private key pair can be performed in a rather efficient manner with significantly reduced computational and communication costs, especially for threshold signatures.

[0028] On the other hand, such a derivation scheme provides a level of security essentially equivalent to a corresponding scheme that does not involve such a derivation scheme.

[0029] Such an implementation allows one to maintain only a single master private key pair, but derive multiple different sub-public / sub-private keys from the master key pair.

[0030] In one embodiment, deriving the sub-private key from the master private key pair includes performing a first algebraic operation on the master private key pair, and deriving the sub-public key from the master public key pair includes performing a second algebraic operation on the master private key pair.

[0031] In some embodiments, the first algebraic operation and the second algebraic operation may be the same.

[0032] In some embodiments, deriving the sub-private key from the master private key pair may include performing key derivation such that the sub-private key depends on both the first master private key and the second master private key, and the sub-public key depends on both the first master public key and the second master public key.

[0033] Such a key derivation technique may be referred to as mixed key derivation.

[0034] In some embodiments, the first algebraic operation and the second algebraic operation are linear operations.

[0035] In one embodiment, the electronic signature algorithm is TIFF2024536213000002.tif7170 and operates on an elliptic curve E generated by a point G of order q, specifically prime order q. Assuming D is the first master public key, D' is the second master public key, d is the first master private key, and d' is the second master private key, the first and second master public keys may be derived from the first and second master private keys as follows:

[0036]

number

[0037] From these master key pairs, the sub-private and sub-public keys can be calculated as follows: The sub-private key d'' can be calculated from the star private key pair by:

[0038]

number

[0039] Furthermore, the sub-public key D'' can be computed from the master public key pair by the following formula:

[0040]

number

[0041] In some embodiments, the discriminant e is the discriminant TIFF2024536213000006.tif6170, where TIFF2024536213000007.tif6170 is the set of integers 0-, …, q-1 with operations performed modulo q.

[0042] A discriminator according to some embodiments of the present invention may be generally defined as an agent or characteristic that allows to distinguish things, people, or classes from one another. Similarly, in the context of some embodiments of the present invention, a discriminator allows to derive sub-private and sub-public keys from a master private and master public key pair, respectively.

[0043] In one embodiment, the discriminator may be derived by a hash function, which may be implemented to be collision resistant.

[0044] In one embodiment, the discriminator may be derived by applying a hash function to a set of multiple hash input data, which may include any identifier, a master public key pair, and / or additional input data.

[0045] In some embodiments, the optional identifier uniquely identifies the ownership and / or context of the sub-public or sub-private key.

[0046] In some embodiments, additive key generation may also be combined with pre-signature re-randomization.

[0047] In an embodiment of another aspect, there is provided a computing system for performing digital signatures according to a public key signature scheme configured to perform steps of the method aspects of the present invention.

[0048] In an embodiment of another aspect of the present invention, there is provided a computer program product for performing digital signatures in accordance with a public key signature scheme, the computer program product including a computer readable storage medium having program instructions embodied therein that are executable by a computing system to cause the computing system to perform steps of the method aspects of the present invention.

[0049] Features and advantages of one aspect of the invention may be applied to other aspects of the invention, as appropriate.The steps of each of the method aspects of the invention may be performed in different orders according to some embodiments.

[0050] Further advantageous embodiments are set forth in the dependent claims and the following description.

[0051] The invention will be better understood, and other objects set forth above will become apparent, from the following detailed description, in which reference is made to the accompanying drawings, in which: [Brief description of the drawings]

[0052] [Figure 1] FIG. 1 is an exemplary diagram of a distributed network according to one embodiment of the present invention. [Diagram 2] FIG. 2 is a diagram illustrating an exemplary replicated system computing cluster. [Diagram 3] FIG. 3 is a schematic flow chart of a computer-implemented method according to one embodiment of the present invention. [Figure 4] FIG. 4 is a schematic flow chart of a computer-implemented method according to one embodiment of the present invention. [Diagram 5] FIG. 5 is a diagram illustrating one embodiment of a key that may be generated by the distributed threshold key generation protocol. [Figure 6] FIG. 6 is a diagram illustrating an exemplary embodiment of a node according to one embodiment of the present invention. [Figure 7] FIG. 7 is a schematic flow chart of a computer-implemented method according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0053] First, some general aspects and terminology of embodiments of the present invention are introduced.

[0054] In some embodiments, a distributed network comprises multiple nodes arranged in a distributed fashion. In such distributed network computing, software and data are distributed across multiple nodes. The nodes establish computing resources, and the distributed network may use, among other things, distributed computing techniques.

[0055] In some embodiments, the distributed network may be embodied as a blockchain network. The term "blockchain" is intended to include all forms of electronic, computer-based distributed ledgers. In some embodiments, the blockchain network may be embodied as a proof-of-work blockchain network. In other embodiments, the blockchain network may be embodied as a proof-of-stake blockchain network.

[0056] Verification key / public key: A string of bits in a public key signature scheme that is intended to be publicly available. The verification key may also be referred to as a public key, and is used, for example, to verify the digital signature of a public key signature scheme.

[0057] A public key signature scheme according to some embodiments of the present invention may comprise, for example, a key for a public key signature and encryption scheme such as RSA, or a key for a public key signature scheme such as Schnorr or DSA.

[0058] Private key (sk): A string of bits associated with a public key, particularly a verification key, that allows some cryptographic operations to be performed, particularly to digitally sign messages. A private key may also be called a private key.

[0059] Distributed Key Generation (DKG): A protocol that allows a set of dealers to create, among other things, a public key, a verification key, and provide a set of recipients with a shared secret for the corresponding private key.

[0060] (n,t)-Threshold Key / Threshold Private Key: Such a threshold key has a threshold t and some shared private keys s1, s2, …., sn such that any t shared private keys allow reconstruction of the private key, while t-1 shares do not allow determination of the private key. In a threshold public key signature scheme, any t shared private keys allow valid signature execution under the threshold public key / verification key, but t-1 shares are insufficient to execute a valid signature.

[0061] In some embodiments, the Feldman Protocol [Fel87], the Joint Feldman Protocol [Ped91], and the GJKR Protocol [GJKR99] may be used as distributed key generation protocols. These protocols are published, for example, in the following documents, the corresponding disclosures of which are incorporated herein by reference:

[0062] [Fel87] Paul Feldman. A practical scheme for non-interactive verifiable secret sharing.

[0063] In 28th Annual Symposium on Foundations of Computer Science, pages 427-437, Los Angeles, California, October 12-14, 1987. IEEE Computer Society Press.

[0064] [Ped91] Torben P. Pedersen. A threshold cryptosystem without a trusted party (extended abstract) (rump session). In Donald W. Davies, editor, Advances in Cryptology - EUROCRYPT'91, volume 547 of Lecture Notes in Computer Science, pages 522-526, Brighton, UK, April 8-11, 1991. Springer, Heidelberg, Germany.

[0065] [GJKR99] Rosario Gennaro, Stanislaw Jarecki, Hugo Krawczyk, and Tal Rabin. Secure distributed key generation for discrete-log based cryptosystems. In Jacques Stern, editor, Advances in Cryptology - EUROCRYPT'99, volume 1592 of Lecture Notes in Computer Science, pages 295-310, Prague, Czech Republic, May 2-6, 1999. Springer, Heidelberg, Germany.

[0066] The Elliptic Curve Digital Signature Algorithm (ECDSA) is a variant of the Digital Signature Algorithm (DSA) that uses elliptic curve cryptography. More specifically, ECDSA signatures operate on elliptic curves or on subgroups of elliptic curves.

[0067] The Threshold Elliptic Curve Digital Signature Algorithm is a threshold signature algorithm based on elliptic curve cryptography, in which any t shared secret keys allow for a valid ECDSA signature to be performed under a threshold ECDSA public / verification key, while t-1 shares are insufficient to perform a valid ECDSA signature.

[0068] Such a threshold elliptic curve digital signature algorithm (ECDSA) is described, for example, in the publication by Jean-Philippe Aumasson, Adrian Hamelink, and Omer Shlomovits, A Survey of ECDSA Threshold Signing. IACR Cryptol. ePrint Arch. 2020: 1390 (2020).

[0069] Secure multi-party computation generally refers to a method in which multiple parties collaboratively compute a function on input data provided by the multiple parties, where the parties keep their respective input data secret. Secure multi-party computation may also be referred to simply as multi-party computation (MPC) or privacy-preserving computation.

[0070] Elliptic curve-based signature algorithms include the Elliptic Curve Digital Signature Algorithm (ECDSA), but also some other signature algorithms that use elliptic curves, such as the Edwards Curve Digital Signature Algorithm (EdDSA). The Edwards Curve Digital Signature Algorithm is a signature algorithm that uses a variant of Schnorr signatures based on the twisted Edwards curve, as specified in the document RFC 8032, Internet Research Task Force (IRTF), Request for Comments: 8032, ISSN: 2070-1721, January 2017.

[0071] In some embodiments, the term multi-party computation may refer to a method in which multiple parties, e.g., n parties p1, p2, ...., pN, each have secret / secret data, e.g., s1, s2, ...., sN. Furthermore, the multiple parties wish to compute the value of a public function F(s1, s2, ...., sN) on their secret / secret data while keeping their own input data secret, i.e., performing a secure function evaluation.

[0072] In some embodiments, the multi-party computation may specifically utilize (n,t)-threshold keys / threshold private keys as secret / secret data.

[0073] In some embodiments, multi-party computation may include, among other things, computation of threshold signatures.

[0074] A pre-signature may be defined as any value / intermediate value used in computing a signature that may be computed before each message to be signed is received. A pre-signature may be message independent, and in particular independent of the content of the message being signed.

[0075] The pre-signature may include, among other things, a random value such as a nonce.

[0076] A step of re-randomizing the pre-signature is in particular to be understood as a step of adding additional randomness, for example an additional random value, to the pre-signature.

[0077] The four-sum attack is, for example, an attack described in "A Generalized Birthday Problem." by David A. Wagner, CRYPTO (2002).

[0078] A "raw" signing oracle is one that takes as input the desired hash h, rather than the message m.

[0079] In some embodiments, the offline phase of a method for performing digital signatures, such as threshold signatures, specifically encompasses method steps where the message to be signed is not yet required. The offline phase is also referred to as a pre-processing phase. The offline phase may be used, among other things, to compute pre-signatures. The computations of the offline phase may be performed in advance and the results, such as pre-signatures, may be retained for subsequent use.

[0080] In some embodiments, the online phase of the method of performing digital signatures, such as threshold signatures, specifically encompasses the method steps where a message to be signed is required. The online phase begins when a signature is requested and the message to be signed is available. The actual signing is much more efficient since the parties can use pre-signed signatures that are held without having to perform the full signing protocol. Signature re-randomization is also performed during the online phase according to some embodiments.

[0081] The generic group model is an idealized cryptographic model as introduced in the paper "Lower Bounds for Discrete Logarithms and Related Problems", Victor Shoup, EUROCRYPT 1997. In the generic group model, the adversary is only given access to an encoding of a randomly chosen group, rather than a concrete encoding such as a finite field or elliptic curve group that is actually used.

[0082] FIG. 1 illustrates an exemplary block diagram of a distributed network 100 in accordance with one embodiment of the present invention.

[0083] The distributed network 100 includes a number of nodes 10, which may also be denoted as network nodes 10. The nodes 10 are assigned to a number of replicated computing clusters 11. The replicated computing clusters 11 establish sub-networks 11, which may hereinafter be referred to as sub-networks 11. In the example of Fig. 1, four sub-networks 11 are provided, denoted SNA, SNB, SNC, and SND.

[0084] Each of the multiple sub-networks 11 is configured to execute a set of computational units at each node 10 of the respective sub-network 11. In some embodiments, a computational unit is to be understood as a piece of software, in particular a piece of software that includes or has its own unit state, an execution state.

[0085] In some embodiments, the unit state is understood to be, in particular, all deterministic data or information used by the deterministic subunits of the computing unit, such as data that the computing unit stores in variables, as well as data that the computing unit obtains from remote calls. The unit state may in particular represent storage locations in the respective memory locations of the respective nodes. In some embodiments, the contents of these memory locations at any point during the execution of the computing unit are referred to as the unit state. The computing unit may in particular be embodied as a stateful computing unit, i.e., the computing unit is, in some embodiments, designed to remember previous events or user interactions.

[0086] The network 100 comprises communication links 12 for intra-subnetwork communication within each subnetwork 11, in particular for intra-subnetwork inter-unit messages exchanged between computing units assigned to the same subnetwork.

[0087] Furthermore, the network 100 comprises communication links 13 for inter-subnetwork communication between the different subnetworks 11, in particular inter-subnetwork inter-unit messages exchanged between the computing units assigned to the different subnetworks.

[0088] Thus, communication link 12 may be denoted as an intra-subnetwork or peer-to-peer (P2P) communication link, and communication link 13 may be denoted as an inter-subnetwork or inter-subnetwork (SN2SN) communication link.

[0089] In some embodiments of the present invention, the sub-networks 11 are configured to replicate a set of computational units across each sub-network 11. More specifically, the sub-networks 11 are configured to replicate unit states of the computational units across each sub-network 11.

[0090] The network 100 may in particular be a proof-of-stake blockchain network.

[0091] Network 100 is configured to exchange inter-subnetwork messages 16 between subnetworks SNA, SNB, SNC, and SND via a messaging protocol and a consensus protocol. The consensus protocol is configured to reach a consensus on the processing order of inter-subnetwork messages 16 in each receiving subnetwork.

[0092] In some embodiments, network 100 may be configured to run the consensus protocol on each subnetwork separately, in other words, each of subnetworks SNA, SNB, SNC, and SND runs its own consensus protocol separately and independently from the other subnetworks.

[0093] The distributed network 100 may comprise a central control unit CCU 20. The central control unit 20 may comprise a central registry 21 that provides network control information to the nodes of the network.

[0094] In some embodiments, at least one of the subnetworks SNA, SNB, SNC, or SND is embodied as a replicated system computing cluster. Each node of such a replicated system computing cluster comprises a system computing unit. Such a system computing cluster may perform multi-party computations such as threshold signatures.

[0095] Distributed network 100 may provide a user interface 101 to a user of distributed network 100 .

[0096] A user may send a signature request to sign, for example, message m with a digital signature. In particular, the digital signature, such as a threshold signature, may be, for example, a threshold ECDSA signature. The signature request may be executed by a system call. The distributed network 100 may execute the requested signature from a system computing unit of a replicated system computing cluster and provide, via the user interface 101, a signature response comprising the message m with the executed signature.

[0097] 2 illustrates in more detail an exemplary replicated computing cluster / sub-network SNA 200 comprising a number of nodes N1, N2, and N3. The replicated computing cluster 200 is embodied as a system computing cluster. Each of the plurality of nodes N1, N2, and N3 of the replicated system computing cluster 200 is configured to execute a system computing unit. More specifically, the system computing unit includes a system computing unit 21a, SCU 21b, and SCU 21c, which execute on node N1. N1 , the system computation unit 21b, SCU N2 , and a system computation unit 21c, SCU N3 The system computing units 21a, 21b, 21c may be collectively referred to as system computing units 21. The system computing units 21a, 21b, and 21c of the replicated system computing cluster 200 comprise a deterministic subunit 22, SNA_det, configured to perform deterministic replicated computations across the replicated system computing cluster 200, SNA, thereby traversing identical chains of unit states. The system computing units 21a, 21b, and 21c of the replicated system computing cluster 200 further comprise a non-deterministic subunit that performs non-deterministic computations. More specifically, the system computing units 21a, 21b, and 21c of the replicated system computing cluster 200 comprise a non-deterministic subunit 22, SNA_det, configured to perform non-deterministic computations. N1 The system includes a non-deterministic sub-unit 23a, N1_nondet. The non-deterministic sub-unit 23a may store and compute non-deterministic data specific / individual to the node N1. Similarly, the system computation unit 21b, SCU N2The SCU includes a non-deterministic sub-unit 23b, N2_nondet, which can store and calculate non-deterministic data specific / individual to the node N2. N3 Each of the nodes N1, N2, and N3 comprises a non-deterministic sub-unit 23c, N3_nondet, which may store and compute non-deterministic data specific / individual to the node N3. In addition, each of the nodes N1, N2, and N3 is configured to execute one or more application computing units that provide application services to users of the distributed network. More specifically, each of the nodes N1, N2, and N3 comprises a set of five application computing units 31, more specifically the application computing units CU A1 , C.U. A2 , C.U. A3 , C.U. A4 , and C.U. A5 These application computing units CU A1 , C.U. A2 , C.U. A3 , C.U. A4 , and C.U. A5 is also configured to perform deterministic replicated computations across the system computing cluster 200. The system computing cluster 200 may be referred to as a mixed computing cluster because it includes both application computing units and system computing units.

[0098] Each of the system computing units 21a, 21b, 21c has a unidirectional communication mechanism 40 from the deterministic sub-unit 22 to the respective non-deterministic sub-unit 23a, 23b, 23c.

[0099] Additionally, each of the system computing units 21a, 21b, and 21c may establish a unidirectional communication mechanism 50 from the non-deterministic sub-units 23a, 23b, and 23c to the deterministic sub-units 22. The communication mechanism 50 comprises a consensus mechanism 51. The consensus mechanism 51 may be used to obtain consensus on messages provided to each of the deterministic sub-units 22, such that all of the deterministic sub-units 22 have an identical view / state of the non-deterministic data provided by one of the respective non-deterministic sub-units 23a, 23b, 23c.

[0100] In some embodiments, the application computing unit CU A1 , C.U. A2 , C.U. A3 , C.U. A4 , or CU A5 Each of the application computing units CU may issue a system call to the system computing units 21a, 21b, and 21c to perform a multi-party computation. The system call may in particular be, for example, a signature request to perform a signature on a message m provided by the respective application computing unit. A2 As a result of the multi-party computation performed by the system computation units 21a, 21b, and 21c, the application computation unit CU A2 receives the signed response Sresp.

[0101] FIG. 3 illustrates a flow chart of method steps for a computer-implemented method of performing digital signatures in accordance with a public key signature scheme.

[0102] In step 310, the signing entity computes a pre-signature.

[0103] In step 320, the signing entity receives the signing request and performs a digital signature on the message.

[0104] In step 330, the signing entity re-randomizes the signature.

[0105] In step 340, the signing entity digitally signs the message with the re-randomized pre-signature.

[0106] In the following, it is assumed that the method is implemented as a digital signature according to the Elliptic Curve Digital Signature Algorithm (ECDSA), and the aforementioned steps are explained in more detail with reference to ECDSA.

[0107] ECDSA can be based on the following signature scheme: E is Z p Let G be the elliptic curve generated by the point G of prime order q defined above. The non-contractive transformation function TIFF2024536213000008.tif7170 maps point P to its x coordinate. The contraction transformation function TIFF2024536213000009.tif7170 maps a point P to a reduced mod q canonical representation of C(P) (i.e., the integers in the interval [0,p)).

[0108] The ECDSA private key is random. TIFF2024536213000010.tif7170 and the public key D = dG ∈ E. In the ECDSA signature scheme, the hash function TIFF2024536213000011.tif7170 is used. To sign a message m, the signature scheme may proceed as follows.

[0109]

number

[0110] The verifier verifies the signature of message m. Verification of TIFF2024536213000013.tif7170 may proceed as follows:

[0111]

number

[0112] In an ECDSA signature algorithm, the values ​​r and R:= rG are independent of the message being signed. Hence, they can be precomputed before the actual signing request. Such elements of the signature algorithm that can be, and do in fact be, precomputed establish a pre-signature according to some embodiments of the invention. The value r establishes the random nonce, in other words, forms the random value of the pre-signature.

[0113] In some embodiments, only the value r may be precomputed, while in some other embodiments, both r and R may be precomputed. The latter embodiment is particularly advantageous in distributed settings involving threshold signatures, particularly ECDSA threshold signatures, in which each party may precompute a share of r. Furthermore, R itself may also be precomputed. Such an embodiment may significantly simplify the online signature phase of the protocol.

[0114] In some embodiments, the pre-signature including the nonce may be re-randomized. With reference to the ECDSA embodiment described above, r′ ∈ Z q and a pre-signature of the form R':= r'G ∈ E can be computed as before.

[0115] However, once the signature request is made, the original pre-signature is re-randomized with an unpredictable public re-randomization value δ. In the ECDSA embodiment described above, the actual pre-signature used is:

[0116]

number

[0117] where δ is a public value, and in particular δ ∈ Z q Meet the following.

[0118] The re-randomization value δ, and therefore the pre-signature, is unpredictable until the signature request with the message is received or determined.

[0119] Such re-randomization can be proved to provide a higher security level. Specifically, it can be proved that the security level of a pre-signature re-randomized without additive key derivation is essentially equivalent to that of plain ECDSA. Furthermore, it is secure even if an adversary can obtain a signature directly on the message digest rather than on the message (raw signature). With additive key derivation, the concrete security decreases by a factor of |E|, but the resulting scheme is no longer vulnerable to 4-sum attacks, where E is a valid set of discriminators / tweaks. Security can also be proved for raw signatures with or without additive key derivation.

[0120] As mentioned above, the use of re-randomized pre-signatures is particularly advantageous in setting the thresholds: in some embodiments, the cost of re-randomization with respect to handling shares is moderate or negligible, particularly since re-randomization is an algebraic operation, such as a linear operation.

[0121] However, the actual generation of an unpredictable public rerandomization value δ has an associated cost, which may depend on other aspects of the computing system that performs digital signatures.

[0122] In one embodiment, the unpredictable public re-randomization value δ may be generated by performing a pseudo-random generation of the public re-randomization value δ, for example by a pseudo-random number generator, after receiving the signature request.

[0123] In one embodiment, the public re-randomization value δ may be computed by applying a hash function to at least the message or a hash of the message. In some embodiments, the hash function may be applied to an additional input, such as a public key for a digital signature. During additive key derivation, a hash may also be applied to the discriminator.

[0124] Such an embodiment of re-randomizing the pre-signatures is essentially cost-free, either in terms of computation or latency, and yet the heuristic appears to provide greater security than simple pre-signatures, in particular thwarting 4-sum attacks.

[0125] In some further embodiments, the public re-randomization value δ may be derived from a random beacon. Such a random beacon may be generally defined as any publicly available randomness. In some embodiments, such a random beacon may be implemented using a threshold BLS signature scheme.

[0126] FIG. 4 illustrates another flowchart of method steps of a computer-implemented method for performing digital signatures in accordance with a public key signature scheme.

[0127] At step 410, the signing entity provides, maintains, stores, and / or uses a master public key pair comprising a first master public key and a second master public key.

[0128] In step 420, the signing entity derives a sub-public key from the master public key pair.

[0129] At step 430, the signing entity provides, maintains, stores, and / or uses a master private key pair. The master private key pair comprises a first master private key and a second master private key.

[0130] In step 440, the signing entity derives a secondary private key from the master private key pair.

[0131] Steps 410 and 430 may be considered preparatory steps or may be considered common steps. The master public / private key pair may be randomly selected.

[0132] Such derivation of subkeys from a master key pair generally has the advantage of limiting the cost of holding private keys: more specifically, it allows the derivation of multiple different subpublic keys for use while only maintaining a single private key pair.

[0133] This private key storage cost arises in both threshold and non-threshold settings. In non-threshold settings, there is the cost of storing the private key in some sort of secure storage. In threshold settings, there is the cost of storing shared secrets in some sort of secure storage, and the cost of periodically dynamically updating these shares as needed to maintain proactive security. Nevertheless, such schemes can be efficiently implemented as threshold signature schemes.

[0134] Below, key derivation techniques according to some embodiments of the present invention are illustratively described with respect to ECDSA signatures.

[0135] In such an embodiment, the master private key is a random master private key pair (d,d') ∈ Z q × Z q and the corresponding master public key is the master public key pair.

[0136]

number

[0137] A given discriminant is a "tweak" e ∈ Z q The corresponding derived sub-private key d'' can be expressed as d + ed' ∈ Z. q and the corresponding derived public subkey D'' is D + eD'.

[0138] Thus, deriving the sub-private key from the master private key pair comprises performing a first algebraic operation on the master private key pair, which in the above example is a linear operation. Deriving the sub-public key from the master public key pair comprises performing a second algebraic operation on the master private key pair, which in the above example is a linear operation. Moreover, in the above example, the algebraic operation and the linear operation are identical.

[0139] The discriminator / tweak e may be generally defined by the embodiment as an agent or characteristic that allows for the distinction between objects, people, or classes. The discriminator e may be derived in particular by a hash function, in particular a collision-resistant hash function.

[0140] The use of a master key pair, comprising a master private key pair and a master public key pair, may provide a provable higher level of security than the use of additive key derivation.

[0141] In particular, in some embodiments, the discriminator / tweak is a function of some predetermined set E ⊆ Z q Thus, we do not need to assume that the discriminant / tweak e ∈ Z q can be derived from the hash function Hash as follows:

[0142]

number

[0143] where id is an arbitrary identifier.

[0144] The optional identifier id may uniquely identify the ownership and / or context of the sub-public or sub-private key.

[0145] In some embodiments, the discriminant e may be derived by applying a hash function Hash to a set of multiple hash input data, which in such embodiments may include any identifier id, a master public key pair, and / or further input data.

[0146] In some embodiments, Hash may be the same hash function previously used to generate h in the ECDSA signature algorithm. In some other embodiments, a different hash function may be applied. In some embodiments, the only requirement is that this hash function must be Z q and is collision-resistant.

[0147] In some embodiments, the signing algorithm may take as input a message m and an optional identifier id.

[0148] Key derivation techniques such as those described above may be combined with re-randomized pre-signatures according to some embodiments.

[0149] In another embodiment, the additive key derivation technique may be combined with a re-randomized pre-signature according to some embodiments.

[0150] Such additive key derivation techniques are described in more detail below with reference to FIG.

[0151] FIG. 7 illustrates another flowchart of method steps of a computer-implemented method for performing digital signatures in accordance with a public key signature scheme.

[0152] At step 710, a master key pair is provided, comprising a master public key D and a master private key d.

[0153] At step 720, one or more subkey pairs are derived from the master key pair. A subkey pair comprises a sub public key D' and a sub private key d'. The subkey pairs are derived from the master key pair by applying an add and shift operation to the master key pair.

[0154] In some embodiments, such an additive key derivation comprises a discriminant A sub-private key may be derived from the master key pair (d, D) using TIFF2024536213000018.tif6170. The discriminator e may also be referred to as the “tweak”.

[0155] More specifically, the sub-private key can be computed as d':= d + e, and the sub-public key can be computed as D':= D + eG.

[0156] Like the mixed key derivation discussed above, additive key derivation is also useful for reducing the cost of securely storing keys, since multiple different public keys can be used while only maintaining a single private key.

[0157] FIG. 5 illustrates an embodiment of a key 510 that may be generated by a distributed threshold key generation protocol. The key 510 may be used by system computing units of a replicated system computing cluster to sign messages at the request of a user or application computing unit. In this example, assume that N system computing units participate in the distributed key generation protocol. Each of the N system computing units is assigned a shared secret key sk i where i = 1, … , N. The N system computing units generate a common public verification key pk, and a predefined threshold, say at least two-thirds or one-third of the system computing units, must create a joint signature σpk using their shared private key before the joint signature can be verified using the public verification key pk.

[0158] As mentioned above, techniques according to some embodiments of the present invention for computing pre-signatures and re-randomizing the pre-signatures may be advantageously used with such threshold signatures.

[0159] 6, there is shown a more detailed block diagram of a network node 10 according to some embodiments of the present invention, for example of the network 100 of FIG. 1. The network node 10 establishes a computational node that may perform computational functions and may generally be embodied as a computing system or computer. The network node 10 may be, for example, a server computer. The network node 10 may be configured to execute a computer-implemented method of operating a distributed network. The network node 10 may operate with numerous other general purpose or special purpose computing system environments or configurations.

[0160] Network node 10 may be described in the general context of computer system executable instructions, such as program modules, executed by a computer system. Generally, program modules may include routines, programs, objects, components, logic, data structures, etc. that perform particular tasks or implement particular abstract data types. Network node 10 is illustrated in the form of a general-purpose computing device. Components of network node 10 may include, but are not limited to, one or more processors or processing units 615, a system memory 620, and a bus 616 that couples various system components including the system memory 620 to the processor 615.

[0161] Bus 616 represents any one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, an accelerated graphics port, and a processor or local bus using any of a variety of bus architectures.

[0162] Network node 10 typically includes a variety of computer system readable media.

[0163] The system memory 620 may include computer system readable media in the form of volatile memory such as random access memory (RAM) 621 and / or cache memory 622. The network node 610 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, the storage system 623 may be provided for reading from or writing to a non-removable, non-volatile magnetic medium (not shown, typically referred to as a "hard drive"). Although not shown, a magnetic disk drive for reading from or writing to a removable, non-volatile magnetic disk (e.g., a "floppy disk") and an optical disk drive for reading from or writing to a removable, non-volatile optical disk, such as a CD-ROM, DVD-ROM, or other optical media, may be provided. In such a case, each may be connected to the bus 616 by one or more data media interfaces. As further illustrated and described below, the memory 620 may include at least one computer program product having a set (e.g., at least one) of program modules configured to perform the functions of some embodiments of the present invention.

[0164] A program / utility 630 having a set (at least one) of program modules 631 may be stored in memory 620, as may an operating system, one or more application programs, other program modules, and program data, by way of example and not limitation. Each of the operating system, one or more application programs, other program modules, and program data, or any combination thereof, may comprise an implementation of a networking environment. The program modules 631 generally perform the functions and / or methods of some embodiments of the invention described herein. The program modules 631 may, among other things, perform one or more steps of a computer-implemented method of operating a distributed network, such as one or more steps of the methods described above.

[0165] The network node 10 may communicate with one or more external devices 617, such as a keyboard or pointing device, and a display 618. Such communication may occur via an input / output (I / O) interface 619. Additionally, the network node 10 may communicate with one or more networks 40, such as a local area network (LAN), a general wide area network (WAN), and / or a public network (e.g., the Internet), via a network adapter 641. In some embodiments, the network 640 may be a distributed network including multiple network nodes 10, such as, for example, the network 100 shown in FIG. 1. As shown, the network adapter 641 communicates with other components of the network node 10 via a bus 616. It should be understood that other hardware and / or software components, not shown, may be used with the network node 10.

[0166] Some aspects of the invention may be embodied as a system, particularly a distributed network including multiple sub-networks, a method, and / or a computer program product. The computer program product may include a computer-readable storage medium (or media) having computer-readable program instructions that cause a processor to perform some aspects of the invention.

[0167] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing, but is not limited to such. As used herein, a computer-readable storage medium should not be interpreted as being a transitory signal in itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted through wires.

[0168] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium into each computing / processing device, and can also be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fiber, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium in the respective computing / processing device.

[0169] The computer readable program instructions for carrying out the operations of the present invention may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, or source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Samalltalks, C++, and conventional procedural programming languages ​​such as the "C" programming language or similar programming languages.

[0170] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, networks, apparatus (systems) and computer program products according to some embodiments of the invention.

[0171] Computer-readable program instructions according to some embodiments of the present invention may be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus. The instructions, executed via the processor of the computer or other programmable data processing apparatus, may then generate a machine to create means for performing the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may be stored on a computer-readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner. As a result, the computer-readable storage medium having instructions stored thereon has a product including instructions for performing aspects of the functions / operations specified in one or more blocks of the flowcharts and / or block diagrams.

[0172] The computer-readable program instructions may be loaded into a computer, other programmable data processing apparatus, or other device and may generate a computer-implemented process that causes the computer, other programmable apparatus, or other device to perform a series of operational steps such that the instructions, executing on the computer, other programmable apparatus, or other device, perform the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0173] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of networks, systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowcharts or block diagrams may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function(s). In some alternative implementations, the functions noted in the blocks may be executed in an order different from that noted in the figures. For example, two blocks shown in succession may in fact be executed substantially simultaneously. Also, the blocks may be executed in the reverse order, depending on the functionality involved.

[0174] While certain presently preferred embodiments of the invention are shown and described in the foregoing and following attachments, it is to be clearly understood that the invention is not limited thereto and may be variously embodied and carried out in other ways within the scope of the appended claims.

[0175] In the following, some further embodiments and a detailed security analysis of the ECDSA signature algorithm are provided. The applicant unexpectedly discovered that the specific security of the ECDSA signature scheme using pre-signatures is substantially inferior to that of simple ECDSA. And the applicant discovered a possibility of an attack against ECDSA using pre-signatures as shown in the following formula.

[0176]

number

[0177] Table 1 summarizes the specific security theorems. In this table, "No Derivation" indicates that no key derivation technique was used. "Additive" indicates that an additive key derivation technique was used, and "Homogeneous" refers to a new key derivation technique according to some embodiments of the present invention that comprises providing a master private key pair and a master public key pair, deriving a sub-private key from the master private key pair and deriving a sub-public key from the master public key pair. Furthermore, "No Pre-Signed" refers to methods that do not use pre-signatures, "With Pre-Signed" refers to methods that use pre-signatures, and "Re-Randomized Pre-Signed" refers to some embodiments that use re-randomized pre-signatures.

[0178] [Table 1]

[0179] Each entry in the table gives an upper bound on the probability of forgery by an adversary (ignoring small constants). The analysis is done for the general swarm model under specific assumptions on the hash function Hash. The upper bound is given by

[0180]

number

[0181] In additive key derivation, it is assumed that the set of all valid tweaks is not too large and is predetermined. In practice (e.g., in BIP32), the tweak is derived from an identifier (possibly combined with a "root" public key) via hashing. This assumption on the set of tweaks may be justified if the set of valid identifiers is indeed small, especially the set of identifiers for which forgery is a concern. It may also be further justified by modeling the hash function used to derive the tweak as a random oracle. However, this analysis works without this assumption.

Claims

1. 1. A computer-implemented method for performing digital signatures according to a public key signature scheme, comprising: Computing a pre-signature; receiving a signature request to perform the digital signature on a message; re-randomizing the pre-signature after receiving the signature request; and performing the digital signature on the message using the re-randomized pre-signature.

2. the step of computing the pre-signature includes computing a random nonce; The computer-implemented method of claim 1 , wherein re-randomizing the pre-signature comprises re-randomizing the random nonce.

3. The computer-implemented method of claim 1 or 2, wherein re-randomizing the pre-signature comprises performing an algebraic operation on the pre-signature.

4. The computer-implemented method of claim 1 or 2, wherein re-randomizing the pre-signature comprises performing a linear operation on the pre-signature.

5. The computer-implemented method of claim 1 or 2, wherein the digital signature is a threshold signature.

6. re-randomizing the pre-signature includes calculating an unpredictable public re-randomization value and utilizing the public re-randomization value for the re-randomization; The computer-implemented method of claim 1 or 2, wherein the unpredictable public re-randomization value is generated after the step of receiving the signature request.

7. The computer-implemented method of claim 6 , further comprising performing a pseudo-random number generation of the public re-randomization value.

8. deriving the public re-randomization value by applying a hash function to at least the message or a hash of the message; 7. The computer-implemented method of claim 6, further comprising: deriving the public re-randomization value by applying the hash function to the public key and / or other inputs of the digital signature.

9. The computer-implemented method of claim 6 , further comprising deriving the public re-randomization value from a random beacon.

10. The computer-implemented method of claim 1 or 2, wherein the digital signature is a digital signature according to a discrete logarithm-based signature algorithm.

11. The computer-implemented method of claim 1 or 2, wherein the digital signature is a digital signature based on an elliptic curve-based signature algorithm.

12. said digital signature algorithm operates on an elliptic curve E generated by a point G of order q, in particular of prime order q, The step of calculating the pre-signature comprises: r' ← Zq* and By calculating R'← r'G ∈ E, generating a random element r'; The step of re-randomizing the pre-signature uses the unpredictable public value δ to: r: = r' + δ and R := R' + δG The computer-implemented method of claim 11 , comprising calculating:

13. providing a master private key pair including a first master private key and a second master private key; providing a master public key pair including a first master public key and a second master public key; deriving a sub-private key from the master private key pair; The computer-implemented method of claim 1 or 2, further comprising: deriving a sub-public key from the master public key pair.

14. 1. A computing system configured to perform digital signatures according to a public key signature scheme and to execute a computer-implemented method, comprising: Computing a pre-signature; receiving a signature request to perform the digital signature on a message; re-randomizing the pre-signature after receiving the signature request; and performing the digital signature on the message using the re-randomized pre-signature.

15. 1. A computer program product for performing digital signatures in accordance with a public key signature scheme, the computer program product including a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by a computing system to cause the computing system to perform a method, the method comprising: Computing a pre-signature; receiving a signature request to perform the digital signature on a message; re-randomizing the pre-signature after receiving the signature request; and performing the digital signature on the message using the re-randomized pre-signature.

Images