Short attribute-based signatures for arbitrary Turing machines from standard assumptions

Abstract

This paper presents the first attribute-based signature (ABS) scheme supporting signing policies representable by Turing machines (TM), based on well-studied computational assumptions. Our work supports arbitrary TMs as signing policies in the sense that the TMs can accept signing attribute strings of unbounded polynomial length and there is no limit on their running time, description size, or space complexity. Moreover, we are able to achieve input-specific running time for the signing algorithm. All other known expressive ABS schemes could at most support signing policies realizable by either arbitrary polynomial-size circuits or TMs having a pre-determined upper bound on the running time. Consequently, those schemes can only deal with signing attribute strings whose lengths are a priori bounded, as well as suffers from the worst-case running time problem. On a more positive note, for the first time in the literature, the signature size of our ABS scheme only depends on the size of the signed message and is completely independent of the size of the signing policy under which the signature is generated. This is a significant achievement from the point of view of communication efficiency. Our ABS construction makes use of indistinguishability obfuscation (IO) for polynomial-size circuits and certain IO-compatible cryptographic tools. Note that, all of these building blocks including IO for polynomial-size circuits are currently known to be realizable under well-studied computational assumptions.

1 Introduction

In a traditional digital signature scheme, each signer possesses a secret signing key and publishes its corresponding verification key. A signature on some message issued by a certain signer is verified with respect to the public verification key of the respective signer, and hence during the verification process, the explicit signer gets identified. In other words, standard digital signatures can guarantee no privacy in the relationship between signers and claims attested by signatures due to the tight correspondence between the signing and verification keys.

Attribute-based signatures (ABS), introduced by Maji et al. [19], aims to relax such a firm relationship between signers and signatures issued by them, thereby ensuring some form of signer privacy. ABS comes in two flavors, namely, key-policy and signature-policy. In a key-policy ABS scheme, a setup authority holds a master signing key and publishes system public parameters. Using its master signing key, the authority can give out restricted signing keys corresponding to specific signing policies. Such a constrained signing key enables a signer to sign messages with respect to only those signing attributes which are accepted by the signing policy embedded within the signing key. The signatures are verifiable by anyone using solely the public parameters. By verifying a signature on some message with respect to some signing attributes, a verifier gets convinced that the signature is indeed generated by a signer possessing a signing key corresponding to some signing policy that accepts the signing attributes. However, the verifier cannot trace the exact signer or signing policy used to generate the signature. The signature-policy variant interchanges the roles of signing attributes and signing policies. Other than being an exciting primitive in its own right, ABS has countless practical applications such as attribute-based messaging, attribute-based authentication, anonymous credential systems, trust negotiation, and leaking secrets.

A central theme of research in the field of ABS has been to expand the class of admissible signing policies in view of implementing ABS in scenarios where the correspondence between signers and signatures is more and more sophisticated. Starting with the initial work of Maji et al. [19], which supports signing policies representable by monotone span programs, the family of supported signing policies has been progressively enlarged by Okamoto and Takashima [20] to admit non-monotone span programs, by Datta et al. [6] to support arithmetic branching programs, and further by Tang et al. [25], Sakai et al. [23], Tsabary [26], as well as El Kaafarani and Katsumata [16] to realize arbitrary polynomial-size circuits. On the other hand, Bellare and Fuchsbauer [4] have put forth a versatile cryptographic primitive termed as policy-based signatures (PBS) and have exhibited a generic transformation from PBS to ABS. Their generic conversion can be used in conjunction with their proposed PBS construction to build an ABS scheme for general polynomial-size circuits as well.

While the circuit model is already powerful enough to capture arbitrary computations, an important bottleneck of this model is that it is non-uniform in nature and thus ABS schemes supporting circuit-realizable signing policies can withstand only signing attribute strings of bounded length, where the bound is determined during setup. Another drawback of representing signing policies as circuits is that generating a signature with respect to some signing attribute string using a signing key corresponding to certain signing policy is at least as slow as the worst-case running time of that policy circuit on all possible signing attribute strings. These are serious limitations not only for ABS itself, but also for all the aforementioned applications of ABS

In this paper, we aim to express signing policies in a uniform computational model, namely, the Turing machine (TM) model, which is the most natural direction to overcome the above problems. First, we would like to mention that concurrently and independently to our work, Sakai et al. [24] have developed an ABS scheme which can withstand TM-realizable signing policies under the symmetric external Diffie–Hellman (SXDH) assumption. Unfortunately however, in their ABS scheme, the size of a signature scales with the running time of the signing policy TM used to generate it on the signing attribute string with respect to which it is created. As a result, for ensuring signer privacy, their scheme should impose a universal upper bound on the running times of the signing policy TMs, and should enforce the size of the signatures to scale with that system-wide upper bound. Evidently, such a universal running-time bound in turn induces a bound on the lengths of the allowable signing attribute strings. Moreover, it implies that the signing algorithm should also have running time proportional to that universal time bound, i.e., incurs the worst-case running time in order to generate the signatures. Consequently, it is clear that their scheme actually fails to achieve both the advanced properties which are the sole utility of considering the richer TM model over the circuit model, namely, unbounded-length signing attribute strings and input-specific running time of the signing algorithm. Further, the failure to achieve these rich properties is in fact the result of their approach that involves giving out non-interactive zero-knowledge (NIZK) proofs for each of the evaluation steps of the signing policy TM on the signing attribute string considered in a manner analogous to how an NIZK proof is issued for each gate of the signing policy circuit in [23]. In contrast, our goal in this paper is to devise techniques to accomplish both the rich properties expected from the TM model and thereby truly expand the state of the art in the field of ABS beyond the essential barriers of the circuit model. Additionally, we aim at making the signature size as small as that of an ordinary digital signature scheme, that is, dependent only on the size of the signed message—a feature that has remained elusive despite the tremendous progress in the field of ABS so far.

1.1 Our contribution

In this paper, we present the first ever key-policy ABS scheme supporting signing policies representable as Turing machines (TM) which can handle signing attribute strings of unbounded polynomial length, as well as have arbitrary (polynomial) running time, description size, and space complexity. Thus, our work captures the most general form of signing policies possible. Moreover, in our ABS scheme, generating a signing key corresponding to a signing policy takes time polynomial in the description size of that signing policy, which may be much shorter compared to the worst-case running time of that signing policy. Also, the signature generation time only depends on the time the used signing policy takes to run on the signing attribute string with respect to which the signature is being generated, rather than its worst-case running time. These features were beyond the reach of any other known ABS construction. On a more positive note, for the first time in the literature, the signature size of our ABS scheme only depends on the size of the signed message and is completely independent of the associated signing policy. This is a significant achievement from the point of view of communication efficiency. Further, using the technique of universal TM, our key-policy ABS construction can be readily converted into a signature-policy variant while preserving the same level of expressiveness as the key-policy version. Table presents a comparison of our work and prior works in the area.

Table 1 State of the art in $\textsf{ABS}$

Our ABS construction is shown to possess perfect signer privacy and existential unforgeability against selective attribute adaptive chosen message attacks under well-studied computational assumptions. The construction makes use of indistinguishability obfuscation (IO) for polynomial-size circuits. Other than IO, we make use of standard digital signatures (SIG), injective pseudorandom generators (PRG), and certain additional IO-compatible cryptographic tools, namely, puncturable pseudorandom functions, somewhere statistically binding (SSB) hash functions, positional accumulators, cryptographic iterators, and splittable signatures. Among the cryptographic building blocks used in our ABS construction in addition to IO, iterators and splittable signatures are realizable using IO itself in conjunction with one-way functions, whereas all the others have efficient instantiations based on standard number theoretic assumptions or one-way functions. Very recently, a series of works [2, 9, 12,13,14,15] have finally provided an IO candidate based on the sub-exponential security of three well-studied computational assumptions, namely, learning parity with noise (LPN), existence of boolean pseudorandom generators (PRG) in $\textsf{NC}^0$, and Decisional Linear ($\textsf{DLIN}$).

We note that while the proposed ABS scheme demonstrates asymptotically better performance compared to existing schemes as described above, the concrete computational overhead might not outweigh that of existing schemes at this point primarily due to fact that the current realization of $\textsf{IO}$ is highly inefficient. However, $\textsf{IO}$ research has so far advanced a long way over the last two decade since its inception by Barak et al. [3], and we believe efficient $\textsf{IO}$ candidates would be discovered in the future improving the concrete overhead of the proposed ABS scheme. On the other hand, the existing ABS schemes, especially those supporting comparably expressive signing policies [16, 23,24,25,26] would still continue to suffer from the asymptotic worst-case efficiency bottleneck. Another limitation of the proposed ABS scheme is that it only achieves selective unforgeability as mentioned above. We leave it as an interesting open problem to construct an ABS scheme for the same class of access policies and with the same asymptotic efficiency as ours while achieving adaptive security at the same time.

To achieve our result, we extend the techniques employed by Koppula et al. [17] for designing message-hiding encoding schemes for TMs, or by Deshpande et al. [7] for designing constrained pseudorandom functions (CPRF) for TMs secure in the selective challenge selective constraints model to withstand adaptive signing key queries of the adversary. We give an overview of our techniques in the next section.

2 Preliminaries

For $n\in \mathbb {N}$ and $a,b\in \mathbb {N}\cup \{0\}$ (with $a<b$), we let $[n]=\{1,\ldots ,n\}$ and $[a,b]=\{a,\ldots ,b\}$. For any set S, $\upsilon \xleftarrow {\$} S$ represents the uniform random variable on S. For a randomized algorithm $\mathcal {R}$, we denote by $\psi = \mathcal {R}(\upsilon ;\rho )$ the random variable defined by the output of $\mathcal {R}$ on input $\upsilon$ and randomness $\rho$, while $\psi \xleftarrow {\$} \mathcal {R}(\upsilon )$ has the same meaning with the randomness suppressed. Also, if $\mathcal {R}$ is a deterministic algorithm $\psi =\mathcal {R}(\upsilon )$ denotes the output of $\mathcal {R}$ on input $\upsilon$. We will use the alternative notation $\mathcal {R}(\upsilon )\rightarrow \psi$ as well to represent the output of the algorithm $\mathcal {R}$, whether randomized or deterministic, on input $\upsilon$. For any string $s\in \{0,1\}^*$, |s| represents the length of the string s. For any two strings $s, s'\in \{0,1\}^*$, $s\Vert s'$ represents the concatenation of s and $s'$. A function $\textsf {negl}$ is negligible if for every integer c, there exists an integer k such that for all $\uplambda >k$, $|\textsf {negl}(\uplambda )|<1/{\uplambda ^c}$.

2.1 Turing machines

A Turing machine (TM) M is a 7-tuple $M=\langle Q,\Sigma _{\textsf {\textsc {inp}}},\Sigma _{\textsf {\textsc {tape}}},\delta ,q_0,q_{\textsf {\textsc {ac}}},q_{\textsf {\textsc {rej}}}\rangle$ with the following semantics:

• Q: The finite set of possible states of M.

• $\Sigma _{\textsf {\textsc {inp}}}$: The finite set of input symbols.

• $\Sigma _{\textsf {\textsc {tape}}}$: The finite set of tape symbols such that $\Sigma _{\textsf {\textsc {inp}}}\subset \Sigma _{\textsf {\textsc {tape}}}$ and there exists a special blank symbol ‘$\_$’ $\in \Sigma _{\textsf {\textsc {tape}}}\backslash \Sigma _{\textsf {\textsc {inp}}}$.

• $\delta :Q\times \Sigma _{\textsf {\textsc {tape}}}\rightarrow Q\times \Sigma _{\textsf {\textsc {tape}}}\times \{+1,-1\}$: The transition function of M.

• $q_0\in Q$: The designated start state.

• $q_{\textsf {\textsc {ac}}}\in Q$: The designated accept state.

• $q_{\textsf {\textsc {rej}}}(\ne q_{\textsf {\textsc {ac}}})\in Q$: The distinguished reject state.

For any $t\in [T=2^\uplambda ]$, we define the following variables for M, while running on some input (without the explicit mention of the input in the notations):

• $\textsf {\textsc {pos}}_{M,t}$: An integer which denotes the position of the header of M after the tth step. Initially, $\textsf {\textsc {pos}}_{M,0}=0$.

• $\textsf {\textsc {sym}}_{M,t}\in \Sigma _{\textsf {\textsc {tape}}}$: The symbol stored on the tape at the $\textsf {\textsc {pos}}_{M,t}$th location.

• $\textsf {\textsc {sym}}_{M,t}^{(\textsf {\textsc {write}})}\in \Sigma _{\textsf {\textsc {tape}}}$: The symbol to be written at the $\textsf {\textsc {pos}}_{M,t-1}$th location during the tth step.

• $\textsf {\textsc {st}}_{M,t}\in Q$: The state of M after the tth step. Initially, $\textsf {\textsc {st}}_{M,0}=q_0$.

At each time step, the TM M reads the tape at the header position and based on the current state, computes what needs to be written on the tape at the current header location, the next state, and whether the header must move left or right. More formally, let $(q,\zeta ,\beta \in \{+1,-1\})=\delta (\textsf {\textsc {st}}_{M,t-1},\textsf {\textsc {sym}}_{M,t-1})$. Then, $\textsf {\textsc {st}}_{M,t}=q, \textsf {\textsc {sym}}_{M,t}^{(\textsf {\textsc {write}})}=\zeta$, and $\textsf {\textsc {pos}}_{M,t}=\textsf {\textsc {pos}}_{M,t-1}+\beta$. M accepts at time t if $\textsf {\textsc {st}}_{M,t}=q_{\textsf {\textsc {ac}}}$. In this paper we consider $\Sigma _{\textsf {\textsc {inp}}}=\{0,1\}$ and $\Sigma _{\textsf {\textsc {tape}}}=\{0,1,\_\}$. Given any TM M and string $x\in \{0,1\}^*$, we define $M(x)=1$, if M accepts x within T steps, and 0, otherwise.

2.2 Indistinguishability obfuscation

Definition 2.1

(Indistinguishability obfuscation: IO [3]) An indistinguishability obfuscator (IO) $\mathcal{I}\mathcal{O}$ for a circuit class $\{\mathbb {C}_\uplambda \}_\uplambda$ is a probabilistic polynomial-time (PPT) uniform algorithm satisfying the following conditions:

$\blacktriangleright$:

Correctness: $\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C)$ preserves the functionality of the input circuit C, i.e., for any $C\in \mathbb {C}_\uplambda$, if we compute $C'=\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C)$, then $C'(\upsilon )=C(\upsilon )$ for all inputs $\upsilon$.

$\blacktriangleright$:

Indistinguishability: For any security parameter $\uplambda$ and any two circuits $C_0,C_1\in \mathbb {C}_\uplambda$ with same functionality, the circuits $\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C_0)$ and $\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C_1)$ are computationally indistinguishable. More precisely, for all (not necessarily uniform) PPT adversaries $\mathcal {D}=(\mathcal {D}_1,\mathcal {D}_2)$, there exists a negligible function $\textsf {negl}$ such that, if

$$\begin{aligned}&\textsf {Pr} \big [(C_0,C_1,\xi )\xleftarrow {\$} \mathcal {D}_1(\textsf {1}^\uplambda )~:~\forall \,\upsilon ,C_0(\upsilon )=C_1(\upsilon )\big ]\ge 1-\textsf {negl} (\uplambda ),\\ \text {then}~ \big |&\textsf {Pr} \big [\mathcal {D}_2(\xi ,\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C_0))=1\big ]-\textsf {Pr} \big [\mathcal {D}_2(\xi ,\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C_1))=1\big ]\big |\le \textsf {negl} (\uplambda ). \end{aligned}$$

$\blacktriangleright$:

Efficiency: For any security parameter $\uplambda$ and any circuit $C\in \mathbb {C}_\uplambda$, the size of the obfuscated circuit $\mathcal{I}\mathcal{O}(\textsf {1}^\uplambda ,C)$ is polynomial in $\uplambda$ and the size of C.

We remark that the two distinct algorithms $\mathcal {D}_1$ and $\mathcal {D}_2$, which pass state $\xi$, can be viewed equivalently as a single stateful algorithm $\mathcal {D}$. In this paper we employ the latter approach, although here we present the definition as it appears in [3]. When clear from the context, we will drop $\textsf {1}^\uplambda$ as an input to $\mathcal{I}\mathcal{O}$.

The circuit class we are interested in are polynomial-size circuits, i.e., when $\mathbb {C}_\uplambda$ is the collection of all circuits of size at most $\uplambda$. This circuit class is denoted by P/poly. The first candidate construction of IO for P/poly was presented by Garg et al. [8] in 2013. Their construction uses nonstandard instance dependent assumption on graded multilinear encodings. Since then, there has been a rapid progress towards designing IO from better understood cryptographic tools and complexity assumptions. Very recently, a series of exciting works [1, 2, 9, 12, 13, 15, 18] have finally provided an IO candidate based on the sub-exponential security of four well-studied computational assumptions, namely, learning with errors (LWE), learning parity with noise (LPN), existence of boolean pseudorandom generators (PRG) in $\textsf{NC}^0$, and symmetric external Diffie–Hellman (SXDH).

2.3 IO-compatible cryptographic primitives

In this section, we present the syntax and efficiency considerations of certain IO-friendly cryptographic tools which we use in our ABS construction. The security properties these primitives are described in Online Appendix A.

2.3.1 Puncturable pseudorandom function

Pseudorandom functions (PRF) [10] are a fundamental tool of modern cryptography. A PRF is a deterministic keyed function with the following property: Given a key, the function can be computed in polynomial time at all points of its input domain. But, without the key it is computationally hard to distinguish the PRF output at any arbitrary input from a uniformly random value, even after seeing the PRF evaluations on a polynomial number of inputs. A puncturable pseudorandom function (PPRF), first introduced by Sahai and Waters [22], is an augmentation of a PRF with an additional puncturing algorithm which enables a party holding a PRF key to derive punctured keys that allow the evaluation of the PRF over all points of the input domain except one. However, given a punctured key, the PRF evaluation still remains indistinguishable from random on the input at which the key is punctured.

Puncturable pseudorandom function PPRF [22]: A puncturable pseudorandom function (PPRF) $\mathcal {F}:\mathcal {K}_{\textsf {\textsc {pprf}}}\times \mathcal {X}_{\textsf {\textsc {pprf}}}\rightarrow \mathcal {Y}_{\textsf {\textsc {pprf}}}$ consists of an additional punctured key space $\mathcal {K}_{\textsf {\textsc {pprf-punc}}}$ other than the usual key space $\mathcal {K}_{\textsf {\textsc {pprf}}}$ and PPT algorithms $(\mathcal {F}.\textsf {Setup} ,\mathcal {F}.\textsf {Eval} , \mathcal {F}.\textsf {Puncture} , \mathcal {F}.\textsf {Eval-Punctured} )$ described below. Here, $\mathcal {X}_{\textsf {\textsc {pprf}}}=\{0,1\}^{\ell _{\textsf {\textsc {pprf-inp}}}}$ and $\mathcal {Y}_{\textsf {\textsc {pprf}}}=\{0,1\}^{\ell _{\textsf {\textsc {pprf-out}}}}$, where $\ell _{\textsf {\textsc {pprf-inp}}}$ and $\ell _{\textsf {\textsc {pprf-out}}}$ are polynomials in the security parameter $\uplambda$,

• $\mathcal {F}.\textsf {Setup} (\textsf {1}^\uplambda )\rightarrow K:$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$ and uniformly samples a PPRF key $K\in \mathcal {K}_{\textsf {\textsc {pprf}}}$.

• $\mathcal {F}.\textsf {Eval} (K,x)\rightarrow r:$ The setup authority takes as input a PPRF key $K\in \mathcal {K}_{\textsf {\textsc {pprf}}}$ along with an input $x\in \mathcal {X}_{\textsf {\textsc {pprf}}}$. It outputs the PPRF value $r\in \mathcal {Y}_{\textsf {\textsc {pprf}}}$ on x. For simplicity, we will represent by $\mathcal {F}(K,x)$ the output of this algorithm.

• $\mathcal {F}.\textsf {Puncture} (K,x)\rightarrow K\{x\}:$ Taking as input a PPRF key $K\in \mathcal {K}_{\textsf {\textsc {pprf}}}$ along with an element $x\in \mathcal {X}_{\textsf {\textsc {pprf}}}$, the setup authority outputs a punctured key $K\{x\}\in \mathcal {K}_{\textsf {\textsc {pprf-punc}}}$.

• $\mathcal {F}.\textsf {Eval-Puncured} (K\{x\},x')\rightarrow r~\text {or}~\bot :$ An evaluator takes as input a punctured key $K\{x\}\in \mathcal {K}_{\textsf {\textsc {pprf-punc}}}$ along with an input $x'\in \mathcal {X}_{\textsf {\textsc {pprf}}}$. It outputs either a value $r\in \mathcal {Y}_{\textsf {\textsc {pprf}}}$ or a distinguished symbol $\bot$ indicating failure. For simplicity, we will represent by $\mathcal {F}(K\{x\},x')$ the output of this algorithm.

The algorithms $\mathcal {F}.\textsf {Setup}$ and $\mathcal {F}.\textsf {Puncture}$ are randomized, whereas, the algorithms $\mathcal {F}.\textsf {Eval}$ and $\mathcal {F}.\textsf {Eval-Punctured}$ are deterministic.

$\blacktriangleright$ Correctness under puncturing: Consider any security parameter $\uplambda$, $K\in \mathcal {K}_{\textsf {\textsc {pprf}}}$, $x\in \mathcal {X}_{\textsf {\textsc {pprf}}}$, and $K\{x\}\xleftarrow {\$}\mathcal {F}.\textsf {Puncture} (K,x)$. Then it must hold that

$$\begin{aligned} \mathcal {F}(K\{x\},x')=\left\{ \begin{array}{l l} \mathcal {F}(K,x'), &{}\hbox {if }x'\ne x\\ \bot , &{}\hbox {otherwise} \end{array}. \right. \end{aligned}$$

$\blacktriangleright$ Efficiency: The $\mathcal {F}.\textsf {Setup}$ algorithm runs in time polynomial in the security parameter $\uplambda$, while the algorithms $\mathcal {F}.\textsf {Eval}$ and $\mathcal {F}.\textsf {Punctured}$ run in time polynomial in $\uplambda$ and the input size $\ell _{\textsf {\textsc {pprf-inp}}}$. Moreover, the size of the full PPRF keys is polynomial in $\uplambda$, whereas that of the punctured keys is polynomial in $\uplambda$ and $\ell _{\textsf {\textsc {pprf-inp}}}$. Hence, the algorithm $\mathcal {F}.\textsf {Eval-Punctured}$ also runs in time polynomial in $\uplambda$ and $\ell _{\textsf {\textsc {pprf-inp}}}$. Boneh and Waters [5], have shown that the tree-based PRF constructed by Goldreich et al. [10] can be readily modified to build a PPRF from one-way functions.

2.3.2 Somewhere statistically binding hash function

We provide the definition of somewhere statistically binding hash function as defined by Hubacek et al. [11]. A somewhere statistically binding hash can be used to create a short digest of some long string. A hashing key is created by specifying a special binding index and the generated hashing key gets the property that the hash value of some string created with the hashing key is statistically binding for the specified index, meaning that the hash value completely determines the symbol of the hashed input at that index. In other words, even if some hash value has several pre-images, all of those pre-images agree in the symbol at the specified index. The index on which the hash is statistically binding should remain computationally hidden given the hashing key. Moreover, it is possible to prove that the input string underlying a given hash value contains a specific symbol at a particular index, by providing a short opening value.

Somewhere statistically binding hash function SSB Hash [11]: A somewhere statistically binding (SSB) hash consists of PPT algorithms $(\textsf {SSB.Gen} ,$ $\mathcal {H}, \textsf {SSB.Open},\textsf {SSB.Verify} )$ along with a block alphabet $\Sigma _{\textsf {\textsc {ssb-blk}}}$ $=\{0,1\}^{\ell _{\textsf {\textsc {ssb-blk}}}}$, output size $\ell _{\textsf {\textsc {ssb-hash}}}$, and opening space $\Pi _{\textsf {\textsc {ssb}}}=\{0,1\}^{\ell _{\textsf {\textsc {ssb-open}}}}$, where $\ell _{\textsf {\textsc {ssb-blk}}},$ $\ell _{\textsf {\textsc {ssb-hash}}},\ell _{\textsf {\textsc {ssb-open}}}$ are some polynomials in the security parameter $\uplambda$. The algorithms have the following syntax:

• $\textsf {SSB.Gen} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {ssb-blk}}},i^*)\rightarrow \textsf {\textsc {hk}}:$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$, an integer $n_{\textsf {\textsc {ssb-blk}}}\le 2^\uplambda$ representing the maximum number of blocks that can be hashed, and an index $i^*\in [0,n_{\textsf {\textsc {ssb-blk}}}-1]$ and publishes a public hashing key $\textsf {\textsc {hk}}$.

• $\mathcal {H}_{\textsf {\textsc {hk}}}:x\in \Sigma _{\textsf {\textsc {ssb-blk}}}^{n_{\textsf {\textsc {ssb-blk}}}}\rightarrow h\in \{0,1\}^{\ell _{\textsf {\textsc {ssb-hash}}}}:$ This is a deterministic function that has the hash key $\textsf {\textsc {hk}}$ hardwired. A user runs this function on input $x=x_0\Vert \ldots \Vert x_{n_{\textsf {\textsc {ssb-blk}}}-1}\in \Sigma _{\textsf {\textsc {ssb-blk}}}^{n_{\textsf {\textsc {ssb-blk}}}}$ to obtain as output $h=\mathcal {H}_{\textsf {\textsc {hk}}}(x)\in \{0,1\}^{\ell _{\textsf {\textsc {ssb-hash}}}}$.

• $\textsf {SSB.Open} (\textsf {\textsc {hk}},x,i)\rightarrow \pi _{\textsf {\textsc {ssb}}}:$ Taking as input the hash key $\textsf {\textsc {hk}}$, input $x\in \Sigma _{\textsf {\textsc {ssb-blk}}}^{n_{\textsf {\textsc {ssb-blk}}}}$, and an index $i\in [0,n_{\textsf {\textsc {ssb-blk}}}-1]$, a user creates an opening $\pi _{\textsf {\textsc {ssb}}}\in \Pi _{\textsf {\textsc {ssb}}}$.

• $\textsf {SSB.Verify} (\textsf {\textsc {hk}},h,i,u,\pi _{\textsf {\textsc {ssb}}})\rightarrow \hat{\beta }\in \{0,1\}:$ On input a hash key $\textsf {\textsc {hk}}$, a hash value $h\in \{0,1\}^{\ell _{\textsf {\textsc {ssb-hash}}}}$, an index $i\in [0,n_{\textsf {\textsc {ssb-blk}}}-1]$, a value $u\in \Sigma _{\textsf {\textsc {ssb-blk}}}$, and an opening $\pi _{\textsf {\textsc {ssb}}}\in \Pi _{\textsf {\textsc {ssb}}}$, a verifier outputs a bit $\hat{\beta }\in \{0,1\}$.

The algorithms $\textsf {SSB.Gen}$ and $\textsf {SSB.Open}$ are randomized, while the algorithm $\textsf {SSB.Verify}$ is deterministic.

$\blacktriangleright$:

Correctness: For any security parameter $\uplambda$, integer $n_{\textsf {\textsc {ssb-blk}}}\le 2^\uplambda$, $i,i^*\in [0,n_{\textsf {\textsc {ssb-blk}}}$ $-1]$, $\textsf {\textsc {hk}}\xleftarrow {\$}\textsf {SSB.Gen} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {ssb-blk}}},i^*)$, $x\in \Sigma _{\textsf {\textsc {ssb-blk}}}^{n_{\textsf {\textsc {ssb-blk}}}}$, and  $\pi _{\textsf {\textsc {ssb}}}\xleftarrow {\$}\textsf {SSB.Open} (\textsf {\textsc {hk}},x,i)$, we have $\textsf {SSB.Verify} (\textsf {\textsc {hk}}, \mathcal {H}_{\textsf {\textsc {hk}}}(x),i,x_i,\pi _{\textsf {\textsc {ssb}}})=1$.

$\blacktriangleright$:

Efficiency: The SSB.Gen algorithm runs in time polynomial in the security parameter $\uplambda$ and $\log n_{\textsf {\textsc {ssb-blk}}}$. Moreover, the hash and opening values have size polynomial in $\uplambda$ and $\log n_{\textsf {\textsc {ssb-blk}}}$. Hence, the SSB.Verify algorithm also runs in time polynomial in $\uplambda$ and $\log n_{\textsf {\textsc {ssb-blk}}}$. On the other hand, the algorithms $\mathcal {H}_{\textsf {\textsc {hk}}}$ and SSB.Open run in time polynomial in $\uplambda$ and $n_{\textsf {\textsc {ssb-blk}}}$ in the worst case. The first construction of an SSB hash is presented by Hubacek et al. [11]. Their construction is based on fully homomorphic encryption (FHE). Recently, Okamoto et al.[21] provides alternative constructions of SSB hash based on various standard number theoretic assumptions such as the Decisional Diffie-Hellman assumption. In this paper, we consider $\ell _{\textsf {\textsc {ssb-blk}}}=1$ and $n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda$.

2.3.3 Positional accumulator

We will now present the notion of a positional accumulator as defined by Koppula et al. [17]. Intuitively, a positional accumulator is a cryptographic data structure that maintains two values, namely, a storage value and an accumulator value. The storage value is allowed to grow comparatively large, while the accumulator value is constrained to be short. Message symbols can be written to various positions in the underlying storage, and new accumulated values can be computed as a string, knowing only the previous accumulator value and the newly written symbol together with its position in the data structure. Since the accumulator values are small, one cannot hope to recover everything written in the storage from the accumulator value alone. However, there are additional helper algorithms which essentially allow a party who is maintaining the full storage to help a more restricted party maintaining only the accumulator value recover the data currently written at an arbitrary location. The helper is not necessarily trusted, so the party maintaining the accumulator value performs a verification procedure in order to be convinced that it is indeed reading the correct symbols.

Positional accumulator [17]: A positional accumulator consists of PPT algorithms $(\textsf {ACC.Setup}, \textsf {ACC.Setup-Enforce-}\textsf {Read}, \textsf {ACC.Setup-Enforce-Write}, \textsf {ACC.Prep-Read}, \textsf {ACC.} \textsf {Prep-Write}, \textsf {ACC.Verify-Read}, \textsf {ACC.Write-Store}, \textsf {ACC.Update})$ along with a block alphabet $\Sigma _{\textsf {\textsc {acc-blk}}}=\{0,1\}^{\ell _{\textsf {\textsc {acc-blk}}}}$, accumulator size $\ell _{\textsf {\textsc {acc-accumulate}}}$, proof space $\Pi _{\textsf {\textsc {acc}}}=\{0,1\}^{\ell _{\textsf {\textsc {acc-proof}}}}$ where $\ell _{\textsf {\textsc {acc-blk}}},$ $\ell _{\textsf {\textsc {acc-accumulate}}}, \ell _{\textsf {\textsc {acc-proof}}}$ are some polynomials in the security parameter $\uplambda$. The algorithms have the following syntax:

• $\textsf {ACC.Setup} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {acc-blk}}})\rightarrow (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0,\textsf {\textsc {store}}_0):$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$ and an integer $n_{\textsf {\textsc {acc-blk}}}\le 2^\uplambda$ representing the maximum number of blocks that can be accumulated. It outputs the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, an initial accumulator value $w_0$, and an initial storage value $\textsf {\textsc {store}}_0$.

• $\textsf {ACC.Setup-Enforce-Read} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {acc-blk}}},((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa )),i^*)~\rightarrow ~(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0, \textsf {\textsc {store}}_0):$ Taking as input the security parameter $\textsf {1}^\uplambda$, an integer $n_{\textsf {\textsc {acc-blk}}}\le 2^\uplambda$ representing the maximum number of blocks that can be accumulated, a sequence of symbol-index pairs $((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa )) \in (\Sigma _{\textsf {\textsc {acc-blk}}}\times [0,n_{\textsf {\textsc {acc-blk}}}-1])^\kappa$, and an additional index $i^*\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, the setup authority publishes the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, an initial accumulator value $w_0$, together with an initial storage value $\textsf {\textsc {store}}_0$.

• $\textsf {ACC.Setup-Enforce-Write} (\textsf {1}^\uplambda ,~n_{\textsf {\textsc {acc-blk}}},~((x_1,i_1),\ldots ,x_\kappa ,i_\kappa )))~\rightarrow ~(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},~w_0, \textsf {\textsc {store}}_0):$ On input the security parameter $\textsf {1}^\uplambda$, an integer $n_{\textsf {\textsc {acc-blk}}}\le 2^\uplambda$ denoting the maximum number of blocks that can be accumulated, and a sequence of symbol-index pairs $((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa ))\in (\Sigma _{\textsf {\textsc {acc-blk}}}\times [0,n_{\textsf {\textsc {acc-blk}}}-1])^\kappa$, the setup authority publishes the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, an initial accumulator value $w_0$, as well as, an initial storage value $\textsf {\textsc {store}}_0$.

• $\textsf {ACC.Prep-Read} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},\textsf {\textsc {store}}_{\textsf {\textsc {in}}}, i_{\textsf {\textsc {in}}})\rightarrow (x_{\textsf {\textsc {out}}},\pi _{\textsf {\textsc {acc}}}):$ A storage-maintaining party takes as input the public parameter $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, a storage value $\textsf {\textsc {store}}_{\textsf {\textsc {in}}}$, and an index $i_{\textsf {\textsc {in}}}\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$. It outputs a symbol $x_{\textsf {\textsc {out}}}\in \Sigma _{\textsf {\textsc {acc-blk}}}\cup \{\epsilon \}$ ($\epsilon$ being the empty string) and a proof $\pi _{\textsf {\textsc {acc}}}\in \Pi _{\textsf {\textsc {acc}}}$.

• $\textsf {ACC.Prep-Write} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{\textsf {\textsc {in}}}, i_{\textsf {\textsc {in}}})\rightarrow \textsf {\textsc {aux}}:$ Taking as input the public parameter $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, a storage value $\textsf {\textsc {store}}_{\textsf {\textsc {in}}}$, together with an index $i_{\textsf {\textsc {in}}}\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, a storage-maintaining party outputs an auxiliary value $\textsf {\textsc {aux}}$.

• $\textsf {ACC.Verify-Read} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, w_{\textsf {\textsc {in}}},x_{\textsf {\textsc {in}}}, i_{\textsf {\textsc {in}}}, \pi _{\textsf {\textsc {acc}}})\rightarrow \hat{\beta }\in \{0,1\}:$ A verifier takes as input the public parameter $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, an accumulator value $w_{\textsf {\textsc {in}}}\in \{0,1\}^{\ell _{\textsf {\textsc {acc-accumulate}}}}$, a symbol $x_{\textsf {\textsc {in}}}\in \Sigma _{\textsf {\textsc {acc-blk}}}\cup \{\epsilon \}$, an index $i_{\textsf {\textsc {in}}}\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, and a proof $\pi _{\textsf {\textsc {acc}}}\in \Pi _{\textsf {\textsc {acc}}}$. It outputs a bit $\hat{\beta }\in \{0,1\}$.

• $\textsf {ACC.Write-Store} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},\textsf {\textsc {store}}_{\textsf {\textsc {in}}}, i_{\textsf {\textsc {in}}},x_{\textsf {\textsc {in}}})\rightarrow \textsf {\textsc {store}}_{\textsf {\textsc {out}}}:$ On input the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, a storage value $\textsf {\textsc {store}}_{\textsf {\textsc {in}}}$, an index $i_{\textsf {\textsc {in}}}\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, and a symbol $x_{\textsf {\textsc {in}}}\in \Sigma _{\textsf {\textsc {acc-blk}}}$, a storage-maintaining party computes a new storage value $\textsf {\textsc {store}}_{\textsf {\textsc {out}}}$.

• $\textsf {ACC.Update} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_{\textsf {\textsc {in}}},x_{\textsf {\textsc {in}}}, i_{\textsf {\textsc {in}}},\textsf {\textsc {aux}})\rightarrow w_{\textsf {\textsc {out}}}~\text {or}~\bot :$ An accumulator-updating party takes as input the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$, an accumulator value $w_{\textsf {\textsc {in}}}\in \{0,1\}^{\ell _{\textsf {\textsc {acc-accumulate}}}}$, a symbol $x_{\textsf {\textsc {in}}}\in \Sigma _{\textsf {\textsc {acc-blk}}}$, an index $i_{\textsf {\textsc {in}}}\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, and an auxiliary value $\textsf {\textsc {aux}}$. It outputs the updated accumulator value $w_{\textsf {\textsc {out}}}\in \{0,1\}^{\ell _{\textsf {\textsc {acc-accumulate}}}}$ or the designated reject string $\bot$.

Following  [7, 17],  in  this  paper  we  will  consider  the  algorithms  $\textsf {ACC.Setup} ,$

$\textsf {ACC.Setup-Enforce-Read}$, and $\textsf {ACC.Setup-Enforce-Write}$ as randomized while all other algorithms as deterministic.

$\blacktriangleright$ Correctness: Consider any symbol-index pair sequence $((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa ))$

$\in (\Sigma _{\textsf {\textsc {acc-blk}}}\times [0,n_{\textsf {\textsc {acc-blk}}}-1])^\kappa$. Fix any $(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0, \textsf {\textsc {store}}_0)~\xleftarrow {\$}~\textsf {ACC.Setup} (\textsf {1}^\uplambda ,$

$n_{\textsf {\textsc {acc-blk}}})$. For $j=1,\ldots ,\kappa$, iteratively define the following:

• $\textsf {\textsc {store}}_j=\textsf {ACC.Write-Store} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{j-1},i_j,x_j)$.

• $\textsf {\textsc {aux}}_j=\textsf {ACC.Prep-Write} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{j-1},i_j)$.

• $w_j=\textsf {ACC.Update} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_{j-1},x_j,i_j,\textsf {\textsc {aux}}_j)$.

The following correctness properties are required to be satisfied:

• (i) For any security parameter $\uplambda$, $n_{\textsf {\textsc {acc-blk}}}\le 2^\uplambda$, index $i^*\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, sequence of symbol-index pairs $((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa ))\in (\Sigma _{\textsf {\textsc {acc-blk}}}\times [0,n_{\textsf {\textsc {acc-blk}}}-1])^\kappa$, and $(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0, \textsf {\textsc {store}}_0)~\xleftarrow {\$}~\textsf {ACC.Setup} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {acc-blk}}})$, if $\textsf {\textsc {store}}_\kappa$ is computed as above, then $\textsf {ACC.Prep-Read} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},\textsf {\textsc {store}}_\kappa ,i^*)$ returns $(x_j,\pi _{\textsf {\textsc {acc}}})$ where j is the largest value in $[\kappa ]$ such that $i_j=i^*$.

• (ii) For any security parameter $\uplambda$, $n_{\textsf {\textsc {acc-blk}}}\le 2^\uplambda$, sequence of symbol-index pairs $((x_1,i_1),\ldots ,(x_\kappa ,i_\kappa ))\in (\Sigma _{\textsf {\textsc {acc-blk}}}\times [0,n_{\textsf {\textsc {acc-blk}}}-1])^\kappa$, $i^*\in [0,n_{\textsf {\textsc {acc-blk}}}-1]$, and $(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0, \textsf {\textsc {store}}_0)\xleftarrow {\$}\textsf {ACC.Setup} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {acc-blk}}})$, if $\textsf {\textsc {store}}_\kappa$ and $w_\kappa$ are computed as above and $(x_{\textsf {\textsc {out}}},\pi _{\textsf {\textsc {acc}}})= \textsf {ACC.Prep-Read} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_\kappa ,i^*)$, then $\textsf {ACC.Verify-} \textsf {Read} (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_\kappa ,x_{\textsf {\textsc {out}}},i^*,\pi _{\textsf {\textsc {acc}}})=1$

$\blacktriangleright$ Efficiency: The ACC.Setup algorithm runs in time polynomial in the security parameter $\uplambda$ and $\log n_{\textsf {\textsc {acc-blk}}}$. Moreover, the accumulator values and proofs have size polynomial in $\uplambda$ and $\log n_{\textsf {\textsc {acc-blk}}}$. Thus, the algorithms ACC.Verify-Read and ACC.Update also run in time polynomial in $\uplambda$ and $\log n_{\textsf {\textsc {acc-blk}}}$. The storage has size polynomial in the number of values stored so far. Hence, the algorithms ACC.Write-Store, ACC.Prep-Read, and ACC.Prep-Write run in time polynomial in $\uplambda$ and $n_{\textsf {\textsc {acc-blk}}}$ in the worst case. The first construction of a positional accumulator is presented by Koppula et al. [17] based on IO and one-way function. Recently, Okamoto et al. [21] provided an alternative construction of positional accumulator from standard number theoretic assumptions. Such as the Decisional Diffie–Hellman assumption.

2.3.4 Iterator

Here, we define cryptographic iterators again following [17]. Informally speaking, a cryptographic iterator consists of a small state that is updated in an iterative fashion as messages are received. An update to incorporate a new message given the current state is performed with the help of some public parameters. Since, states are relatively small regardless of the number of messages that have been iteratively incorporated, there is in general many sequences of messages that lead to the same state. However, the security property requires that the normal public parameters should be computationally indistinguishable from specially constructed enforcing parameters which ensure that a particular state can only be obtained as the outcome of an update to precisely one other state-message pair. Note that this enforcement is a very localized property to a specific state and hence can be achieved information-theoretically when it is fixed ahead of time where exactly this enforcement is desired.

Iterator [17]: A cryptographic iterator consists of PPT algorithms $(\textsf {ITR.Setup},$ $\textsf {ITR.Setup-Enforce},$ $\textsf {ITR.Iterate} )$ along with a message space $\mathcal {M}_{\textsf {\textsc {itr}}}$ $=\{0,1\}^{\ell _{\textsf {\textsc {itr-msg}}}}$ and iterator state size $\ell _{\textsf {\textsc {itr-st}}}$, where $\ell _{\textsf {\textsc {itr-msg}}},\ell _{\textsf {\textsc {itr-st}}}$ are some polynomials in the security parameter $\uplambda$. Algorithms have the following syntax:

• $\textsf {ITR.Setup} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {itr}}})\rightarrow (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_0):$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$ along with an integer bound $n_{\textsf {\textsc {itr}}}\le 2^\uplambda$ on the number of iterations. It outputs the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}$ and an initial state $v_0\in \{0,1\}^{\ell _{\textsf {\textsc {itr-st}}}}$.

• $\textsf {ITR.Setup-Enforce} (\textsf {1}^\uplambda ,n_{\textsf {\textsc {itr}}},(\mu _1,\ldots ,\mu _\kappa ))\rightarrow (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_0):$ Taking as input the security parameter $\textsf {1}^\uplambda$, an integer bound $n_{\textsf {\textsc {itr}}}\le 2^\uplambda$, together with a sequence of $\kappa$ messages $(\mu _1,\ldots ,\mu _\kappa )\in \mathcal {M}_{\textsf {\textsc {itr}}}^\kappa$, where $\kappa \le n_{\textsf {\textsc {itr}}}$, the setup authority publishes the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}$ and an initial state $v_0\in \{0,1\}^{\ell _{\textsf {\textsc {itr-st}}}}$.

• $\textsf {ITR.Iterate} (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}, v_{\textsf {\textsc {in}}}\in \{0,1\}^{\ell _{\textsf {\textsc {itr-st}}}},\mu )\rightarrow v_{\textsf {\textsc {out}}}:$ On input the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}$, a state $v_{\textsf {\textsc {in}}}$, and a message $\mu \in \mathcal {M}_{\textsf {\textsc {itr}}}$, an iterator outputs an updated state $v_{\textsf {\textsc {out}}}\in \{0,1\}^{\ell _{\textsf {\textsc {itr-st}}}}$. For any integer $\kappa \le n_{\textsf {\textsc {itr}}}$, we will write $\textsf {ITR.Iterate} ^\kappa (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},$ $v_0,(\mu _1,\ldots ,\mu _\kappa ))$  to  denote  $\textsf {ITR.Iterate} (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_{\kappa -1},\mu _\kappa )$, where $v_j$ is defined iteratively as $v_j=\textsf {ITR.Iterate} (\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_{j-1},\mu _j)$ for all $j=1,\ldots ,\kappa -1$.

The algorithm $\textsf {ITR.Iterate}$ is deterministic, while the other two are randomized.

$\blacktriangleright$ Efficiency: The algorithms ITR.Setup and ITR.Iterate run in time polynomial in the security parameter $\uplambda$ and $\log n_{\textsf {\textsc {itr}}}$. Also, the state has size polynomial in $\uplambda$ and $\log n_{\textsf {\textsc {itr}}}$. Koppula et al. [17] have presented a construction of cryptographic iterators from IO and one-way function.

2.3.5 Splittable signature

The following background on splittable signatures is taken verbatim from Koppula et al. [17] as well. A splittable signature scheme is essentially a normal signature scheme augmented by some additional algorithms that produce alternative signing and verification keys with different capabilities. More precisely, there are “all-but-one” signing and verification keys which work correctly for all messages except for a specific one, as well as there are “one” signing and verification keys which work only for a particular message. Additionally, there are “reject” verification keys which always reject signatures.

Splittable signature SPS [17]: A splittable signature scheme (SPS) for message space $\mathcal {M}_{\textsf {\textsc {sps}}}=\{0,1\}^{\ell _{\textsf {\textsc {sps-msg}}}}$ and signature space $\mathcal {S}_{\textsf {\textsc {sps}}}=\{0,1\}^{\ell _{\textsf {\textsc {sps-sig}}}}$, where $\ell _{\textsf {\textsc {sps-msg}}},\ell _{\textsf {\textsc {sps-sig}}}$ are some polynomials in the security parameter $\uplambda$, consists of PPT algorithms $(\textsf {SPS.Setup}, \textsf {SPS.Sign}, \textsf {SPS.Verify},$ $\textsf {SPS.Split}, \textsf {SPS.Sign-ABO} )$ which are described below:

• $\textsf {SPS.Setup} (\textsf {1}^\uplambda )\rightarrow (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}}, \textsf {\textsc {vk}}_{\textsf {\textsc {sps-rej}}}):$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$ and generates a signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}}$, a verification key $\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}}$, together with a reject verification key $\textsf {\textsc {vk}}_{\textsf {\textsc {sps-rej}}}$.

• $\textsf {SPS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m)\rightarrow \sigma _{\textsf {\textsc {sps}}}:$ A signer given a signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}}$ along with a message $m\in \mathcal {M}_{\textsf {\textsc {sps}}}$, produces a signature $\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}$.

• $\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}},m,\sigma _{\textsf {\textsc {sps}}})\rightarrow \hat{\beta }\in \{0,1\}:$ A verifier takes as input a verification key $\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}}$, a message $m\in \mathcal {M}_{\textsf {\textsc {sps}}}$, and a signature $\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}$. It outputs a bit $\hat{\beta }\in \{0,1\}$.

• $\textsf {SPS.Split} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m^*)\rightarrow (\sigma _{\textsf {\textsc {sps-one}},m^*},\textsf {\textsc {vk}}_{\textsf {\textsc {sps-one}}}, \textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sps-abo}}}):$ On input a signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}}$ along with a message $m^*\in \mathcal {M}_{\textsf {\textsc {sps}}}$, the setup authority generates a signature $\sigma _{\textsf {\textsc {sps-one}},m^*}=\textsf {SPS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m^*)$, a one-message verification key $\textsf {\textsc {vk}}_{\textsf {\textsc {sps-one}}}$, and all-but-one signing-verification key pair $(\textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sps-abo}}})$.

• $\textsf {SPS.Sign-ABO} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}},m)\rightarrow \sigma _{\textsf {\textsc {sps}}}~\text {or}~\bot :$ An all-but-one signer given an all-but-one signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}}$ and a message $m\in \mathcal {M}_{\textsf {\textsc {sps}}}$, outputs a signature $\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}$ or a distinguished string $\bot$ to indicate failure. For simplicity of notation, we will often use $\textsf {SPS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}},m)$ to represent the output of this algorithm.

We note that among the algorithms described above, $\textsf {SPS.Setup}$ and $\textsf {SPS.Split}$ are randomized while all the others are deterministic.

$\blacktriangleright$ Correctness: For any security parameter $\uplambda$, message $m^*\in \mathcal {M}_{\textsf {\textsc {sps}}}$, $(\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}},$ $\textsf {\textsc {vk}}_{\textsf {\textsc {sps-rej}}})\xleftarrow {\$} \textsf {SPS.Setup} (\textsf {1}^\uplambda )$, and $(\sigma _{\textsf {\textsc {sps-one}},m^*}, ~ \textsf {\textsc {vk}}_{\textsf {\textsc {sps-one}}}, ~ \textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}}, ~ \textsf {\textsc {vk}}_{\textsf {\textsc {sps-abo}}})\xleftarrow {\$} \textsf {SPS.Split} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m^*)$ the following correctness conditions hold:

• (i) $\forall \, m\in \mathcal {M}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}},m, \textsf {SPS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m))=1$.

• (ii) $\forall \, m\ne m^*\in \mathcal {M}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps}}},m)= \textsf {SPS.Sign-ABO} (\textsf {\textsc {sk}}_{\textsf {\textsc {sps-abo}}},m)$.

• (iii) $\forall \,\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps-one}}},m^*,\sigma _{\textsf {\textsc {sps}}})=\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}},m^*,\sigma _{\textsf {\textsc {sps}}})$.

• (iv) $\forall \, m\ne m^*\in \mathcal {M}_{\textsf {\textsc {sps}}},~\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}},$ $~~~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps-abo}}},m, \sigma _{\textsf {\textsc {sps}}})=\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps}}},m, \sigma _{\textsf {\textsc {sps}}})$.

• (v) $\forall \, m\ne m^*\in \mathcal {M}_{\textsf {\textsc {sps}}},~\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps-one}}},m,\sigma _{\textsf {\textsc {sps}}})=0$.

• (vi) $\forall \, \sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps-abo}}}, m^*,\sigma _{\textsf {\textsc {sps}}})=0$.

• (vii) $\forall \, m\in \mathcal {M}_{\textsf {\textsc {sps}}},~\sigma _{\textsf {\textsc {sps}}}\in \mathcal {S}_{\textsf {\textsc {sps}}}, ~\textsf {SPS.Verify} (\textsf {\textsc {vk}}_{\textsf {\textsc {sps-rej}}},m,\sigma _{\textsf {\textsc {sps}}})=0$.

$\blacktriangleright$ Efficiency: The algorithms SPS.Setup, SPS.Sign, and SPS.Verify run in time polynomial in the security parameter $\uplambda$ and the supported message length $\ell _{\textsf {\textsc {sps-msg}}}$. Koppula et al. [17] have constructed a splittable signature scheme using IO and one-way function.

3 Our attribute-based signature for TMs

3.1 Notion of attribute-based signatures for TMs

First, we will formally define the notion of an attribute-based signature scheme where signing policies are associated with TMs. This definition is similar to that defined in [23, 25] for circuits.

Definition 3.1

(Attribute-based signature for turing machines: ABS) Let $\mathbb {M}_\uplambda$ be a class of TMs, the members of which have (worst-case) running time bounded by $T=2^\uplambda$. An attribute-based signature (ABS) scheme for signing policies associated with the TMs in $\mathbb {M}_\uplambda$ comprises of an attribute universe $\mathcal {U}_{\textsf {\textsc {abs}}}\subset \{0,1\}^*$, a message space $\mathcal {M}_{\textsf {\textsc {abs}}}=\{0,1\}^{\ell _{\textsf {\textsc {abs-msg}}}}$, a signature space $\mathcal {S}_{\textsf {\textsc {abs}}}=\{0,1\}^{\ell _{\textsf {\textsc {abs-sig}}}}$, where $\ell _{\textsf {\textsc {abs-msg}}}, \ell _{\textsf {\textsc {abs-sig}}}$ are some polynomials in the security parameter $\uplambda$, and PPT algorithms $(\textsf {ABS.Setup}, \textsf {ABS.KeyGen}, \textsf {ABS.Sign}, \textsf {ABS.Verify} )$ described below:

• $\textsf {ABS.Setup} (\textsf {1}^\uplambda )\rightarrow (\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}):$ The setup authority takes as input the security parameter $\textsf {1}^\uplambda$. It publishes the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$ while generates a master secret key $\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}$ for itself.

• $\textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M)\rightarrow \textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M):$ Taking as input the master secret key $\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}$ and a signing policy TM $M\in \mathbb {M}_\uplambda$ of a signer, the setup authority provides the corresponding signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)$ to the legitimate signer.

• $\textsf {ABS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M),x,\textsf {msg} )\rightarrow \sigma _{\textsf {\textsc {abs}}}~\text {or}~\bot :$ On input the signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)$ corresponding to the legitimate signing policy TM $M\in \mathbb {M}_\uplambda$, a signing attribute string $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$, and a message $\textsf {msg} \in \mathcal {M}_{\textsf {\textsc {abs}}}$, a signer outputs either a signature $\sigma _{\textsf {\textsc {abs}}}\in \mathcal {S}_{\textsf {\textsc {abs}}}$ or $\bot$ indicating failure.

• $\textsf {ABS.Verify} (\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},x,\textsf {msg} , \sigma _{\textsf {\textsc {abs}}})\rightarrow \hat{\beta }\in \{0,1\}:$ A verifier takes as input the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$, a signing attribute string $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$, a message $\textsf {msg} \in \mathcal {M}_{\textsf {\textsc {abs}}}$, and a purported signature $\sigma _{\textsf {\textsc {abs}}}\in \mathcal {S}_{\textsf {\textsc {abs}}}$. It outputs a bit $\hat{\beta }\in \{0,1\}$.

We note that all the algorithms described above except $\textsf {ABS.Verify}$ are randomized. The algorithms satisfy the following properties:

• $\blacktriangleright$ Correctness: For any security parameter $\uplambda$, $(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}})\xleftarrow {\$} \textsf {ABS.Setup} (\textsf {1}^\uplambda )$, $M\in \mathbb {M}_\uplambda$, $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)\xleftarrow {\$} \textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M)$, $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$, and $\textsf {msg} \in \mathcal {M}_{\textsf {\textsc {abs}}}$, if $M(x)=1$, then $\textsf {ABS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M),x,\textsf {msg})$ outputs $\sigma _{\textsf {\textsc {abs}}}\in \mathcal {S}_{\textsf {\textsc {abs}}}$ such that $\textsf {ABS.Verify} (\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},x,\textsf {msg} , \sigma _{\textsf {\textsc {abs}}})=1$.

• $\blacktriangleright$ Signer privacy: An ABS scheme is said to provide signer privacy if for any security parameter $\uplambda$, message $\textsf {msg} \in \mathcal {M}_{\textsf {\textsc {abs}}}$, $(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}})\xleftarrow {\$} \textsf {ABS.Setup} (\textsf {1}^\uplambda )$, signing policies $M,M'\in \mathbb {M}_\uplambda$, signing keys $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)\xleftarrow {\$} \textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M),$ $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M')\xleftarrow {\$} \textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M')$, $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$ such that $M(x)=1=M'(x)$, the distributions of the signatures outputted by $\textsf {ABS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M),x,\textsf {msg} )$ and $\textsf {ABS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M'),x,\textsf {msg} )$ are identical.

• $\blacktriangleright$ Existential unforgeability against selective attribute adaptive chosen message attack: This property of an ABS scheme is defined through the following experiment between an adversary $\mathcal {A}$ and a challenger $\mathcal {B}$:

  • $\mathcal {A}$ submits a challenge attribute string $x^*\in \mathcal {U}_{\textsf {\textsc {abs}}}$ to $\mathcal {B}$.

  • $\mathcal {B}$ generates $(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}, \textsf {\textsc {msk}}_{\textsf {\textsc {abs}}})\xleftarrow {\$}\textsf {ABS.Setup} (\textsf {1}^\uplambda )$ and provides $\mathcal {A}$ with $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$.

  • $\mathcal {A}$ may adaptively make a polynomial number of queries of the following types:

    • Signing key query: When $\mathcal {A}$ queries a signing key corresponding to a signing policy TM $M\in \mathbb {M}_\uplambda$ subject to the restriction that $M(x^*)=0$, $\mathcal {B}$ gives back $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)\xleftarrow {\$} \textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M)$ to $\mathcal {A}$.

    • Signature query: When $\mathcal {A}$ queries a signature on a message $\textsf {msg} \in \mathcal {M}_{\textsf {\textsc {abs}}}$ under an attribute string $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$, $\mathcal {B}$ samples a signing policy TM $M\in \mathbb {M}_\uplambda$ such that $M(x)=1$, creates a signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)\xleftarrow {\$} \textsf {ABS.KeyGen} (\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M)$, and generates a signature $\sigma _{\textsf {\textsc {abs}}}\xleftarrow {\$} \textsf {ABS.Sign} (\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M),x,\textsf {msg} )$, which $\mathcal {B}$ returns to $\mathcal {A}$.

  • At the end of interaction $\mathcal {A}$ outputs a message-signature pair $(\textsf {msg} ^*,\sigma _{\textsf {\textsc {abs}}}^*)$. $\mathcal {A}$ wins if the following hold simultaneously:

    • (i) $\textsf {ABS.Verify} (\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},x^*,\textsf {msg} ^*,\sigma _{\textsf {\textsc {abs}}}^*)=1$.

    • (ii) $\mathcal {A}$ has not made any signature query on $\textsf {msg} ^*$ under $x^*$.

The ABS scheme is said to be existentially unforgeable against selective attribute adaptive chosen message attack if for any PPT adversary $\mathcal {A}$, for any security parameter $\uplambda$,

$$\begin{aligned} \textsf {Adv} _\mathcal {A}^{\textsf {\textsc {abs,uf-cma}}}(\uplambda )=\textsf {Pr} [\mathcal {A}~\text {wins}]\le \textsf {negl} (\uplambda ), \end{aligned}$$

for some negligible function $\textsf {negl}$.

Remark 3.1

Note that in the existential unforgeability experiment above without loss of generality, we can consider signature queries on messages only under the challenge attribute string $x^*$. This is because any signature query under some attribute string $x\ne x^*$ can be replaced by a signing key query for a signing policy TM $M_x\in \mathbb {M}_\uplambda$ that accepts only the string x. Since $x\ne x^*$, $M_x(x^*)=0$, and thus $M_x$ forms a valid signing key query. We use this simplification in our proof.

3.2 Overview of the proposed $\textsf{ABS}$ scheme

Here we explain the high level technical ideas underlying our ABS scheme. We start by adapting the techniques of Deshpande et al. [7] and Koppula et al. [17] to the ABS setting. Our master signing key consists of a PPRF key $\textsf {\textsc {k}}$ and a set of public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ of a positional accumulator. We assign a different signing key-verification key pair of a standard SIG scheme to each of the possible signing attribute strings and we define such an SIG signing key-verification key pair associated with a signing attribute string x as those obtained by running the setup algorithm of SIG using the randomness obtained by evaluating the underlying PPRF with key $\textsf {\textsc {k}}$ on $w_{\textsf {\textsc {inp}}}$, where $w_{\textsf {\textsc {inp}}}$ is the accumulation of the bits of x using $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$. Our signing key corresponds to some TM M would comprise of two IO-obfuscated programs $\mathcal {P}_1$ and $\mathcal {P}_{\textsf {\textsc {abs}}}$. The first program $\mathcal {P}_1$, also known as the initial signing program, takes as input an accumulator value and outputs a signature on it together with the initial state and header position of the TM M. The second program, $\mathcal {P}_{\textsf {\textsc {abs}}}$, also known as the next step program, has the PPRF key $\textsf {\textsc {k}}$ hardwired in it. It takes as input a state and header position of M, along with an input symbol and an accumulator value. It essentially computes the next step function of M on the input state-symbol pair, and eventually outputs the proper SIG signing-verification key pair, if M reaches the accepting state. More precisely, in case of reaching to the accepting state, $\mathcal {P}_{\textsf {\textsc {abs}}}$ first computes the PPRF with key $\textsf {\textsc {k}}$ on input $w_{\textsf {\textsc {inp}}}$. After that, it generates and outputs a SIG signing key-verification key pair by running the setup algorithm of SIG using the computed pseudorandom string.

The program $\mathcal {P}_{\textsf {\textsc {abs}}}$ also performs certain authenticity checks before computing the next step function of M in order to prevent illegal inputs. For this purpose, $\mathcal {P}_{\textsf {\textsc {abs}}}$ additionally takes as input a signature on the input state, header position, and accumulator value, together with a proof for the positional accumulator. The program $\mathcal {P}_{\textsf {\textsc {abs}}}$ verifies the signature in order to ensure authenticity, as well as checks the accumulator proof to get convinced that the input symbol is indeed the one placed at the input header position of the underlying storage of the input accumulator value. If all these verifications pass, then $\mathcal {P}_{\textsf {\textsc {abs}}}$ determines the next state and header position of M, as well as the new symbol that needs to be written to the input header position. The program $\mathcal {P}_{\textsf {\textsc {abs}}}$ then updates the accumulator value by placing the new symbol at the input header position, as well as signs the updated accumulator value along with the computed next state and header position of M.

Our ABS public parameters would contain $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ along with the IO-obfuscated verifying program $\mathcal {V}_{\textsf {\textsc {abs}}}$, which has the PPRF key $\textsf {\textsc {k}}$ hardwired in it. It takes as input an accumulator value and performs the following steps: First, it runs the PPRF with key $\textsf {\textsc {k}}$ on the accumulator value to generate a pseudorandom string. Next, it runs the setup algorithm of SIG using that pseudorandom string to generate and output the SIG verification key associated with the accumulator value.

In order to sign a message under some signing attribute string accepted by the TM embedded in its signing key, a signer first computes the accumulation $w_{\textsf {\textsc {inp}}}$ of the bits of x using $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ which are also included in the PPRF key $\textsf {\textsc {k}}$, and then obtains a signature on $w_{\textsf {\textsc {inp}}}$ together with the initial state and header position of M, by running the program $\mathcal {P}_1$. The signer then repeatedly runs the program $\mathcal {P}_{\textsf {\textsc {abs}}}$, each time on input the current accumulator value, current state and header position of M, along with the signature on them. Additionally, in each iteration, the signer also feeds $w_{\textsf {\textsc {inp}}}$ to $\mathcal {P}_{\textsf {\textsc {abs}}}$. The iteration is continued until the program $\mathcal {P}_{\textsf {\textsc {abs}}}$ either outputs the proper signing-verification key pair or the designated symbol $\bot$ indicating failure. After that, the signer signs the message using the obtained SIG signing key. The ABS signature consists of the generated SIG verification key-signature pair. The signature verification process on some message under some claimed signing attribute string requires first generating the SIG verification key associated with the claimed signing attribute string by accumulating the bits of the claimed signing attribute string using $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ and inputting the accumulated value to $\mathcal {V}_{\textsf {\textsc {abs}}}$. It then checks whether the generated SIG verification key matches the one included within the ABS signature, as well as whether the SIG signature included within the ABS signature verifies under that SIG verification key.

While the above strategy appears to be sound, there still remain some subtle issues. Observe that to handle the positional accumulator related verifications and updations, the program $\mathcal {P}_{\textsf {\textsc {abs}}}$ must have $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ hardwired in it. During the course of the selective unforgeability proof, we have to modify the signing keys given to the adversary $\mathcal {A}$ to embed the punctured PPRF key $\textsf {\textsc {k}}\{w_{\textsf {\textsc {inp}}}^*\}$ punctured at $w_{\textsf {\textsc {inp}}}^*$ instead of the full PPRF key $\textsf {\textsc {k}}$. Here, $w_{\textsf {\textsc {inp}}}^*$ is the accumulation of the bits of the challenge signing attribute string $x^*$, committed by $\mathcal {A}$ at the beginning of the experiment, using $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ included within the public parameters given to the adversary $\mathcal {A}$. In order to make this substitution, it is to be ensured that the programs $\mathcal {P}_{\textsf {\textsc {abs}}}$ included in those signing keys always outputs $\bot$ for signing attribute strings corresponding to $w_{\textsf {\textsc {inp}}}^*$ even if reaching the accepting state. As usual, we would carry out the transformation one signing key at a time through multiple hybrid steps. Now, suppose for transforming the signing keys we attempt to follow a strategy similar to that of [7, 17]. Let the total number of signing keys queried by $\mathcal {A}$ be $\hat{q}_{\textsf {\textsc {key}}}$. Consider the transformation of the $\nu$th signing key ($1\le \nu \le \hat{q}_{\textsf {\textsc {key}}}$) corresponding to the TM $M^{(\nu )}$ that runs on the challenge signing attribute string $x^*$ for $t^{*(\nu )}$ steps and reaches the rejecting state. In the course of transformation, the program $\mathcal {P}_{\textsf {\textsc {abs}}}^{(\nu )}$ contained in the $\nu$th signing key would first be altered to one that always outputs $\bot$ for inputs corresponding to $w_{\textsf {\textsc {inp}}}^*$ within the first $t^{*(\nu )}$ steps. Towards accomplishing this transition, in successive hybrids, the steps of execution of $M^{(\nu )}$ on $x^*$ would be repeatedly programmed and unprogrammed within $\mathcal {P}_{\textsf {\textsc {abs}}}^{(\nu )}$ taking the help of IO. In order to perform this operation using IO, at various stages, we need to guarantee program functional equivalence, and for that we need to generate $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ in read/write enforcing mode, certain special statistically binding modes indistinguishable from the normal setup mode. However, in the prefixed version of positional accumulator employed in [7] or in [17], to setup $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ in read/write-enforcing mode, we require the entire sequence of symbol-position pairs arising from iteratively running $M^{(\nu )}$ on $x^*$ up to the step we are programming in. This was not a problem for [7, 17] since in their security model the adversary $\mathcal {A}$ was bounded to declare the TM queries prior to setting up the system. On the contrary, in our unforgeability experiment, $\mathcal {A}$ is allowed to adaptively submit signing key queries corresponding to signing policy TMs of its choice throughout the experiment. In such a case, we would be able to determine those symbol-position pairs only after receiving the $\nu$th queried TM $M^{(\nu )}$ from $\mathcal {A}$. However, we would require $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ while creating the signing keys queried by $\mathcal {A}$ before making the $\nu$th signing key query, and even for preparing the public parameters. Thus, it is immediate that we must generate $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ prior to receiving the $\nu$th signing key query from $\mathcal {A}$. This is clearly impossible as setting $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ in read/write enforcing mode requires the knowledge of the TM $M^{(\nu )}$, which is not available before the $\nu$th signing key query of $\mathcal {A}$.

Observe that the root cause of the problem discussed above is the use of a single set of public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}$ of the positional accumulator throughout the system. Therefore, we attempt to assign a fresh set of public parameters of the positional accumulator to each signing key. However, for compressing the signing attribute strings to a fixed length, on which the PPRF can be applied to produce the pseudorandom strings specifying the SIG signing key-verification key pairs associated with those signing attribute strings, we need a system-wide compressing tool. We employ a somewhere statistically-binding (SSB) hash function for this purpose.

Our idea is that while signing a message under some signing attribute string x using its legitimate signing key for some TM M, the signer first computes the hash value h by hashing x using the system-wide SSB hash key, which is part of the ABS public parameters. The signer also computes the accumulator value $w_{\textsf {\textsc {inp}}}$ by accumulating the bits of x using the public parameters of positional accumulator, specific to its signing key. Then, using the obfuscated initial signing program $\mathcal {P}_1$ included in its signing key, the signer will obtain a signature on $w_{\textsf {\textsc {inp}}}$ along with the initial state and header position of M. Finally, the signer will repeatedly run the obfuscated next step program $\mathcal {P}_{\textsf {\textsc {abs}}}$ included in its signing key, each time giving as input all the quantities as earlier, except that it would now have to feed the SSB hash value h in place of $w_{\textsf {\textsc {inp}}}$ in each iteration. This is because, in case $\mathcal {P}_{\textsf {\textsc {abs}}}$ reaches the accepting state, it would require h to apply the PPRF for producing the SIG signing key-verification key pair associated with x. The same change would also apply to the public verifying program $\mathcal {V}_{\textsf {\textsc {abs}}}$, namely, it would also take as input the SSB hash value of a signing attribute string in place of the accumulator value obtained by accumulating its bits.

However, this approach is not completely sound yet. Observe that, a possibly malicious signer can compute the SSB hash value h on the signing attribute string x, with respect to which it wishes to generate a signature despite of the fact that its signing policy TM M does not accepts it, but initiates the computation by accumulating the bits of only a substring of x or some entirely different signing attribute string, which is accepted by M. To prevent such malicious behavior, we include another IO-obfuscated program $\mathcal {P}_2$ within the signing key, we call the accumulating program, whose purpose is to restrict the signer from accumulating the bits of a different signing attribute string rather than the hashed one. The program $\mathcal {P}_2$ takes as input an SSB hash value h, an index i, a symbol, an accumulator value, a signature on the input accumulator value (along with the initial state and header position of M), and an opening value for SSB. The program $\mathcal {P}_2$ verifies the signature, and also checks whether the input symbol is indeed present at the index i of the string that has been hashed to form h, using the input opening value. If all of these verifications pass, then $\mathcal {P}_2$ updates the input accumulator value by writing the input symbol at the ith position of the accumulator storage, and signs the updated accumulator value (along with the initial state and header position of M). The signature used by $\mathcal {P}_2$ is also a splittable signature that facilitates the security proof. The obfuscated initial signing program $\mathcal {P}_1$ included in the signing key is also modified to take as input a hash value, and output a signature on the accumulator value corresponding to the empty accumulator storage together with the initial state and header position of M.

Moreover, for forbidding the signer from performing the computation by accumulating an M-accepted substring of the hashed input, we define the SIG signing key-verification key pair associated with a signing attribute string as the output of the setup algorithm of SIG using the pseudorandom string generated by applying the PPRF on the pair (hash value, length) of the signing attribute string instead of just the hash value. Note that, without loss of generality, we can set the upper bound of the length of signing attribute strings to be $2^\uplambda$, where $\uplambda$ is the underlying security parameter, in view of the fact that by suitably choosing $\uplambda$ we can accommodate signing attribute strings of any polynomial length. Since the lengths of the attribute strings are bounded by $2^\uplambda$, the lengths can be expressed as bit strings of size $\uplambda$. Hence, the total size of the hash value-length pair corresponding to a signing attribute string would still be bounded. Also, the obfuscated next step programs $\mathcal {P}_{\textsf {\textsc {abs}}}$ included in our signing keys, must also take as input the length of the signing attribute strings for applying the PPRF if reaching to the accepting state.

Thus, the signing procedure of our ABS scheme becomes the following: to sign a message under some signing attribute string using its legitimate signing key corresponding to some TM M, a signer first hash the signing attribute string with the system-wide SSB hash key. The signer also obtains a signature on the empty accumulator value, by running the obfuscated initial signing program $\mathcal {P}_1$ on input the computed hash value. Next, it repeatedly runs the obfuscated accumulating program $\mathcal {P}_2$ to authentically accumulate the bits of the hashed signing attribute string. Finally, it runs the obfuscated next step program $\mathcal {P}_{\textsf {\textsc {abs}}}$ iteratively on the current accumulator value along with other legitimate inputs, until it obtains either the SIG signing key-verification key pair associated with the signing attribute string under consideration or $\bot$. Once it obtains the SIG signing key-verification key pair associated with the signing attribute string, it simply signs the message using the SIG signing key, and outputs the SIG verification key-signature pair as the ABS signature on the message.

Notice that the problem with enforcing the public parameters of the positional accumulator while transforming the adaptively queried signing keys will not appear in our case as we have assigned a separate set of public parameters of positional accumulator to each signing key. However, our actual proof of selective unforgeability involves many subtleties that are difficult to describe with this high level description, and is provided in full details in the sequel. We would only like to mention here that to cope up with certain issues in the proof, another IO-obfuscated program $\mathcal {P}_3$ is also included within the signing keys, we call the signature changing program, that changes the splittable signature obtained from $\mathcal {P}_2$ on the accumulation of the bits of the signing attribute string, before starting the iterative computation with the obfuscated next step program $\mathcal {P}_{\textsf {\textsc {abs}}}$.

3.3 The proposed ABS scheme

We now formally describe our ABS scheme. Let $\uplambda$ be the underlying security parameter. Let $\mathbb {M}_\uplambda$ denote a family of TMs, the members of which have (worst case) running time bounded by $T=2^\uplambda$, input alphabet $\Sigma _{\textsf {\textsc {inp}}}=\{0,1\}$, and tape alphabet $\Sigma _{\textsf {\textsc {tape}}}=\{0,1,\_\}$. Our ABS construction supporting signing attribute universe $\mathcal {U}_{\textsf {\textsc {abs}}}\subset \{0,1\}^*$, signing policies representable by TMs in $\mathbb {M}_\uplambda$, and message space $\mathcal {M}_{\textsf {\textsc {abs}}}=\{0,1\}^{\ell _{\textsf {\textsc {abs-msg}}}}$ utilizes the following cryptographic building blocks.

• (i) $\mathcal{I}\mathcal{O}$: An indistinguishability obfuscator for general polynomial-size circuits.

• (ii) $\textsf {SSB}=(\textsf {SSB.Gen}, ~\mathcal {H}, ~\textsf {SSB.Open}, ~\textsf {SSB.Verify})$: A somewhere statistically binding hash function with block alphabet $\Sigma _{\textsf {\textsc {ssb-blk}}}=\{0,1\}$.

• (iii) $\textsf {ACC} ~~ = ~~ (\textsf {ACC.Setup}, ~~ \textsf {ACC.Setup-Enforce-Read}, ~~ \textsf {ACC.Setup-Enforce-Write}, \textsf {ACC.Prep-Read}, \textsf {ACC.Prep-Write}, \textsf {ACC.Verify-Read}, \textsf {ACC.Write-Store}, \textsf {ACC.Update})$: A positional accumulator with block alphabet $\Sigma _{\textsf {\textsc {acc-blk}}}=\{0,1,\_\}$.

• (iv) $\textsf {ITR}=(\textsf {ITR.Setup}, ~\textsf {ITR.Setup-Enforce}, ~\textsf {ITR.Iterate})$: A cryptographic iterator with an appropriate message space $\mathcal {M}_{\textsf {\textsc {itr}}}$.

• (v) $\textsf {SPS}~=~(\textsf {SPS.Setup}, ~\textsf {SPS.Sign}, ~\textsf {SPS.Verify}, ~\textsf {SPS.Split}, ~\textsf {SPS.Sign-ABO})$: A splittable signature scheme with an appropriate message space $\mathcal {M}_{\textsf {\textsc {sps}}}$.

• (vi) $\textsf {PRG}:\{0,1\}^\uplambda \rightarrow \{0,1\}^{2\uplambda }$: A length-doubling pseudorandom generator.

• (vii) $\mathcal {F}=(\mathcal {F}.\textsf {Setup}, ~\mathcal {F}.\textsf {Puncture}, ~\mathcal {F}.\textsf {Eval})$: A puncturable pseudorandom function whose domain and range are chosen appropriately.

• (viii) $\textsf {SIG}=(\textsf {SIG.Setup}, \textsf {SIG.Sign}, \textsf {SIG.Verify})$: A digital signature scheme with associated message space $\mathcal {M}_{\textsf {\textsc {abs}}}=\{0,1\}^{\ell _{\textsf {\textsc {abs}}}}$ that is existentially unforgeable against chosen message attack (CMA).

Our ABS scheme is described below:

• $\textsf {ABS.Setup}(\textsf {1}^\uplambda )\rightarrow (\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}},\mathcal {V}_{\textsf {\textsc {abs}}}), \textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}=(K,\textsf {\textsc {hk}}))$: The setup authority takes as input the security parameter $\textsf {1}^\uplambda$ and proceeds as follows:

  • 1. It first chooses a PPRF key $K\xleftarrow {\$}\mathcal {F}.\textsf {Setup}(\textsf {1}^\uplambda )$.

  • 2. Next it generates $\textsf {\textsc {hk}}\xleftarrow {\$}\textsf {SSB.Gen}(\textsf {1}^\uplambda ,n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,i^*=0)$.

  • 3. Then, it creates the obfuscated program $\mathcal {V}_{\textsf {\textsc {abs}}}=\mathcal{I}\mathcal{O}(\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}[K])$, where the program $\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}$ is described in Fig. .

  • 4. It keeps the master secret key $\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}=(K,\textsf {\textsc {hk}})$ and publishes the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}},\mathcal {V}_{\textsf {\textsc {abs}}})$.

Fig. 1

$\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}$

• $\textsf {ABS.KeyGen}(\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M)\rightarrow \textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)=(\textsf {\textsc {hk}}, \textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0,\textsf {\textsc {store}}_0, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_0,\mathcal {P}_1,$ $\mathcal {P}_2, \mathcal {P}_3,\mathcal {P}_{\textsf {\textsc {abs}}})$: On input the master secret key $\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}=(K,\textsf {\textsc {hk}})$ and a signing policy TM $M=\langle Q,\Sigma _{\textsf {\textsc {inp}}},\Sigma _{\textsf {\textsc {tape}}},\delta ,q_0,q_{\textsf {\textsc {ac}}},q_{\textsf {\textsc {rej}}}\rangle \in \mathbb {M}_\uplambda$, the setup authority performs the following steps:

  • 1. At first, it selects PPRF keys $K_1,\ldots ,K_\uplambda ,K_{\textsf {\textsc {sps}},A},K_{\textsf {\textsc {sps}},E}\xleftarrow {\$}\mathcal {F}.\textsf {Setup}(\textsf {1}^\uplambda )$.

  • 2. Next, it generates $(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0,\textsf {\textsc {store}}_0)\xleftarrow {\$}\textsf {ACC.Setup}(\textsf {1}^\uplambda ,n_{\textsf {\textsc {acc-blk}}}=2^\uplambda )$ and $(\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_0)\xleftarrow {\$}\textsf {ITR.Setup}(\textsf {1}^\uplambda ,n_{\textsf {\textsc {itr}}}=2^\uplambda )$.

  • 3. Then, it constructs the obfuscated programs

    • $\mathcal {P}_1=\mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0,w_0,v_0,K_{\textsf {\textsc {sps}},E}])$,

    • $\mathcal {P}_2=\mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}, K_{\textsf {\textsc {sps}},E}])$,

    • $\mathcal {P}_3=\mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A},K_{\textsf {\textsc {sps}},E}])$,

    • $\mathcal {P}_{\textsf {\textsc {abs}}}~=~\mathcal{I}\mathcal{O}(\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}[M,~T~=~2^\uplambda ,~\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},~\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},~K,$ $~~~~~~~~~~~~~~~~~~~K_1,\ldots ,K_\uplambda ,K_{\textsf {\textsc {sps}},A}])$,

    where the programs $\textsf {Init-SPS.Prog}, \textsf {Accumulate.Prog}$, $\textsf {Change-SPS.Prog}$ and $\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}$ are shown respectively in Figs. , ,   and .

  • 4. It provides the constrained key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)=(\textsf {\textsc {hk}}, \textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0,\textsf {\textsc {store}}_0, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},$ $v_0,\mathcal {P}_1,\mathcal {P}_2,\mathcal {P}_3,\mathcal {P}_{\textsf {\textsc {abs}}})$ to a legitimate signer.

Fig. 2

$\textsf {Init-SPS.Prog}$

Fig. 3

$\textsf {Accumulate.Prog}$

Fig. 4

$\textsf {Change-SPS.Prog}$

Fig. 5

$\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}$

• $\textsf {ABS.Sign}(\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M),x,\textsf {msg})\rightarrow \sigma _{\textsf {\textsc {abs}}}=(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}}, \sigma _{\textsf {\textsc {sig}}})~\text {or}~\bot$: A signer takes as input its signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)=(\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}},w_0, \textsf {\textsc {store}}_0,\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}},v_0,\mathcal {P}_1,\mathcal {P}_2,\mathcal {P}_3, \mathcal {P}_{\textsf {\textsc {abs}}})$, corresponding to its legitimate signing policy TM $M=\langle Q,\Sigma _{\textsf {\textsc {inp}}},\Sigma _{\textsf {\textsc {tape}}},\delta ,q_0,$ $q_{\textsf {\textsc {ac}}},q_{\textsf {\textsc {rej}}}\rangle \in \mathbb {M}_\uplambda$, an attribute string $x=x_0\ldots x_{\ell _x-1}\in \mathcal {U}_{\textsf {\textsc {abs}}}$ with $|x|=\ell _x$, and a message $\textsf {msg}\in \mathcal {M}_{\textsf {\textsc {abs}}}$. If $M(x)=0$, it outputs $\bot$. Otherwise, it proceeds as follows:

  • 1. It first computes $h=\mathcal {H}_{\textsf {\textsc {hk}}}(x)$.

  • 2. Next, it computes $\breve{\sigma }_{\textsf {\textsc {sps}},0}=\mathcal {P}_1(h)$.

  • 3. Then for $j=1,\ldots ,\ell _x$, it iteratively performs the following:

    • (a) It computes $\pi _{\textsf {\textsc {ssb}},j-1}\xleftarrow {\$}\textsf {SSB.Open}(\textsf {\textsc {hk}},x,j-1)$.

    • (b) It computes $\textsf {\textsc {aux}}_j=\textsf {ACC.Prep-Write}(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{j-1},j-1)$.

    • (c) It computes $\textsf {\textsc {out}}=\mathcal {P}_2(j-1,x_{j-1},q_0,w_{j-1},\textsf {\textsc {aux}}_j,v_{j-1}, \breve{\sigma }_{\textsf {\textsc {sps}},j-1},h,$ $\pi _{\textsf {\textsc {ssb}},j-1})$.

    • (d) If $\textsf {\textsc {out}}=\bot$, it outputs $\textsf {\textsc {out}}$. Else, it parses $\textsf {\textsc {out}}$ as $\textsf {\textsc {out}}=(w_j,v_j,\breve{\sigma }_{\textsf {\textsc {sps}},j})$.

    • (e) It computes $\textsf {\textsc {store}}_j=\textsf {ACC.Write-Store}\bigg (\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{j-1},j-1,x_{j-1}\bigg )$.

  • 4. It computes $\sigma _{\textsf {\textsc {sps}},0}=\mathcal {P}_3(q_0,w_{\ell _x},v_{\ell _x},h,\ell _x, \breve{\sigma }_{\textsf {\textsc {sps}},\ell _x})$.

  • 5. It sets $\textsf {\textsc {pos}}_{M,0}=0$ and $\textsf {\textsc {seed}}_0=\epsilon$.

  • 6. Suppose, M accepts x in $t_x$ steps. For $t=1,\ldots ,t_x$, it iteratively performs the following steps:

    • (a) It computes $(\textsf {\textsc {sym}}_{M,t-1},\pi _{\textsf {\textsc {acc}},t-1})= \textsf {ACC.Prep-Read}(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{\ell _x+t-1},$ $\textsf {\textsc {pos}}_{M,t-1})$.

    • (b) It computes $\textsf {\textsc {aux}}_{\ell _x+t}=\textsf {ACC.Prep-Write}(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, \textsf {\textsc {store}}_{\ell _x+t-1}, \textsf {\textsc {pos}}_{M,t-1})$.

    • (c) It computes $\textsf {\textsc {out}}~=~\mathcal {P}_{\textsf {\textsc {abs}}}(t,\textsf {\textsc {seed}}_{t-1}, ~ \textsf {\textsc {pos}}_{M,t-1}, ~ \textsf {\textsc {sym}}_{M,t-1}, ~ \textsf {\textsc {st}}_{M,t-1}, w_{\ell _x+t-1},\pi _{\textsf {\textsc {acc}},t-1}, \textsf {\textsc {aux}}_{\ell _x+t},v_{\ell _x+t-1},h,\ell _x, \sigma _{\textsf {\textsc {sps}},t-1})$.

    • (d) If $t=t_x$, it parses $\textsf {\textsc {out}}$ as $\textsf {\textsc {out}}=(\textsf {\textsc {sk}}_{\textsf {\textsc {sig}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}})$. Otherwise, it parses $\textsf {\textsc {out}}$ as $\textsf {\textsc {out}}=(\textsf {\textsc {pos}}_{M,t},\textsf {\textsc {sym}}_{M,t}^{(\textsf {\textsc {write}})}, \textsf {\textsc {st}}_{M,t}, w_{\ell _x+t},v_{\ell _x+t},\sigma _{\textsf {\textsc {sps}},t},\textsf {\textsc {seed}}_t)$.

    • (e) It  computes  $\textsf {\textsc {store}}_{\ell _x+t}~=~\textsf {ACC.Write-Store}(\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}, ~~~ \textsf {\textsc {store}}_{\ell _x+t-1}, \textsf {\textsc {pos}}_{M,t-1},\textsf {\textsc {sym}}_{M,t}^{(\textsf {\textsc {write}})})$.

  • 7. Finally, it computes $\sigma _{\textsf {\textsc {sig}}}\xleftarrow {\$}\textsf {SIG.Sign}(\textsf {\textsc {sk}}_{\textsf {\textsc {sig}}},\textsf {msg})$.

  • 8. It outputs the signature $\sigma _{\textsf {\textsc {abs}}}=(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}}, \sigma _{\textsf {\textsc {sig}}})\in \mathcal {S}_{\textsf {\textsc {abs}}}$.

• $\textsf {ABS.Verify}(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}},x,\textsf {msg},\sigma _{\textsf {\textsc {abs}}})\rightarrow \hat{\beta }\in \{0,1\}$: A verifier takes as input the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}},\mathcal {V}_{\textsf {\textsc {abs}}})$, an attribute string $x=x_0\ldots x_{\ell _x-1}\in \mathcal {U}_{\textsf {\textsc {abs}}}$, where $|x|=\ell _x$, a message $\textsf {msg}\in \mathcal {M}_{\textsf {\textsc {abs}}}$, together with a signature $\sigma _{\textsf {\textsc {abs}}}=(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}}, \sigma _{\textsf {\textsc {sig}}})\in \mathcal {S}_{\textsf {\textsc {abs}}}$. It executes the following:

  • 1. It first computes $h=\mathcal {H}_{\textsf {\textsc {hk}}}(x)$.

  • 2. Next, it computes $\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}=\mathcal {V}_{\textsf {\textsc {abs}}}(h,\ell _x)$.

  • 3. If $[\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}}=\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}]~\wedge ~[\textsf {SIG.Verify}(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}},\textsf {msg},\sigma _{\textsf {\textsc {sig}}})=1]$, it outputs 1. Otherwise, it outputs 0.

Remark 3.2

(Efficiency of the proposed ABS scheme) From the efficiency of the underlying building blocks discussed in Sect. 2.3, it follows that our ABS.Setup algorithm runs in time polynomial in the security parameter $\uplambda$ and $\log T$, while the ABS.KeyGen algorithm runs in time polynomial in $\uplambda$, the size of the TM M for which the signing key is being generated, and $\log T$, where T is the upper bound on the worst-case running time of the supported TM family. On the other hand, the algorithm ABS.Verify runs in time polynomial in $\uplambda$, the size of the signing attribute string x considered, the size of the signed message $\textsf {msg}$, and $\log T$, whereas the algorithm ABS.Sign additionally depends on the description size of the TM M embedded within the used signing key, and the running time $t_x$ of M on the signing attribute string x. In all prior ABS constructions, the ABS.Sign algorithm depends polynomially on the worst-case running time T of the supported class of signing policies (in addition to the sizes of the signing policy, the signing attribute string, and the message considered), which in general is much larger compared to the actual running time of the used signing policy on the signing attribute string considered. Moreover, the size of signatures of our ABS scheme depends only on $\uplambda$ and the size of the signed message $\textsf {msg}$, in particular independent of the size of the signing attribute string x under which the signature is generated. This is evidently an important achievement from the point of view of communication efficiency that was beyond the reach of all prior ABS constructions.

4 Security analysis

Theorem 4.1

(Security of the proposed ABS scheme) Assuming $\mathcal{I}\mathcal{O}$ is a secure indistinguishability obfuscator for $\textsf {P/poly}$, $\mathcal {F}$ is a secure puncturable pseudorandom function, SSB is a somewhere statistically binding hash function, ACC is a secure positional accumulator, ITR is a secure cryptographic iterator, SPS is a secure splittable signature scheme, PRG is a secure injective pseudorandom generator, and SIG is existentially unforgeable against chosen message attack, the proposed ABS scheme satisfies signer privacy and existential unforgeability against selective attribute adaptive chosen message attack.

4.1 Proof overview of Theorem 4.1

Signer privacy: Observe that the ABS scheme described in Sect. 3.3 clearly preserves signer privacy since the signature on some message with respect to some signing attribute string only contains the SIG verification key obtained from hashing the signing attribute string with the system wide SSB hash function and its length together with an SIG signature on the message verifiable under that SIG verification key. In particular, the ABS signatures do not depend on the signing keys used to generate them.

Existential unforgeability: We provide here a bird’s eye view of the proof of existential unforgeability of the ABS scheme proposed in Sect. 3.3. We avoid many subtle technical details which are actually not easy to describe at an informal level and can hinder the intuitive blueprint of proof. Recall that in the selective unforgeability experiment, the adversary $\mathcal {A}$ has to commit to some signing attribute string $x^*$, under which it wishes to output a forgery, at the beginning of the experiment, and then is supplied with the public parameters, and is allowed to adaptively request any polynomial number of signatures and signing keys associated with signing policies that do not accept $x^*$. At the end, $\mathcal {A}$ outputs a forged signature on some message $\textsf {msg}^*$ under $x^*$, and is declared to be the winner if it has not queried any signature on $\textsf {msg}^*$ under $x^*$.

To argue selective unforgeability of the above ABS construction, we first change the original unforgeability experiment into one in which we hardwire the punctured PPRF key $\textsf {\textsc {k}}\{x^*\}$ punctured at $x^*$ within the verifying program $\mathcal {V}_{\textsf {\textsc {abs}}}$ included within the public parameters given to $\mathcal {A}$, as well as in the signing programs $\mathcal {P}_{\textsf {\textsc {abs}}}$ included within all the signing keys provided to $\mathcal {A}$. More precisely, we modify the program $\mathcal {V}_{\textsf {\textsc {abs}}}$ into a new program $\mathcal {V}_{\textsf {\textsc {abs}}}'$ as follows: When run on some signing attribute string $x \ne x^*$, the program $\mathcal {V}_{\textsf {\textsc {abs}}}'$ runs identically to $\mathcal {V}_{\textsf {\textsc {abs}}}$, but it uses the punctured PPRF key $\textsf {\textsc {k}}\{x^*\}$ in place of the full PPRF key $\textsf {\textsc {k}}$. On the other hand, when run on $x^*$, it uses a hardwired string $\hat{r}_{\textsf {\textsc {sig}}}^*$ as the randomness for generating the SIG verification key corresponding to $x^*$. We set $\hat{r}_{\textsf {\textsc {sig}}}^*$ to be the evaluation of the PPRF with key $\textsf {\textsc {k}}$ on $x^*$. We similarly modify the signing programs $\mathcal {P}_{\textsf {\textsc {abs}}}$ into new programs $\mathcal {P}_{\textsf {\textsc {abs}}}'$ as follows: When run on some signing attribute string $x \ne x^*$, $\mathcal {P}_{\textsf {\textsc {abs}}}'$ runs identically to $\mathcal {P}_{\textsf {\textsc {abs}}}$ except that it uses the punctured PPRF key $\textsf {\textsc {k}}\{x^*\}$ in place of the full PPRF key $\textsf {\textsc {k}}$. On the other hand, when run on input $x^*$, $\mathcal {P}_{\textsf {\textsc {abs}}}'$ outputs $\bot$.

Observe that the programs $\mathcal {V}_{\textsf {\textsc {abs}}}$ and $\mathcal {V}_{\textsf {\textsc {abs}}}'$ are clearly functionally identical since the punctured PPRF key behaves identically to the full PPRF key on all inputs $x \ne x^*$. For the same reason, for all the signing keys given to $\mathcal {A}$, the programs $\mathcal {P}_{\textsf {\textsc {abs}}}$ and $\mathcal {P}_{\textsf {\textsc {abs}}}'$ are also functionally identical since $\mathcal {A}$ is allowed to request signing keys for only those signing policies that does not accept $x^*$. Thus, by the security of IO, which stipulates that obfuscations of functionally identical programs are computationally indistinguishable, the modified experiment is computationally indistinguishable from the original one. After that, we apply the pseudorandomness at punctured point property of PPRF to change the pseudorandom string $\hat{r}_{\textsf {\textsc {sig}}}$ hardwired within $\mathcal {V}_{\textsf {\textsc {abs}}}'$ to a uniformly random one. This modification essentially ensures that a perfectly distributed SIG signing key-verification key pair gets associated to $x^*$. Note that once this alteration is made, we can directly prove the unforgeability of our ABS scheme relying on the unforgeability property of SIG.

We follow the same technique introduced in [7] for handling the tail hybrids in the final stage of transformation of the signing keys in our unforgeability experiment. Note that as in [7], we consider TMs which run for at most $T=2^\uplambda$ steps on any input. Unlike [17], Deshpande et al. [7] have devised an approach to obtain an end to end polynomial reduction to the security of IO for the tail hybrids by means of an injective pseudorandom generator (PRG). We directly adopt that technique to deal with the tail hybrids in our unforgeability proof. Please refer to [7] for a high level overview of the approach.

4.2 Formal Proof of Theorem 4.1

• $\blacktriangleright$ Signer privacy: Observe that for any message $\textsf {msg}\in \mathcal {M}_{\textsf {\textsc {abs}}}$, $(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}}, \mathcal{I}\mathcal{O}(\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}[K])), \textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}=(K,\textsf {\textsc {hk}}))\xleftarrow {\$}\textsf {ABS.Setup}(\textsf {1}^\uplambda )$, and $x\in \mathcal {U}_{\textsf {\textsc {abs}}}$ with $|x|=\ell _x$, a signature on $\textsf {msg}$ under x is of the form $\sigma _{\textsf {\textsc {abs}}}=(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}},\sigma _{\textsf {\textsc {sig}}})$, where $(\textsf {\textsc {sk}}_{\textsf {\textsc {sig}}},\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}})=\textsf {SIG.Setup}(\textsf {1}^\uplambda ;~\mathcal {F}(K, (\mathcal {H}_{\textsf {\textsc {hk}}}(x),\ell _x))),\sigma _{\textsf {\textsc {sig}}}= \textsf {SIG.Sign}(\textsf {\textsc {sk}}_{\textsf {\textsc {sig}}},$ $\textsf {msg})$. Here, $\textsf {\textsc {hk}}\xleftarrow {\$}\textsf {SSB.Gen}(\textsf {1}^\uplambda ,n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,i^*=0)$ and $K\xleftarrow {\$}\mathcal {F}.\textsf {Setup}(\textsf {1}^\uplambda )$. Thus, the distribution of the signature $\sigma _{\textsf {\textsc {abs}}}$ is clearly the same regardless of the signing key $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M)$ that is used to compute it.

• $\blacktriangleright$ Existential unforgeability: We will prove the existential unforgeability of the ABS construction of Sect. 3.3 against selective attribute adaptive chosen message attack by means of a sequence of hybrid experiments. We will demonstrate based on the security of various primitives that the advantage of any PPT adversary $\mathcal {A}$ in consecutive hybrid experiments differs only negligibly as well as that in the final hybrid experiment is negligible. We note that due to the selective attribute setting, the challenger $\mathcal {B}$ knows the challenge attribute string $x^*=x_0^*\ldots x_{\ell ^*-1}^*\in \mathcal {U}_{\textsf {\textsc {abs}}}$ and the SSB hash value $h^*=\mathcal {H}_{\textsf {\textsc {hk}}}(x^*)$ before receiving any signing key or signature query from the adversary $\mathcal {A}$. Suppose, the total number of signing key query and signature query made by the adversary $\mathcal {A}$ be $\hat{q}_{\textsf {\textsc {key}}}$ and $\hat{q}_{\textsf {\textsc {sign}}}$ respectively. As noted in Remark 3.1, without loss of generality we will assume that $\mathcal {A}$ only queries signatures on messages under the challenge attribute string $x^*$. Please refer to Fig.   for an overview of the hybrid transitions and their analysis. The description of the hybrid experiments follows:

Fig. 6

Structure of the hybrid reduction proving unforgeability of our ABS scheme

4.3 Sequence of hybrid experiments

${\textbf {\textsf {Hyb}}}_{\varvec{0}}$: This experiment corresponds to the real selective attribute adaptive chosen message unforgeability experiment described in Sect. 3.1. More precisely, this experiment proceeds as follows:

• $\mathcal {A}$ submits a challenge attribute string $x^*=x_0^*\ldots x_{\ell ^*-1}^*\in \mathcal {U}_{\textsf {\textsc {abs}}}$ with $|x^*|=\ell ^*$ to $\mathcal {B}$.

• $\mathcal {B}$ generates $(\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}}, ~ \mathcal{I}\mathcal{O}(\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}[K])), ~~ \textsf {\textsc {msk}}_{\textsf {\textsc {abs}}}=(\textsf {\textsc {hk}}, ~ K))\xleftarrow {\$} \textsf {ABS.Setup}(\textsf {1}^\uplambda )$, as described in Sect. 3.3, and provides $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$ to $\mathcal {A}$.

• For $\eta =1,\ldots ,\hat{q}_{\textsf {\textsc {key}}}$, in response to the $\eta$th signing key query corresponding to signing policy TM $M^{(\eta )}=\langle Q^{(\eta )},\Sigma _{\textsf {\textsc {inp}}},\Sigma _{\textsf {\textsc {tape}}}, \delta ^{(\eta )},q_0^{(\eta )},q_{\textsf {\textsc {ac}}}^{(\eta )}, q_{\textsf {\textsc {rej}}}^{(\eta )}\rangle \in \mathbb {M}_\uplambda$ with $M^{(\eta )}(x^*)=0$, $\mathcal {B}$ creates

  $$\begin{aligned}&\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})=\\&\left( \begin{array}{l} \textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},w_0^{(\eta )},\textsf {\textsc {store}}_0^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},v_0^{(\eta )},\\ \mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0^{(\eta )},w_0^{(\eta )},v_0^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )}, K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}[M^{(\eta )},T=2^\uplambda ,\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K,\\ \quad K_1^{(\eta )},\ldots ,K_\uplambda ^{(\eta )} ,K_{\textsf {\textsc {sps}},A}^{(\eta )}]) \end{array} \right) \\&\xleftarrow {\$}\textsf {ABS.KeyGen}(\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M^{(\eta )}), \end{aligned}$$

  as described in Sect. 3.3 and returns $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})$ to $\mathcal {A}$.

• For $\theta =1,\ldots ,\hat{q}_{\textsf {\textsc {sign}}}$, in reply to the $\theta$th signature query on message $\textsf {msg}^{(\theta )}$ under attribute string $x^*$, $\mathcal {B}$ identifies some TM $M^*\in \mathbb {M}_\uplambda$ such that $M^*(x^*)=1$, generates $\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^*)\xleftarrow {\$}\textsf {ABS.KeyGen}(\textsf {\textsc {msk}}_{\textsf {\textsc {abs}}},M^*)$, and computes $\sigma _{\textsf {\textsc {abs}}}^{(\theta )}=(\textsf {\textsc {vk}}_{\textsf {\textsc {sig}}}^*,\sigma _{\textsf {\textsc {sig}}}^{(\theta )}) \xleftarrow {\$}\textsf {ABS.Sign}(\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^*),x^*,\textsf {msg}^{(\theta )})$ as described in Sect. 3.3. $\mathcal {B}$ gives back $\sigma _{\textsf {\textsc {abs}}}^{(\theta )}$ to $\mathcal {A}$.

• Finally, $\mathcal {A}$ outputs a forged signature $\sigma _{\textsf {\textsc {abs}}}^*$ on some message $\textsf {msg}^*$ under attribute string $x^*$.

${\textbf {\textsf {Hyb}}}_{\varvec{0,\nu }}~\varvec{(\nu =1,\ldots ,\hat{q}_{{ \textsf {\textsc {key}}}})}$: This experiment is similar to $\textsf {Hyb}_0$ except that for $\eta \in [\hat{q}_{\textsf {\textsc {key}}}]$, in reply to the $\eta$th signing key query of $\mathcal {A}$ corresponding to signing policy TM $M^{(\eta )}\in \mathbb {M}_\uplambda$ with $M^{(\eta )}(x^*)=0$, $\mathcal {B}$ returns the signing key

$$\begin{aligned} \textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})= \left( \begin{array}{l} \textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},w_0^{(\eta )},\textsf {\textsc {store}}_0^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},v_0^{(\eta )},\\ \mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0^{(\eta )},w_0^{(\eta )},v_0^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}({\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}'[M^{(\eta )},T=2^\uplambda ,\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K,}\\ \quad {K_1^{(\eta )},\ldots ,K_\uplambda ^{(\eta )} ,K_{\textsf {\textsc {sps}},A}^{(\eta )},h^*,\ell ^*]}) \end{array} \right) , \end{aligned}$$

if ${\eta \le \nu }$, where the program $\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}'$ is an alteration of the program $\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}$ (Fig. 5) and is described in Fig. , while it returns the signing key

$$\begin{aligned} \textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})= \left( \begin{array}{l} \textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},w_0^{(\eta )},\textsf {\textsc {store}}_0^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},v_0^{(\eta )},\\ \mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0^{(\eta )},w_0^{(\eta )},v_0^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}[M^{(\eta )},T=2^\uplambda ,\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K,\\ \quad K_1^{(\eta )},\ldots ,K_\uplambda ^{(\eta )} ,K_{\textsf {\textsc {sps}},A}^{(\eta )}]) \end{array} \right) , \end{aligned}$$

if ${\eta >\nu }$. Observe that $\textsf {Hyb}_{0,0}$ coincides with $\textsf {Hyb}_0$.

Fig. 7

$\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}'$

${\textbf {\textsf {Hyb}}}_{\varvec{1}}$: This experiment coincides with $\textsf {Hyb}_{0,\hat{q}_{\textsf {\textsc {key}}}}$. More formally, in this experiment for $\eta =1,\ldots ,\hat{q}_{\textsf {\textsc {key}}}$, in reply to the $\eta$th signing key query of $\mathcal {A}$ corresponding to signing policy TM $M^{(\eta )}\in \mathbb {M}_\uplambda$ with $M^{(\eta )}(x^*)=0$, $\mathcal {B}$ generates all the components of the signing key as in $\textsf {Hyb}_0$, however, it returns the signing key

$$\begin{aligned}&\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})=\\&\left( \begin{array}{l} \textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},w_0^{(\eta )},\textsf {\textsc {store}}_0^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},v_0^{(\eta )},\\ \mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0^{(\eta )},w_0^{(\eta )},v_0^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}'[M^{(\eta )},T=2^\uplambda ,\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},K,\\ \quad K_1^{(\eta )},\ldots ,K_\uplambda ^{(\eta )} ,K_{\textsf {\textsc {sps}},A}^{(\eta )},h^*,\ell ^*]) \end{array} \right) . \end{aligned}$$

The rest of the experiment is analogous to $\textsf {Hyb}_0$.

${\textbf {\textsf {Hyb}}}_{\varvec{2}}$: This experiment is identical to $\textsf {Hyb}_1$ other than the following exceptions:

• (I) Upon receiving the challenge attribute string $x^*$, $\mathcal {B}$ proceeds as follows:

  • 1. It selects a PPRF key $K\xleftarrow {\$}\mathcal {F}.\textsf {Setup}(\textsf {1}^\uplambda )$ and generates $\textsf {\textsc {hk}}\xleftarrow {\$}\textsf {SSB.Gen}(\textsf {1}^\uplambda ,$ $n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,i^*=0)$ just as in $\textsf {Hyb}_1$,

  • 2. It computes $h^*= \mathcal {H}_{\textsf {\textsc {hk}}}(x^*)$ and creates the punctured PPRF key ${K\{(h^*,\ell ^*)\}} {\xleftarrow {\$}\mathcal {F}.\textsf {Puncture}(K,(h^*,\ell ^*))}$,

  • 3. It computes $\widehat{r}_{\textsf {\textsc {sig}}}^*=\mathcal {F}(K,(h^*,\ell ^*))$, forms $(\widehat{\textsf {\textsc {sk}}}_{\textsf {\textsc {sig}}}^*,\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}^*)=\textsf {SIG.Setup}(\textsf {1}^\uplambda ;\widehat{r}_{\textsf {\textsc {sig}}}^*)$,

  • 4. It  sets  the  public  parameters  $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$  to  be  given  to  $\mathcal {A}$  as  $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}~=(\textsf {\textsc {hk}}, ~\mathcal{I}\mathcal{O}({\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}'[K\{(h^*,~\ell ^*)\},~\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}^*,~h^*,~\ell ^*]}))$,  where  the  program $\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}'$ is an alteration of the program $\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}$ (Fig. 1) and is depicted in Fig. .

Fig. 8

$\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}'$

• (II) For $\eta =1,\ldots ,\hat{q}_{\textsf {\textsc {key}}}$, in response to the $\eta$th signing key query of $\mathcal {A}$ corresponding to signing policy TM $M^{(\eta )}\in \mathbb {M}_\uplambda$ with $M^{(\eta )}(x^*)=0$, $\mathcal {B}$ provides $\mathcal {A}$ with the signing key

  $$\begin{aligned}&\textsf {\textsc {sk}}_{\textsf {\textsc {abs}}}(M^{(\eta )})=\\&\left( \begin{array}{l} \textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},w_0^{(\eta )},\textsf {\textsc {store}}_0^{(\eta )}, \textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},v_0^{(\eta )},\\ \mathcal{I}\mathcal{O}(\textsf {Init-SPS.Prog}[q_0^{(\eta )},w_0^{(\eta )},v_0^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Accumulate.Prog}[n_{\textsf {\textsc {ssb-blk}}}=2^\uplambda ,\textsf {\textsc {hk}},\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )}, K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Change-SPS.Prog}[K_{\textsf {\textsc {sps}},A}^{(\eta )},K_{\textsf {\textsc {sps}},E}^{(\eta )}])\\ \mathcal{I}\mathcal{O}(\textsf {Constrained-Key.Prog}_{\textsf {\textsc {abs}}}'[M^{(\eta )},T=2^\uplambda ,\textsf {\textsc {pp}}_{\textsf {\textsc {acc}}}^{(\eta )},\textsf {\textsc {pp}}_{\textsf {\textsc {itr}}}^{(\eta )},{K\{(h^*,\ell ^*)\}},\\ \quad K_1^{(\eta )},\ldots ,K_\uplambda ^{(\eta )} ,K_{\textsf {\textsc {sps}},A}^{(\eta )},h^*,\ell ^*]) \end{array} \right) . \end{aligned}$$

${\textbf {\textsf {Hyb}}}_{\varvec{3}}$: This experiment is similar to $\textsf {Hyb}_2$ with the only exception that $\mathcal {B}$ selects ${\hat{r}_{\textsf {\textsc {sig}}}^*\xleftarrow {\$}\mathcal {Y}_{\textsf {\textsc {pprf}}}}$. More formally, this experiment has the following deviations from $\textsf {Hyb}_2$:

• (I) In this experiment $\mathcal {B}$ creates the punctured PPRF key $K\{(h^*,\ell ^*)\}$ as in $\textsf {Hyb}_2$, however, it generates ${(\widehat{\textsf {\textsc {sk}}}_{\textsf {\textsc {sig}}}^*,\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}^*)\xleftarrow {\$}\textsf {SIG.Setup}(\textsf {1}^\uplambda )}$. It includes the obfuscated program $\mathcal{I}\mathcal{O}(\textsf {Verify.Prog}_{\textsf {\textsc {abs}}}'[K\{(h^*,\ell ^*)\},\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}^*,h^*,\ell ^*])$ within the public parameters $\textsf {\textsc {pp}}_{\textsf {\textsc {abs}}}$ to be provided to $\mathcal {A}$ as earlier.

• (II) Also, for $\theta =1,\ldots ,\hat{q}_{\textsf {\textsc {sign}}}$, to answer the $\theta$th signature query of $\mathcal {A}$ on message $\textsf {msg}^{(\theta )}\in \mathcal {M}_{\textsf {\textsc {abs}}}$ under attribute string $x^*$, $\mathcal {B}$ computes ${\sigma _{\textsf {\textsc {sig}}}^{(\theta )}~\xleftarrow {\$} ~\textsf {SIG.Sign}(\widehat{\textsf {\textsc {sk}}}_{\textsf {\textsc {sig}}}^*,}$ ${\textsf {msg}^{(\theta )})}$ and returns ${\sigma _{\textsf {\textsc {abs}}}^{(\theta )}=(\widehat{\textsf {\textsc {vk}}}_{\textsf {\textsc {sig}}}^*,\sigma _{\textsf {\textsc {sig}}}^{(\theta )})}$ to $\mathcal {A}$.

4.4 Analysis

Let $\textsf {Adv}_\mathcal {A}^{(0)}(\uplambda ), \textsf {Adv}_\mathcal {A}^{(0,\nu )}(\uplambda )~(\nu =1,\ldots ,\hat{q}_ {\textsf {\textsc {key}}}), \textsf {Adv}_\mathcal {A}^{(1)}(\uplambda ), \textsf {Adv}_\mathcal {A}^{(2)}(\uplambda )$, and $\textsf {Adv}_\mathcal {A}^{(3)}(\uplambda )$ represent respectively the advantage of the adversary $\mathcal {A}$, i.e., $\mathcal {A}$’s probability of successfully outputting a valid forgery, in $\textsf {Hyb}_0,\textsf {Hyb}_{0,\nu }~(\nu =1,\ldots ,\hat{q}_{\textsf {\textsc {key}}}),\textsf {Hyb}_1,$ $\textsf {Hyb}_2,$ and $\textsf {Hyb}_3$ respectively. Then, by the description of the hybrid experiments it follows that $\textsf {Adv}_\mathcal {A}^{\textsf {\textsc {abs,uf-cma}}}(\uplambda )\equiv \textsf {Adv}_\mathcal {A}^{(0)}(\uplambda )\equiv \textsf {Adv}_\mathcal {A}^{(0,0)}(\uplambda )$ and $\textsf {Adv}_\mathcal {A}^{(1)}(\uplambda )\equiv \textsf {Adv}_\mathcal {A}^{(0,\hat{q}_{\textsf {\textsc {key}}})}(\uplambda )$. Hence, we have

$$\begin{aligned} \begin{aligned} \textsf {Adv}_\mathcal {A}^{\textsf {\textsc {abs,uf-cma}}}(\uplambda )\le&\sum _{\nu =1}^{\hat{q}_{\textsf {\textsc {key}}}}|\textsf {Adv}_\mathcal {A}^{(0,\nu -1)}(\uplambda )-\textsf {Adv}_\mathcal {A}^{(0,\nu )}(\uplambda )|+\\&\sum _{j=1}^2|\textsf {Adv}_\mathcal {A}^{(j)}(\uplambda )-\textsf {Adv}_\mathcal {A}^{(j+1)}(\uplambda )|+\textsf {Adv}_\mathcal {A}^{(3)}(\uplambda ). \end{aligned} \end{aligned}$$

(4.1)

Lemmas B.1–B.4 presented in Online Appendix B will show that the RHS of Eq. (4.1) is negligible and thus the existential unforgeability of the ABS construction of Sect. 3.3 follows. $\square$

5 Conclusion

In this paper, we construct the first ABS scheme supporting signing policies expressible as Turing machines (TM) which can handle signing attribute strings of arbitrary polynomial length and at the same time features input-specific running time for the signing algorithm. On the technical side, we devise new ideas to empower the techniques of [7, 17] to deal with adaptive key queries.