WO2022204236A1 - Secret key-using signature scheme that includes back up key for fall back and proof of ownership purposes - Google Patents

Abstract

A key generation mechanism and resulting digital signature allow users to generate another and secret back up key securely nested inside the secret key of a signature scheme. The back up key, which is secret, can be used to generate a proof of ownership and a fallback, wherein only the real owner of this secret key can generate such a proof. This extra level of security is ideal for digital wallets for cryptocurrencies to avoid leakage of account private keys. The construction is compatible with major designs for wallets, for example those based on ECDSA, and adds a one time signature key as the back up key, thereby offering a quantum secure fallback for the account holder.

Description

SECRET KEY-USING SIGNATURE SCHEME THAT INCLUDES BACK UP KEY FOR FALL BACK AND PROOF OF OWNERSHIP PURPOSES

FIELD OF THE INVENTION

The invention relates to secret key-using signature scheme that includes a back up key for fall back and proof of ownership purposes, a method of generating a signature scheme, and a cryptographic protocol establishing proof of ownership

BACKGROUND ART

Digital wallets allow users to securely store secret cryptographic keys which can be used to spend cryptocurrency funds. These wallets, and corresponding keys, are becoming increasingly important as hackers attempt to exploit eventual security flaws and, as a result, steal funds controlled by such wallets. In practice, users rely on a few approaches. The most straightforward technique is to resort to secure hardware, i.e., hardware wallets, see [1] in the references section below. Further citations to bracketed numbers make reference to one or more of the listed references. Another popular approach among practitioners is the technique of hot/cold wallets, where, briefly, there is a hot wallet permanently connected to the network, typically initiated with the public key and can generate addresses for receiving funds. The cold wallet, on the other hand, stores the secret key and is kept without network connection, see [11]. This separation ensures that it is harder for attackers to gain access to secret keys as they are kept offline. Despite these security enhanced wallets, in the case of massive key leakage, including in the cold wallet, any attempt of confirming the ownership of the leaked key is impractical, if possible.

An example of such a leak is the hack involving the Trinity wallet, see [23]. This attack resulted in the theft of roughly 1.5M USD. Trinity, an open-source software wallet which enables users to manage their IOTA tokens, suffered from a hack so severe that the IOTA Foundation decided to halt the coordinator node and, as a result, temporarily stopped the confirmations of all transactions on the network. To perform this attack, the adversary gained the ability to load malicious code into the local Trinity wallet instances running on the computers of the target users and retrieved the secret seeds— along with the encryption passwords— to a malicious server owned by the attacker. The adversary then waited for the release of a new software update, which when installed resulted in overwriting the local cache of each compromised user and cleaned the traces of the exploit. After performing this attack, the adversary effectively gained access to secret keys that were— at least temporarily— on hot storage, resulting in a massive leakage without a practical solution for the users to prove ownership of their secret keys.

On a different threat vector, attacks against cold wallets storing elliptic curve secret keys are believed to be possible with the uprising of quantum computing. Major cryptocurrencies are based heavily on the Elliptic Curve Digital Signature Algorithm or ECDSA signature scheme. Therefore, an adversary capable of breaking the elliptic curve discrete logarithm problem (ECDLP) can extract the secret keys behind a wallet address, even though such keys never left the cold storage.

In both early mentioned cases, the target is the secret key, i.e., the secret information kept by the wallet. Prior to the leakage, standard technique to prove ownership can be constructed by employing Zero Knowledge Proof of Knowledge (ZKPK) Protocols. The security derives directly from the zero knowledge property of ZKPK. However, in the case of a massive leakage, any party can generate such proof. Therefore, new techniques need to be developed.

The use of hash-based signatures, including those that employ one-time constructions are well known in the art. Typically, every signature scheme requires the use of a cr/ptographic hash function. Hash-based signature schemes rely solely on hash functions and, as a result, do not require any additional cryptographic or computational assumption. Since there are cryptographical ly-secure hash functions that are considered unfeasible to invert (see a formal definition provided below), users can provide a preimage that serves as proof of ownership of a specific public key.

Lamport, see [10], proposed a signature scheme that relies only on the security of one-way functions. In this scheme, to sign a single bit, the signer first generates two secret key values (x, y), and publishes the corresponding pair of hash values as the public key PK = H(x), H(y). The signer releases the secret value x\r\ case the bit to be signed is a 0, or releases the secret value y in case the bit is a 1. One of the main limitations of this scheme, however, is the fact that it can only produce one-time signatures (OTS).

Following Lamport, Winternitz, see [20], proposed a scheme known as the Winternitz one-time signature (W-OTS), that allowed the signing of several bits at once as opposed to individual bits. In this scheme, the public key is H^w(x) instead of the pair H(x), H(y). If the message byte to be signed is, for example, 20, then the signature output is H²⁰(x). Moreover, to prevent an attacker from modifying the signature, the signer also releases a checksum value associated with the signed byte. This checksum is designed to prevent the adversary to attempt to produce a forgery by increasing any of the bytes without invalidating the resulting signature.

HO!sing, see [15], published an upgrade called W-OTS⁺ that shortens the signatures size and increases the security of the original Winternitz scheme. This construction uses a chaining function in addition to a family of keyed functions, along with the XOR of a random value (or mask) before applying the one-way function to a specific ladder height.

The main technical challenge is to improve the wallet design by allowing for the creation of "some structure" in the ECDSA secret key, which allows for the introduction of some sort of "proof of ownership" that prevents or at least minimizes the damage of situations like the IOTA Hack, while also providing quantum resistance, in the case of the massive leakage. Ideally, this new design should also be compatible with the current address system of cryptocurrencies by not significantly changing the ECDSA design. The present invention responds to this need by providing an invention that guarantees backward compatibility with ECDSA based wallets, for example, by adding a nested "back up key" to generate a quantum secure "proof of ownership". In other words, the technique allows the embedding of a nested private key (in addition to the ordinary private key) to be used only in situations when it is necessary to prove ownership and provide a fallback if the secret key is learned.

SUMMARY OF THE INVENTION

The invention proposes a new approach, herein labeled S_leeve, to a quantum- secure fallback inside an elliptic curve private key. The core idea is to have a hidden hash-based signing key pair. Users can then demonstrate they are the rightful owner of the cryptocurrency wallet even in the presence of an adversary capable of breaking the elliptic curve discrete logarithm problem, which is not a possibility using any of the existing curve-based cryptocurrency wallets. Moreover and in catastrophic scenarios, where a massive leakage has potentially happened, and systems is halted, a user can show to trusted third parties that they are the correct owners of the wallet.

Along with S_leeve, other ideas are presented for security guarantees and security analysis.

One aspect of the invention is an improvement in secret key-using digital signature. The improvement entails embedding a back up key in the secret key of the digital signature, the back up key allowing a user a fallback, wherein the user can continue to use the digital signature, or a proof of ownership, wherein a user can prove to a third party that the user is the owner of the secret key.

For the digital signature, the back up key is the secret key of a hash-based signature and the secret key is based on a public key derived from the hash-based signature.

While the digital signature can use any hash based signature schemes, a preferred scheme uses a variant of a Winternitz one time signature scheme, The digital signature can also use an elliptic curve digital signature algorithm for generation thereof.

For the fallback and proof of ownership functionality, additional cryptographic protocols are provided that respectively output an ownership proof p based on the back up key and a challenge c and verify a validity of ownership proof p using a verification key, the secret key, the back up key, the ownership proof p, and a challenge c.

Beside providing a new digital signature scheme, the invention includes a method of generating a secret key-using signature, wherein the back up key in the secret key of the digital signature.

The additional cryptographic protocols that allow for the fallback position and proof of ownership are also separate aspects of the invention.

The invention is also an improvement in digital wallets that store a secret key that permits spending of cryptocurrency funds, whereby the digital wallet include the improved digital signature scheme of the invention. BRIEF DESCRIPTION OF THE DRAWING

Figure 1 shows a simplified diagram showing the basic features of one embodiment of the invention.

Figure 2 shows a simplified diagram showing an exemplary construction for practicing the invention.

Figure 3 shows a variation of the construction shown in Figure 2.

DETAILED DESCRIPTION OF THE INVENTION

A main aspect of the invention is the establishment of two new properties associated with digital signatures, i.e., fallback and proof of ownership. These properties extend the functionality of a signature scheme by (1) allowing, considering an ECDSA scheme, the continued use of a signature scheme despite the leakage of the secret key, albeit using a different scheme, i.e., a variant of the known W-OTS+ scheme, and (2) prove the ownership of the secret key, even when it becomes public.

More concretely, regarding (1), in addition to the verification and secret key, the generation algorithm of the inventive constructions also outputs the "back up key" which can be used with the secret key as a separate (quantum secure) signature scheme for the fallback situation. In such situation, the inventive construction is usable for existing wallets, and relies solely on symmetric primitives which when instantiated with the correct security parameter, are conjectured secure even against adversaries with quantum capabilities or adversaries with access to elliptic curve secret key material stored on hot wallets. The inventive construction is easily extendable and relevant in a hot/cold wallet setting where the hot wallet— permanently connected to the network— contains the elliptic curve public key and, if needed, the actual elliptic curve key pair. The cold wallet, on the other hand, is kept without any network connection and stores the quantum-secure key pair, including the back up key.

Regarding (2), it is observed that a variant of the known W-OTS+ signature scheme nested into the main signature scheme can be used to prove the ownership of an ECDSA secret key. By design, the back up key is the secret key of the internally nested scheme, i.e., W-OTS⁺, while the ECDSA secret key is derived from the public key of the W-OTS⁺ variant. Given the existence of the internal signature scheme, the proof of ownership for the potentially leaked ECDSA secret key, is the W-OTS⁺ like signature or variant. It is emphasized that the combination of two different signature schemes is a technical challenge that has been solved by the inventive breakthrough, i.e., a new signature variant which for description purposes is called the Extended W-GTS⁺, or "eW-OTS⁺" for short.

It should be noted that although the W-OTS⁺ signature scheme is used for example purposes, other hash-based signature schemes can also be adapted in a similar fashion.

The ECDSA secret key is generated by combining the eW-OTS⁺ verification key / tuple into a L-tree structure, similarly to other existing proposals for other hash based signatures, see [10]. The resulting value is then treated as the ECDSA secret key, making the inventive key generation mechanism especially suited for digital wallets, requiring no change on existing blockchain system designs currently in use. The security of the inventive construction starts by studying the inventive signature scheme eW-OTS⁺ in the light of the existing attacks against symmetric cryptographic primitives, including quantum ones as described in [14. 22]. Finally, a prototype is implemented with full test coverage and the prototype results are compared with reference implementations.

The following is a general summary of the invention: a) introduce new properties for a digital scheme having fallback and proof of ownership functionalities; b) develop a new variant of the W-OTS⁺ based signature scheme, i.e., eW-

OTs+; c) construct a protocol, named S_leeve for generation and verification of a (single) proof of ownership p and formalize security based on the eW-OTS⁺; d) provide information relating to results of experiments conducted on the invention, which implements the main routines of the inventive construction; and e) address how to extend the S_leeve protocol for multiple proofs of ownership.

The cryptographic S_leeve protocol can be used as a tool for a catastrophic scenario as a massive leak of private information. As already happened in the Trinity leak mentioned above, in order to minimize the damage, the system could be halted, until all the honest users are confirmed. The proof of ownership via the S_leeve protocol allows the users to confirm their authenticity, and its addresses, using a back up key stored separately, as will be described in more detail below introduced later when describing the Sieeve protocol and used only in the fallback or proof of ownership situation. Furthermore, it is worth mentioning that although it does not help in the return of the potentially-already stolen funds, once the system is stopped, the S_leeve allows the quick and safe identification of the honest owners of the addresses.

As a precursor to the description of eWOTS⁺ and the Sleeve protocol, the EDSCA construction for a digital signature and the construction for a W-OTS⁺ signature are provided.

Definition 1 (ECDSA). Given a hash function H, the ECDSA signature scheme is the tuple (Gen, Sign, Verify), defined as in Table 1:

Table 1 is illustrated below.

Table 1. ECDSA construction. The W-QTS⁺ Construction. The Winternitz-OTS⁺ signature schemes introduced by Hiilsing, see [17], introduces l as an alternative signature scheme with quantum resistance. Their construction relies on a hash family and a chaining function as explained below.

Definition 2 (Family of Functions). Given the security and the Winternitz parameters, respectively, A eNand w ∈N,w > 1, let a family of functions Hl be {hk :

<0,1 }l ®{0,l}λ|k eKλ} with key space Kl.

Definition 3 (Chaining Function). Given a family of functions Hl, x e{0,l}A, an iteration counter i eN, a key k eKA, for j A— bit strings r = (rl,...,rj) e{0,1}λxj with j ≥ i, then we have the chaining function as follows: cik(x,r) ={hk(ci-1k (x,r) ®ri), 1 <i <j;

<x, i = 0.

Table 2 W-OTS+ Construction is shown below.

Table 2. W-OTS÷ construction. Additionally, the notation is reviewed for the subset of randomness vector r = (ri, ...n) and r_a, rb is denoted by the subset of (r_a, ... r_b).

Definition 4 (W-OTS+). Given the security parameter A, a chaining function c, and k <— K from the key space K, the W-OTS+ signature scheme is the tuple (GenW,SignW ,VerifyW), defined as in Table 2, which is found in the listing of Tables at the end of the specification.

The Security of W-OTS⁺. The standard security notion for digital signature schemes is existential unforgeability under adaptive chosen message attacks (EU-CMA) which is defined using the following experiment. By Dss(lA), we denote a digital signature scheme (Dss) with security parameter A, then we model the security by defining the security experiment ExpEU-CMA Dss(lA) (A), as follows:

Experiment Exp^{EU CMA}Dss(iA) (A)

(sk, pk) < — keygen(lA)

Let {Mi,σi}^q1 be the query-answer pairs of Signfsk,·)

Return 1 if Verify(pk,M*,o*) = 1 and M* /e{Mi}^q1

The probability of success of the adversary A in the above EU-CMA experiment as SuccEU-CMA Dss(lλ) (A) = Pr[ExpEU-CMA Dss(lA) (A) = 1].

Definition 5 (EU-CMA). Let A,t,q e N,t,q = poly(A), Dss a digital signature scheme. Dss EU-CMA-secure is called secure if the maximum success probability InSec^{EU CMA}(Dss(lA); t,q) of all possibly probabilistic adversaries A, running in time < t, making at most q queries to Sign in the above experiment, is negligible in A:

negl(A).

It should be noted that the inventive construction relies on the W-OTS⁺ signature scheme, which is EU-CMA secure as long as the number of oracle queries of A is limited to one (i.e., q = 1).

Finally, an important property for the hash function is reviewed which is a building block of the W-OTS⁺ signature scheme.

Definition 6 (Second preimage resistance). Given a hash function family /A, the success probability of an adversary A against the second preimage resistance of hh is defined as Succ^SPR _Hn (A) = Pr[K $< - {0,l}k; M $< - {0,l}m;

M' $<— A(K,M) : M' ¹ M LHK(M) = HK(M')]

With the preliminaries explained in terms of the EDSAC and W~OTS⁺ signatures, the following explains in more detail the proof of ownership cryptographic protocol as well as the variant on the W-OTS⁺ or eW-OTS⁺. The ownership protocol is described first followed by the eW-OTS⁺.

As noted above, the inventive cryptographic protocol relies on a digital signature. It is assumed that there is a generation algorithm bqh_p (1^l), which outputs the pairs of keys, vk and sk, and backup information bk, whereas the pair (vk, sk) is the regular verification key used for verifying a signature, and the secret key used for issuing a signature, that allows the issuing of an ownership proof p, with the backup information bk, with respect to vk. More concretely, two extra algorithms, (Proof, Verify-proof), are added to the tuple (Gen_re, Sign, Verify), turning into inventive protocol named Sleeve. Given Gen^ (1^l) -> (vk, sk, bk), there is: — Proof(bk, c) -> p: it is a PPT algorithm that on input of the backup information bk and the challenge c, it outputs the ownership proof p;

— ^' Verify-proof(vk, sk, p, c) -> {0,1}: it is a deterministic algorithm that on input of a public-key vk, secret-key sk, a ownership proof p and a challenge c, it outputs either 0, for an invalid proof, or 1 for a valid one.

It should be noted that sk is used as a regular secret key with Sign and Verify. Given the earlier formulation, the property of proof of ownership is introduced.

Definition 7 (Proof of Ownership). For any probabilistic polynomial time (PPT) algorithm A, it holds:

Pr[(vk,sk,bk) Genjt(lA) : (c*,n*) ÷-A(sk,vk)

AVerify-proof(vk,sk,n*,c*) = 1] < negl(A) for all the probabilities are computed over the random coins of the generation and proof verification algorithms and the adversary.

It should be noted that proof of knowledge is not enough on its own. An alternative method to prove ownership of a secret-key, fairly straightforward in discrete logarithm based signatures, relies on regular Zero Knowledge Proof of Knowledge protocol (ZKP), when the signer simply proves the knowledge of secret key. However, in the case where the secret key is leaked, the security guarantees are voided in such method. On the other hand, the earlier introduced definition requires a proof of ownership, despite the secret key being already in possession of the adversary, thus showing that knowledge of the secret key is not enough. The inventive protocol allows a permanent switch from the secret key, sk for example, in the case it is hopelessly public, to a brand new "back up secret key" bk, that is, the new, and still protected, this back up secret key only known to the signer. In addition to the new secret key bk, there is also a new signature scheme where the new verification key is the assumed leaked secret key sk.

The earlier prior art definition for Proof of Ownership is formally not a "proof’ in the sense of ZKP. For example, it is easy to see that is skips completeness and zero- knowledge like security properties. Still following the analogy, the property of the invention is equivalent to the ZKP "soundness."

Definition 8 (FALLBACK)

The scheme (Genjt, Sign, Verify), with secret and verification keys, respectively sk and vk, such that Gen_*(l^λ --> (vk, sk, bk), has fallback if there are sign and verification algorithms Sign, and Verify, such that sk and bk can be used as verification and secret keys respectively, along with Sign and Verify to satisfy Definition 5.

It is worth noting that current blockchain designs are not compatible with hash- based signatures such as W-OTST However, the inventive design could be used to authenticate to a third party, as, for example, in the case of the Trinity attack. Another alternative is to rely on the fallback feature, and the proof of ownership, to transfer the potentially endangered funds to an address or account of a newly created public/private key. In such a case, the ECDSA secret key could be exposed since the fund would be securely transferred to a new and safe pair of keys. The construction for the proof of ownership as presented above is heaviiy based on the W-OTS⁺ signature scheme. Before presenting how to construct such proofs, the adaptation of the original construction is detailed and described in Definition 4, in order to introduce the Extended W-OTS⁺ which will be used in combination with ECDSA.

For the adaptation of W-OTS+, the inventive construction allows users to generate a quantum secure key pair and, from those values, derive an elliptic curve wallet to be used for cryptocurrency transactions. For simplicity of explanation, it is assumed that the quantum -secure key material to be a W-OTS⁺ key pair and the elliptic curve wallet to use the ECDSA algorithm. However, it should be noted that the inventive construction is easily extended to use other cryptographic primitives.

The data structure introduced by Dahmen [10] is relied upon to keep the W-OTS⁺ public key. The L-Tree of height h stores 2^h leaves (such that 2^h ³ l

+ 1, the size of W-OTS⁺ public key). Each node of the tree is denoted by yi[j], for node index from left to right is j= 0,..., 2^j - 1 and i = 0, ..., h, and the root is the node y_o[0]. The nodes of the tree are computed using a hash function H_x selected from a keyed hash family H- {H_X :{0,l}²ⁿ ® (0,l>ⁿ _x&. On a given level / and node j of the tree, each input is computed by the concatenation of the left and right children nodes outputs, after each was bit wise XORed by the masks v,[0] and v[l], for n-bit strings chosen at uniformly at random. More formally, for i = h, ... , 0 and j = 0, ... , 2' — 1, one has yi[j] = Hx((yi+l[2j] 0vi[O])|!(yi+l[2j + 1] 0vi[l])) Since its introduction in Dahmen, see [10], L-Trees have been used in combination with hash based signature schemes, see [16]. For simplicity, a typical combination is described between W-OTS⁺ and L-Tree. Later, this construction is adapted to suit the inventive construction, i.e., the Extended W-OTS⁺. The L-Tree construction introduces three extra sets of values for the verification key W-OTS, in addition to vk = (vko, vk, , vkx) as given by Table 2. They are

—The hash family index x;

—The XOR masks v, [0] and vi [1] for i = 0, h;

—The root value y₀ [0].

In order to create a new wallet, a user randomly generates a cry ptogra phi ca Insecure seed value, to be used to derive the W-OTS⁺ public seed, the W-OTS⁺ secret keys (ski, ski), and the hash key x. Once the derivation step is completed, clients use the chaining function to obtain all the W-OTS⁺ ladder values. The top ladder values are the components of the W-OTS+ public key, which are compressed into a single value using the earlier described L-Trees. Let this value be L_z(vk₀, .... ykj) for the set of h XOR masks and hash family index x.

A new construction for W-OTS⁺ is proposed, which as noted above is called Extended W-OTS⁺ (eW-OTS⁺). The motivation of the novel design is to allow the nesting of the W-OTS⁺ public key into a regular ECDSA secret key, and yet allow the construction of proofs of ownership. This combination of keys will be presented later. The main differences between W-OTS⁺ and the eW-OTS⁺ design are (1) the key generation algorithm incorporates the typical construction with L- Tree earlier described into the key generation, (2) the regular W-OTS⁺ public key is changed to pk, and (3) the secret key tuple has an extra term, i.e,, sko, instead of the regular terms sk, .... sk*. The full construction is given by Definition 9.

Definition 9 (eW-OTS⁺). Given the security parameter k, a chaining function c, and k < -K from the key space K, an unkeyed hash function H, then the eW-OTS* signature scheme is the tuple (Gen_ew , Sign_ew, Verify_ew), defined as in Table 3, which is found below.

Table 3. Extended W-OTS⁺ Signature Scheme. It should be noted that the Extended W-OTS⁺ construction has as key pair (sk, pk) which differs from the regular construction (sk,vk) of W-OTS⁺. The reader will certainly notice the need for the notation change in the public key from vk to pk in the next section, when the combination between ECDSA and eW- OTS⁺ is described and both terms are used.

The ECDSA Key Pair from eW-OTS⁺ will now be discussed. It is assumed that the elliptic curve wallet is generated in a one-way manner, which means that if the ECDSA wallet is compromised, then the user can prove ownership of the wallet by providing a signature from the eW-OTS⁺ key pair, which is assumed secure. More formally pk = (vk₀, L, sk₀), as defined in Table 3, is the input in a unkeyed hash function // resulting in H (vko, H (L, sk₀)), which is the ECDSA private key, sk, and can be used to calculate the public key using the trapdoor function of the signature scheme. The ECDSA public and secret key are, respectively, sk_EDsc_A=//(Vko_//7(L, sko); and

Figure 1 represents a base description of the inventive construction. A user generates a post-quantum (PQ) key pair (PQsk,PQpk) along with a hash key X from a local randomness seed, which is used as an input when hashing the fallback public key. The result of the hashing operation is used as an elliptic curve secret key, Elliptic Curve Cryptography secret key, then used as elliptic curve cryptography (ECC) trapdoor and obtain the elliptic curve public key Elliptic Curve Cryptography public key,

Figure 2 illustrates a simplified diagram of the construction. In general, the dotted boxes are the potentially public values, while the norma! boxes are the secret values. The diagram shows the commonly known ladders, i.e,, the sequence of hash function executions up to the verification values and the "rng seed" generating randomness for the private key hash x. More particularly, a user randomly generates a cryptographically-secure seed value 1, to be used to derive the W-OTS⁺ public seed 3, the W-OTS⁺ secret keys fsk,, ..., sk^ 5, and the hash key x7. Once the derivation step is completed, the chaining function is used to obtain all the W-OTS⁺ ladder values, designated as 9. The top ladder values 11 are the components of the W-OTS⁺ public key, which are compressed into a single value 13 using the earlier described L-Trees. Let this value be L_VfX(v ko, vki, ... vkt).

Then (eW-OTS⁺)pk = (vk₀, L, sko) as 15 in Figure 2 is the input in a unkeyed hash function H resulting in H (vko, H (L, sk₀)), which is the ECDSA private key, sk, or 17 in Figure 2. This private key sk can be used to calculate the public key 19 using the trapdoor function of the signature scheme.

Figure 3 shows a similar construction to that of Figure 2 using a tweak. Here, a user generates the WOTS⁺ secret key values, along with a public seed (P), a tweak (T), and a secret hash key {H), The user applies the corresponding WOTS⁺ hash chaining function to each of the secret key values and obtains the top ladder values (vj ... vi). To obtain a compressed WOTS⁺ public key, the user applies a Tweakable Hash function using as input the following values: Public seed (P), Tweak (T), and the top ladder values. From this compressed public key value, the user generates an ECDSA secret key by applying a Tweakable Hash (Th) function with the following input values: Public Seed (P), hash key (x), and WOTS* Compressed PK. The user then applies the corresponding trapdoor. In this case, one multiplies the ECDSA secret key by the group Generator G.

Typically, cryptocurrencies, such as Bitcoin [21], Ethereum [25], Cardano [2], for wallet addresses are built by hashing the ECDSA public key. Therefore, to integrate the inventive construction in certain settings, an additional hash of the elliptic curve public key value is necessary, i.e., A{vk_EC_DS_A).

The following details ownership, proof generation, and verification. As described above, the signature scheme that offers proof of ownership is a tuple (Genu, Sign, Verify, Proof, Verify-proof), such that Gen

® (vk, sk, bk), Proof (bk, c) ® p and Verify-proof (vk, sk, bk) ® {0,1}. In order to construct such scheme, the ECDSA and eW-OTS⁺ designs are combined. The generation and verification of signatures are respectively carried by Sign and Verify as regular ECDSA signatures. The proof of ownership is put forth by the eW-OTS⁺ design via the Proof and Verify-proof algorithms. Put simply, the tuple (vk, sk) is the regular ECDSA key pair, such that sk is generated from the underpinning eW-OTS⁺ public key pk. Whereas bk is the eW-QTS⁺ secret key (sko, sk, , skf) corresponding to pk. It remains to introduce the ΰehp algorithm to generate the tuple (vk, sk, bk). The following relates to the generation of the "back up key". Intuitively, the proof of ownership of the key, requires similar properties of an identification scheme between a prover and a verifier instantiated by a particular signature scheme. In the inventive construction, the identification scheme is based on the earlier introduced eW-OTS⁺ design. More concretely, given a challenge as a message provided by the verifier, the prover only needs to sign this message with bk. As described earlier, let the ECDSA key pair be sk = /^pk), for pk= (vko, L, sko), and vk = H (vko, H (L, sk₀)) for an unkeyed hash function H. Therefore the "back up secret key" bk is (sko,...,, sk_t), the eW-OTS⁺ secret-key, is illustrated in

Table 3.

For completeness, the construction is presented of algorithm Gen

® (vk, sk, bk). Note that in the following construction, the key pair (vk, sk) can be used as regular signature (i.e., for the ECDSA Signature), that is with algorithms (Sign, Verify) as in Table 1.

The following relates to Generation and Verification of the Proof. Whereas the regular ECDSA signatures are generated and verified via the pair of algorithms (Sign, Verify) and the keys (sk, vk) generated via construction Table 2, the proof generation and verification are done via the algorithms for W-OTS⁺ described by Table 3. More concretely, the algorithm Proof^s (bk c), for a challenge c, is implemented by the algorithm Sign_ew, whereas the proof verification Verify-proof (vk, sk, p, c) is based on an adaptation of the signature verification Verify^k _ew (pk, s, m). The full description of the procedure is in Table 5. It should also be understood that the construction can be extended to provide multiple proofs of ownership by adding more eW-OTS⁺ instances "underneath" the main one presented in Table 4.

Table 4. The algorithm Gen„, likewise the eW-OTS⁺ construction, adds a L data structure into its procedure, and outputs also the “back up secret key” bk.

For the purpose of this disclosure, it is not necessary to fully describe the algorithms as such would be understood by one of skill in the art. However, an informal description of the construction is presented below.

From a practical consideration, the back up key bk is not necessary to the regular use in combination with the ECDSA scheme, i.e., the blockchain use. In order to guarantee a secure and legit use of the bk, that is the generation of proof of ownership in case of a catastrophic leakage, bk should be kept in a separate storage, i.e., cold storage.

The following discussion relates to ownership, fallback and eW-OTS⁺ security. This relates to the properties of the inventive construction for S_lee_ve providing fallback and generation of proof of ownership. However, first the security level provided by the inventive design based on the eW-OTS⁺ construction of Table 3 is described. It is considered as a security level A if a successful attack is expected to require on average 2^{λ 1} evaluations of the used hash function family.

For the unforgeability of eW-OTS⁺, the security of the extended W~OTS⁺ is based on the existential unforgeability of the underlying W-OTS⁺ signature scheme and the (multi-target) second preimage resistance of the used hash function. Recall that the existential unforgeability under chosen message attack (EU-CMA) for one time signature schemes is defined when the number of signature queries is limited to 1, see [15]. Then, the following theorem applies. Theorem 1. Given the EU-CMA security of W-OTS, the Extended W-OTS⁺ from Table 3 is existentially un forgeable under adaptive chosen message attacks, if H_n is from a second-preimage resistant hash function family. /

Proof for W-OTS^± uses a family of functions F_n : {f_k : {0, l}ⁿ — > {0, l}ⁿ I k€

Kn} with a key space Kn. It is known from [15] that, to attack the EU-CMA property, an adversary A must be able to break the following security level, li, such that li > n-\oqi ( M¾+ IF). Alternatively, A may attempt to subvert the underlying hash function H introduced in the inventive construction.

To successfully attack this additional step introduced in the extended W- OTS⁺ and produce a forged signature, A must break the second-preimage resistance property of //and find a colliding L(W-OTS⁺v_k)' that matches the target hash output.

It is shown in the Appendix below that the cost of this attack for an n-bit hash is 2ⁿ. Additionally, it is known that in a real-world cryptocurrency setting, the adversary has the advantage of being able to perform multi-target attacks on any of the existing //outputs, which results in the following security level of λ2≤ n₁ - log2(d). Given the above tight bounds, the security level (l) of the extended W- OTS⁺, which is l < min {λ1, λ2}.

For simplicity, it is assumed that n = n1. Therefore, it is obtained that the best attack against the extended W-OTS⁺ construction is the same attack against the original W-OTS⁺. As a result, if the adversary is able to break the EU-CMA property of the extended W-OTS⁺, then it can break the unforgeability of the original W-OTS+. Therefore, the inventive construction is no weaker than the original as long as the output of the used hash function H is n1 > n .

In terms of security regarding ownership and fallback, it is now described the security of the inventive scheme (Gen_π, Sign, Verify, Proof, Verify-proof)· Given the eW-OTS⁺ construction from Table 3, let Sign_ew be the algorithm Proof, Gen_π is given by Table 4, while Verify-proof is given by Table 5 below, finally Sign and Verify are the ECDSA algorithms for signing and verifying signatures, respectively. For readability, let (Gen,_t, Sign, Verify, Proof, Verify-proof) be known as Sleeve, (as already mentioned above). Then, the following properties of Sleeve can be claimed.

Table 5. The verification of the proof 7 r adapts the verification procedure for eW-OTS⁺ by adding an extra check on the ECDSA verification key vk.

Corollary 1. S_lee_ve generates a single proof of ownership it as per Definition 7 flnoD/XSketch) The proof p is an eW-OTS⁺ signature on a challenge c. Given the security of eW-OTS⁺ stated by Theorem 1, thereby p generated by Sleeve satisfies Definition 7.

Now it is shown that tuple (Gen*, Sign, Verify), parsed from Sleeve provides a fallback signature scheme. Theorem 2. The tuple (Gen_*, Sign, Verify), derived from S_leeve, has the fallback property as per Definition 8.

Proof (Sketch) Following Definition 8, it is shown that there are algorithms Sign_rc, and Verify*, such that sk and bk can derive regular verification and secret signatures. By considering the original construction Sieeve, it is that Sign* -Proof and Verify* = Verify-proof, and this ends the proof.

In this section, selected issues are discussed and open problems are analyzed as well as some other challenges in the inventive technology.

For fail-stop Signatures, traditional digital signatures allow a user Alice to produce signatures such that everyone who knows the public key of the signer Alice can verify such signature. Such signatures are computationally secure for the signer as they can be forged by an adversary with quantum capabilities. Once a signature is forged, it is difficult for the honest signer Alice to convince third parties that she did not produce the forged signature. Fail-stop signatures, see [24], solve this problem by offering the signer a method to prove that a forgery took place. After receiving such a proof, the system should be stopped. As a result, the signer is protected from an arbitrarily powerful forgery since all participants, or an eventual system operator, know the signature scheme is broken, and should halt the system.

A possible enhancement for inventive Sieeve is to alter the key generation to support the integration of fail-stop signatures. Instead of generating an ECDSA keypair from a hash-based key, users can generate a fail-stop keypair as this would allow a user to prove that a rogue signature is indeed a forgery and therefore instantiate the backup key to prove the true ownership of a key pair.

For tweakable hash functions, in hash-based signature schemes, it is important to use constructions that use security notions such as second preimage and preimage resistance instead of collision resistance. Different hash-based schemes focus on different ways to achieve these more specific security notions as they substantially enhance the security level of the produced signatures. However, the main idea behind the different constructions to achieve these specific security notions is similar enough that it is possible to create an abstraction, such that it is not necessary to provide a new security analysis for each of the alternatives to move towards (second) preimage resistance.

The work from [5] introduces an abstraction-called tweakable hash functions— which allows protocol designers to unify the description of hash-based signature schemes, separating the exact details of how the scheme computes tree nodes typically used in hash-based constructions. This division allows for the separation of the analysis of the high-level construction from the analysis of how this computation is done. As a result, changing the way nodes are computed in a hash-based signature scheme only requires analyzing the hashing construction as a tweakable hash function.

One optimization that is introduced is the use of tweakable hash functions to compress all the W-OTS⁺ top ladder values into a single root value, which results in a more simplified implementation with better performance. For cold storage, using S_leeve does not necessarily imply that both the ECDSA secret key and the backup key should be stored in different cold storage units. For example, a quantum adversary can gain rogue access to an ECDSA secret key by breaking the discrete log problem using only public information such as the public keys that are present in a blockchain. In this setting, the fallback key remains securely stored and can be freely used by the wallet owner.

To increase the security of Sleeve it is possible, however, to use different storages for the secret key and the backup key to ensure that if a wallet owner moves the ECDSA secret key to a hot wallet, and such a wallet is compromised, then the owner remains protected as the adversary A should not be able to gain access to the cold wallet containing the Sleeve backup key.

For backwards compatibility, ideally, users should be able to use the ideas behind Sleeve to use the seed phrase of a hierarchical deterministic wallet and retroactively prove ownership of a specific wallet address. The feasibility of this remains undefined and represents an interesting future work challenge as it would allow any user to utilize this approach and have the ability to prove ownership of wallet address with guaranteed backwards compatibility with any wallet that supports the use of seed phrases to generate hierarchical deterministic wallets. It should be noted that the inventive construction preserves the structure of both the ECDSA private and public keys, and if the user actually relies on two different cold storage solutions— one for the ECDSA key and the other for the Sleeve backup key— then it is possible to achieve backwards compatibility as the storage of the ECDSA key pair does not require any particular or different treatment.

To support the Sleeve backup key, however, both the wallets and the blockchain may require protocol modifications. Wallets require modification to have the ability to generate hash-based signatures, while the blockchain needs to be modified to have the ability of verifying these hash-based signatures.

For compatibility with different post-quantum signature schemes, the Sleeve is designed in a modular manner that allows the hiding of any quantum secure signature key pair, and is not exclusive to W-OTS⁺. Here, the focus is particularly focus on W- OTS⁺ as a fallback for ECDSA because it corresponds to the real-world use case that inspired the creation of the construction. Platforms, however, have the flexibility to use different signature schemes accordingly.

For informal multiple proofs construction, the inventive construction described above allows only a single proof. The reason is that eW-OTS⁺signature scheme is a one-time signature scheme. However, a construction to allow the generation of several proofs is also within the scope of the invention. The basic change is in the generation of the secret-key tuple bko, bki,...,bk£. Whereas in the previous constructions of Tables 3 and 4 the values in the tuple are picked at random, the extended version computes t tuples, where each set of values

is generated from executing a Key Derivation Function (KDF) from the previous tuple

^.^bk^^-1)), for j <t. More concretely, bki(j— 1) = KDF(L®) and hk^-¹⁾ =

KDF(LG)| |^saft0-1)| |(/) for 1 < i < JL, randomly chosen values salt^^-1) and the L-Tree root value L® of the underlying construction i.e. eW-OTS⁺ instance with index j. Thus, for a t-backup key value construction, the generation is as follows:

- Pick bk® = (x®,vi® [0],vi®[l],...,v® iogi[0], v® _{|0g i}[i] for 1 <j <t;

- Pick vko® = (r®,k®), for 1 < j < t, and (r®,k®) chosen as (r,k) in Table 4;

- Pick random values (bki®,...,bk| ®;

Given bko® and (bki® bki ®, compute L®;

Compute

and randomly chosen values salt^0”15.

The intuition is to add t -1 eW-OTS+ constructions "underneath" the upmost one. The public key of the underlying eW-OTS+ instance, generates, via KDF (which can be constructed by a hash function), the secret key of the next (i.e., bki^0”15, the last line of the above description).

The verification algorithm for such multiple construction has to take into account in which "level" (from t to 0, in the above description) the signature was generated, and be continually updated on each new signature generation. For comparison, the construction for a single proof only has one level. The "multilevel" p-th proof is of the form p = ((po,..., p ju +¾), (vko^Ci5,sko^{1),L<¹⁵, salt⁽¹⁾),..., (vko^ip+1),sko^(p+1) ,L^(p+1),salt®⁺¹⁵),

Thus, the verification procedure transverse the underneath structure of eW-OTS⁺ instances from some point p, i.e., the p-th proof, up to the upmost one 1. Roughly the procedure is as follows:

- Compute vkj

Compute

For p -1 < j <1,

- Compute

~ Compute

- Compute L®

at this point the verification boils down to the correctness of the value L = L(l) as before,

The following section discusses applications of the invention. This section is divided into two parts. First, a concrete example is provided as to how to proceed upon suspecting the existence of a successful attack against the computational assumptions that ensure the security of the ECDSA algorithm. Secondly, different real-world use cases are introduced that allow users to prove ownership of their wallet in the event where the ECDSA secret key is leaked, but the Sleeve backup key remains safe.

F!ard Fork. If an attacker A is able to steal the secret keys behind a cryptocurrency wallet, then A is able to steal all the funds associated with that wallet. Since a Sleeve proof-of-ownership does not convince A to return the stolen funds, at first glance it may appear that there is no reason to have a fallback mechanism as all these funds are gone.

Sleeve is better suited for situations where the signature scheme associated with the quantum-secure backup can be used as a direct replacement for the original scheme. In a b!ockchain, this signature transition is only possible by making significant changes in the protocol, which create an alternative blockchain. This process is known as a hard fork. Using the inventive construction, any blockchain can perform a signature scheme transition and allow any user to claim ownership of potentially stolen funds. As quantum algorithms become practical, blockchain platforms can recommend their users to create new wallet addresses using the Sleeve structure such that, when a hard fork is required, any user can produce a proof-of-ownership to transfer the funds to an address containing a new public key.

Sleeve becomes even more applicable in token sales settings where the smart contracts enforce lockup periods to restrict buyers from selling purchased tokens.

If there is evidence of a quantum attack against a blockchain, users can utilize the Sleeve construction to prove ownership of potentially compromised tokens and redeem them in an alternative manner while the lockup period is still active, thus ensuring that no theft occurs.

Revoking Wallet Addresses. It is extremely important for users to have the ability to revoke a wallet address they own. Therefore, user Alice should have the ability notify the network that a specific wallet address is to be considered invalid and rejected by the nodes when attempting to make a payment. Alice, in this example, has her ECDSA secret key stolen and revokes her stolen wallet address by creating a proof-of-ownership, using her backup key, to inform the network that her address is compromised and, simultaneously introduce a new wallet address to contain the funds associated with the initial wallet.

Insurance. An insurance company may, for example, need to refund a group of protected customers after a set of ECDSA private keys are leaked and the associated funds stolen. Any user whose key is present in this leak, if in possession of their S_leeve backup key, can remotely prove that they are the true owners of a specific wallet address and prove to the insurance company that they are entitled to the refund. The insurance company knows that an adversary is not able to produce such a forgery unless both keys are compromised.

To validate the invention, a single-threaded prototype in Golang was implemented. It should be noted that this implementation does not combine the W-OTS⁺ public key values using an L-Tree structure. Instead, the implementation uses a tweakable hash function to combine all the W-OTS+ ladder top values into a single root value, see Figure 3. Since the inventive construction has a very concrete application, an additional implementation variant was implemented that includes the B1P 39 161 standard to generate the hidden W-OTS^' fallback from a mnemonic seed. The correctness of this code is verified by comparing it with reference BIP39 implementations, see [7,13].

The experiments were run on a 2.8 GHz Quad-Core Intel Core 17 with 1603 of RAM, running 64-bit macOS 10.15.6. Below, is a table containing the corresponding performance of the prototype.

Table showing Performance metrics of the inventive implementation.

The timings shown in the Table immediately above demonstrate that the key generation component of the inventive design is significantly slower than presently used key generation mechanisms. Depending on the protocol instantiation, the inventive key generation is between 50% to 100% slower than a normal ECDSA key generation algorithm. We highlight, however, that this is an expected result given the amount of additional steps introduced by the inventive construction. It should also be noted that the key generation can be easily accelerated by performing the W-OTS⁺ ladder calculations in parallel. Regarding key storage, the inventive construction utilizes the same storage space as a normal ECDSA private key. For example, the wallet storage of a Bitcoin secret key would require 256-bits for both the S_leeve construction and for a normal wallet.

As such, an invention has been disclosed in terms of preferred embodiments thereof which fulfills each and every one of the objects of the present invention as set forth above and provides a new and improved key generation mechanism that allows users to generate a back up key and use the back up key if their secret key is compromised to allow either continued use of the signature scheme or prove ownership of the secret key. Of course, various changes, modifications and alterations from the teachings of the present invention may be contemplated by those skilled in the art without departing from the intended spirit and scope thereof. It is intended that the present invention only be limited by the terms of the appended claims.

APPENDIX

The earlier-presented constructions are hash-based ones, therefore in this section, an extensive list is presented of computational complexities of various generic attacks against hash functions, while relating them with the inventive constructions. Later these complexities are relied upon to analyze and prove security of our proposed signature scheme.

Preimaae resistance. The adversary A may obtain a hash digest and attempt to invert the one-way property of the used hash function. Assuming that the inputs are uniform random n-bit values, then this preimage attack costs 2ⁿ in the classical setting. In the post-quantum setting, using Grover's algorithm, this attack costs 2ⁿ>².

Second preimaae resistance fSPR). The adversary may instead attempt to find a second preimage of an n-bit message. Assuming a non-compressing hash function, that is, there is at least an n-bit-to-n-bit preimage to hash mapping, then this attack costs 2ⁿ in the classic setting, and 2^n/2 in the post-quantum setting.

Enhanced target collision resistance (eTCR). The notion of eTCR implies that an adversary is allowed to choose a target message M. Upon choosing this target message, A learns the function //¾r (by learning the key K) and the adversary wins after presenting a new message M' and a (possibly new) key /f'such that HK(M)= HK’(M).

A possible application of the eTCR game in the inventive setting involves the adversary committing to a L(W-OTS\k) public key value and then obtaining the hash function key. There are two ways an adversary may attempt to break the eTCR property of a hash function. First, A may attempt to obtain a new L(W- OTS⁺vk)¹ such that /*(L(W-OTS⁺ _vk)) = tk L(W-OTS⁺ _vk)')· Second, A may attempt to obtain a new key K' a nd L(W-OTS⁺ _vk)' such that Afc(L(W-OTS⁺ _vk)) = tk L(W- OTS\_k)').

If A owns the secret keys corresponding to the colliding L(W-OTS⁺ _vk)’, then A can forge a proof of ownership of the target wallet. This forgery costs at least 2ⁿ pre-quantum, 2^n/2 post-quantum (Grover's algorithm), and results in the adversary having the ability to prove ownership of an elliptic curve based wallet with a different fallback public key. It is highlighted, however, that even if the adversary can find a second preimage, it is not guaranteed that it corresponds to a L(W-OTS⁺ _vk)' actually controlled by A.

Mu!ti-taraet attacks. The previous definitions assume an adversary attacking one single target. We assume a hash function with n-bit outputs is used d times and each of these d outputs is publicly posted ( e.g ,, on a blockchain). The adversary A may, therefore, attempt to invert any of these public lvalues, which results in an attack complexity of 2^n'log2i* instead of 2ⁿ. In order to show the effectiveness of a multi-target attack, we consider the case where all the secret keys associated with the wallet addresses are publicly exposed and are generated using the inventive hidden key construction. This setting results in a leakage of approximately 2²⁹ target wallet addresses, see for example, [12, 8], which results in an attack complexity cost of 2^n'29. Typically, ECDSA secret keys are 256 bits. Therefore, a multi-target attack in the setting described herein results in a direct loss of 29 bits in security, resulting in a cost of 2²²⁷ instead of 2²⁵⁶. In a postquantum setting, however, the adversary must perform 2ⁿ/²/d^1/2, where d < 2^n/3. Decisional second-nreimaoe resistance (DSPR). In [4] Bernstein and Htilsing introduce DSPR, which defines the advantage in deciding, given a random input x, whether xhas a second preimage.

An adversary could potentially use this definition to determine in advance whether or not it is worth attacking the SPR (or eTCR) of a hash function. If the DSPR advantage is non-negligible, then the adversary can choose a wallet target, and determine in advance whether or not there is a second-preimage. For example, if there is not a second-preimage associated with a target wallet address, then the adversary can select another target address as opposed to spending unnecessary computational resources trying to find a non-existent value. The paper, however, proves that DSPR is at least as hard to break as preimage resistance (PRE) or second preimage resistance (SPR) for uniform random hash functions from {0,l}ⁿ to (0, l}ⁿ. This results in an attack cost of 2ⁿ in the classical setting, and 2^n/2 in the postquantum setting.

The inventors considered ways to attack DSPR for real hash functions, and concluded that there is no obvious way for a fast attack to achieve any advantage. Consequently, A cannot take advantage of the DSPR notion to gain any non-negligible advantage in creating forged proof(s)-of-ownership. The work of Banegas and Bernstein [3] studies the existing overhead beyond the quantum queries and shows that even in a post-quantum setting, the collision-finding algorithms costs at least 2ⁿ², even if it requires a smaller number of queries.

References:

1. Myrto Arapinis, Andriana Gkaniatsou, Dimitris Karakostas, and Aggelos Kiayias. A formal treatment of hardware wallets. In Ian Goldberg and Tyler Moore, editors, FC 2019: 23rd International Conference on Financial Cryptography and Data Security, volume 11598 of Lecture Notes in Computer Science, pages 426-445, Frigate Bay, St. Kitts and Nevis, February 18-22, 2019. Springer, Heidelberg, Germany.

2. Christian Badertscher, Peter Gazi, Aggelos Kiayias, Alexander Russell, and Vassilis Zikas. Ouroboros genesis: Composable proof-of-stake blockchains with dynamic availability. In David Lie, Mohammad Mannan, Michael Backes, and XiaoFeng Wang, editors, ACM CCS 2018: 25th Conference on Computer and Communications Security, pages 913-930, Toronto, ON, Canada, October 15-19, 2018. ACM

Press.

3. Gustavo Banegas and Daniel J. Bernstein. Low-communication parallel quantum multi-target preimage search. In Carlisle Adams and Jan Camenisch, editors, SAC 2017: 24th Annual International Workshop on Selected Areas in Cryptography, volume 10719 of Lecture Notes in Computer Science, pages 325-335, Ottawa, ON, Canada, August 16-18, 2017. Springer, Heidelberg, Germany.

4. Daniel J. Bernstein and Andreas HOIsing. Decisional second-preimage resistance: When does SPR imply PRE? In Steven D. Galbraith and Shiho Moriai, editors, Advances in Cryptology - ASIACRYPT 2019, Part III, volume 11923 of Lecture Notes in Computer Science, pages 33-62, Kobe, Japan, December 8-12, 2019. Springer, Heidelberg, Germany.

5. Daniel J. Bernstein, Andreas HOIsing, Stefan Ko!bl, Ruben Niederhagen, Joost Rijneveld, and Peter Schwabe, The SPHINCS+ signature framework. In Cavallaro et al. [9], pages 2129-2146.

6. Mnemonic code for generating deterministic keys, https://github.com/bitcoin/ bips/blob/master/bip-0039.mediawiki. Accessed: 2020-01-20. 7. Mnemonic code converter, https://iancoleman.io/bip39/. Accessed: 2020-01.20.

8. Study finds less than 40% of btc addresses are economically relevant. https://news.bitcoin.com/study-finds-less-than-40-of-btc-addresses-are-economically- relevant/. Accessed: 2020-09-18.

9. Lorenzo Cavallaro, Johannes Kinder, XiaoFeng Wang, and Jonathan Katz, editors. ACM CCS 2019: 26th Conference on Computer and Communications Security. ACM Press, November 11-15, 2019.

10. Erik Dahmen, Katsuyuki Okeya, Tsuyoshi Takagi, and Camiiie Vuiilaume. Digital signatures out of second-preimage resistant hash functions. In Johannes Buchmann and Jintai Ding, editors, Post-quantum cryptography, second international workshop, PQCRYPTO 2008, pages 109-123, Cincinnati, Ohio, United States, October 17-19 2008. Springer, Heidelberg, Germany.

11. Poulami Das, Sebastian Faust, and Julian Loss. A formal treatment of deterministic wallets. In Cavallaro et al. [9], pages 651-668.

12. Ethereum unique addresses chart, https://etherscan.io/chart/address. Accessed: 2020-09-18.

13. Implementation of wots up my sleeve, https://github.com/yaksetig/sleeve. Accessed: 2021-04-01.

14. Golang implementation of the bip39 spec, https://godoc.org/github.com/tyler- smith/go-bip39. Accessed: 2020-09-20.

15. Lov K. Grover. A fast quantum mechanical algorithm for database search. In 28^th Annual ACM Symposium on Theory of Computing, pages 212-219, Philadelphia, PA, USA, May 22-24, 1996. ACM Press.

16. Andreas HOIsing. W-OTS-f- - shorter signatures for hash-based signature schemes.

In Youssef et al. [27], pages 173-188.

17. Andreas Hiilsing, Joost Rijneveld, and Fang Song. Mitigating multi-target attacks in hash-based signatures. In Chen-Mou Cheng, Kai-Min Chung, Giuseppe Persiano, and Bo-Yin Yang, editors, PKC 2016: 19th International Conference on Theory and Practice of Public Key Cryptography, Part I, volume 9614 of Lecture Notes in Computer Science, pages 387-416, Taipei, Taiwan, March 6-9, 2016. Springer, Heidelberg, Germany.

18. Michael Hutter and Peter Schwabe. NaCI on 8-bit AVR microcontrollers. In Youssef et al. [27], pages 156-172.

19. Dimitris Karakostas, Aggelos Kiayias, and Mario Larangeira. Account management in proof of stake ledgers. In Clemente Galdi and Vladimir Kolesnikov, editors, Security and Cryptography for Networks, pages 3-23, Cham, 2020. Springer International Publishing.

20. Leslie Lamport. Constructing digital signatures from a one-way function. Technical Report SRI-CSL-98, SRI International Computer Science Laboratory, October 1979.

21. Ralph C. Merkle. A certified digital signature. In Gilles Brassard, editor, Advances in Cryptology - CRYPTO'89, volume 435 of Lecture Notes in Computer Science, pages 218-238, Santa Barbara, CA, USA, August 20-24, 1990. Springer, Heidelberg, Germany.

22. Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system, 2009.

23. Peter W. Shor. Polynomial-time algorithms for prime factorization and discrete logarithms on a quantum computer. SIAM Journal on Computing, 26(5): 1484-1509, Oct 1997.

24. Trinity attack incident part 1: Summary and next steps, https://blog.iota.org/trinity- attack-incident-part-l-summary-and-next-steps-8c7ccc4d81e8. Accessed: 2020-09-22.

25. Eugene van Heyst and Torben P. Pedersen. How to make efficient fail-stop signatures. In Rainer A. Rueppel, editor, Advances in Cryptology - EUROCRYPT'92, volume 658 of Lecture Notes in Computer Science, pages 366-377,

BalatonfOred, Hungary, May 24-28, 1993. Springer, Heidelberg, Germany.

26. Gavin Wood. Ethereum: A secure decentralised generalised transaction ledger. Ethereum project yellow paper, 151:1-32, 2014.

27. Amr Youssef, Abderrahmane Nitaj, and Aboul Ella Hassanien, editors. AFRICACRYPT 13: 6th International Conference on Cryptology in Africa, volume 7918 of Lecture Notes in Computer Science, Cairo, Egypt, June 22-24, 2013, Springer, Heidelberg, Germany.

Claims

WE CLAIM:

1. In a secret key-using digital signature, the improvement comprising a back up key embedded in the secret key of the digital signature, the back up key allowing a user a fallback, wherein the user can continue to use the digital signature, or a proof of ownership, wherein a user can prove to a third party that the user is the owner of the secret key.

2. The digital signature of claim 1, wherein the digital signature uses an elliptic curve digital signature algorithm for generation thereof.

3. The digital signature of claim 1, wherein the back up key is the secret key of a hash- based signature and the secret key is based on a public key derived from the hash- based signature.

4. The digital signature of claim 3, wherein the hash-based signature is based on a variant of a Winternitz one time signature.

5. The digital signature of claim 1, wherein the fallback and proof of ownership comprise cryptographic protocols that respectively output an ownership proof p based on the back up key and a challenge c and verify a validity of ownership proof p using a verification key, the secret key, the back up key, the ownership proof p, and a challenge c.

6. In a method of generating a secret key-using signature, the improvement comprising embedding a back up key in the secret key of the digital signature, the back up key allowing a user a fallback, wherein the user can continue to use the digital signature, or a proof of ownership, wherein a user can prove to a third party that the user is the owner of the secret key.

7. The method of claim 6, wherein the digital signature uses an elliptic curve digital signature algorithm for generation thereof.

8. The method of claim 6, wherein the back up key is the secret key of a hash-based signature and the secret key is based on a public key derived from the hash-based signature.

9. The method of claim 8, wherein the hash-based signature is based on a variant of a Winternitz one time signature.

10. The method of claim 6, wherein the fallback and proof of ownership comprise cryptographic protocols that respectively output an ownership proof p based on the back up key and a challenge c and verify a validity of ownership proof p using a verification key, the secret key, the back up key, the ownership proof p, and a challenge c.

11. Cryptographic protocols for use with a secret key-using digital signature that includes a back up key embedded in the secret key of the digital signature, the back up key allowing a user a fallback, wherein the user can continue to use the digital signature, or a proof of ownership, wherein a user can prove to a third party that the user is the owner of the secret key, cryptographic protocols respectively output an ownership proof p based on the back up key and a challenge c and verify a validity of ownership proof p using a verification key, the secret key, the back up key, the ownership proof p, and a challenge c.

12. In a digital wallet that stores a secret key that permits spending of cryptocurrency funds, the improvement comprising the digital signature of claim 1.

13. The digital wallet of claim 12, wherein the digital wallet is an elliptic curve digital signature algorithm based digital wallet.