Attribute Based Signatures: The Case for Automation

Lalitha Muthu Subramanian and Roopa Vishwanathan

Department of Computer Science, New Mexico State University, Las Cruces, New Mexico, U.S.A.

Keywords:

Attribute-based Signatures, Groth-Sahai Proofs, Computer-aided Cryptography.

Abstract:

Attribute-based signatures (ABS) allow a signer to sign boolean predicates using certain attributes that are

accepted by signing policies and are associated with signing keys. Ideally, the veriﬁer of the signature must

not obtain any other information except that a signer possessing the right attributes produced the signature.

The goal of an attribute-based signature is to preserve the anonymity of the signer and the signers’ attributes,

while ensuring that a signature will only pass veriﬁcation if the signer possesses enough valid attributes to

satisfy the given predicate. In this paper, we explore the question of what would it take to automate the

construction and proofs of complex cryptographic protocols such as attribute-based signatures. We posit that,

at the minimum, it would require: (1) creating new data types to support attribute-based cryptography, and

more generally, pairing-based cryptography (2) creating new function templates to operate on the data types

(3) creating libraries for credential bundles, which are commonly used to tie in a set of attributes to a single

user (4) automating Groth-Sahai witness-indistinguishable proofs, and (5) automated functional support for

constructing a general framework for attribute-based signatures.

1 INTRODUCTION

Attribute based Signatures (Escala et al., 2011;

El Kaafarani et al., 2014; Maji et al., 2011) have at-

tracted signiﬁcant interest primarily due to the ﬁne-

grained privacy control options they offer when com-

pared to other well-used techniques, such as tradi-

tional digital signatures, ring and mesh signatures.

Attribute Based signatures (ABS) allows a signer

owning a set of attributes to anonymously sign a mes-

sage, without revealing the attributes that were used

to generate a valid signature. Thus, in ABS, the re-

cipient of a signature is convinced that someone with

a set of right attributes has signed a predicate rep-

resenting a signing policy, and indeed authenticated

a given message, but the recipient neither learns the

signer’s identity nor the attributes used to satisfy the

predicate. Hence, attribute based signatures offer the

signer a privacy-preserving environment where valid

signatures can only be produced by users who hold

a subset of valid attributes that satisfy some signing

policy.

2 RELATED WORK

Halevi (Halevi, 2005), ﬁrst proposed the idea of cre-

ating automated tools for cryptographic proof veriﬁ-

cation. His vision was to automate the tools that help

with commonly used argument techniques, i.e., tools

that help with canonical, standard parts of the proof,

and leave the more subtle, idiosyncratic parts of the

proof to the prover to be proved manually. Halevi’s

paper stressed the need for such tools to be designed

to work with existing proof frameworks, i.e., frame-

works that cryptographers understand and are famil-

iar with, as opposed to proposing new proof frame-

works, and to work in the widely-used computational

model of cryptography, as opposed to the symbolic

model of Dolev and Yao (Dolev and Yao, 1983). As

motivational examples, Halevi presented two case-

studies, in which two manually-written proofs, one

for a new block cipher encryption mode, and the other

for the Cramer-Shoup encryption system, are ana-

lyzed and pointed out places where a hypothetical

automated tool could possibly have been very use-

ful in the process of constructing the proof. In re-

sponse to this, recently researchers have proposed au-

tomated tools such as EasyCrypt (Barthe et al., 2011;

Barthe et al., 2013b), CryptoVerif (Blanchet, 2006),

CertiCrypt (Barthe et al., 2009), ZooCrypt (Barthe

et al., 2013a), and the more general-purpose proof as-

sistant Coq (labs, ) augmented with the Foundational

Subramanian, L. and Vishwanathan, R.

Attribute Based Signatures: The Case for Automation.

DOI: 10.5220/0006901405370542

In Proceedings of the 15th International Joint Conference on e-Business and Telecommunications (ICETE 2018) - Volume 2: SECRYPT, pages 537-542

ISBN: 978-989-758-319-3

537

Cryptography Framework library (FCF) (Petcher and

Morrisett, 2015). Most of these tools are proposed

for proof automation, not protocol construction. Cer-

ticrypt, EasyCrypt and FCF can be used to ver-

ify some primitives as well as most protocols, but

the proofs are non-intuitive and tedious to construct.

ZooCrypt could be used to verify proofs of crypto-

graphic primitives, but works only for a special class

of constructs: padding-based encryption schemes. In

the area of pairing-based proof automation, there has

been work in automating proofs in the generic group

model (Barthe et al., 2014; Ambrona et al., 2016; Am-

brona et al., 2017), and the standard model (Barthe

et al., 2015).

Most of these tools have been proposed for gener-

ating proofs for simple cryptographic primitives, such

as ElGamal (Barthe et al., 2011), padding-based en-

cryption schemes, etc. Automating constructions of

advanced cryptographic protocols such as attribute-

based signatures, or attribute-based encryption is a

non-intuitive and challenging task. But it is never-

theless useful, since many of the fundamental mathe-

matical constructs, and cryptographic operations used

in the design of ABS schemes are also used by other

important categories of cryptographic protocols, such

as zero-knowledge proofs, identity-based encryption,

and more. Hence, work in this area will be impactful

beyond just ABS schemes.

2.1 Contribution

In this position paper, we compare techniques used to

construct attribute-based signature schemes across the

literature, and identify those building blocks, assump-

tions, and primitives that are commonly used and

would be suitable candidates for automation. Also,

we explore possible ways to achieve this.

3 AUTOMATION SUPPORT

In this section, we give the common cryptographic

primitives, assumptions, and data types that are used

in the construction of ABS schemes, and propose tem-

plates for their automation.

3.1 Common Primitives

We now enlist some common functional primitives

that are used in the construction of ABS schemes; any

tool that automates the construction of ABS schemes

would need to provide templates and libraries that im-

plement these primitives.

A new generic primitive called credential bun-

dles (Maji et al., 2011) is widely used in ABS con-

structions. Credential bundles, intuitively tie in a

user’s identity to a set of attributes, and prevent col-

lusion among users potentially possessing the same

kind of attribute (e.g., employee), and hence model

the requirements of a set of publicly veriﬁable at-

tributes issued to a unique signer that resist collusion.

A credential bundle scheme has a message space m,

and consists of the following algorithms.

• CB.Setup: On input a security parameter, outputs

a veriﬁcation key V

and a secret key S

• CB.Gen: On input (S

,{m

,...,m

} ⊆ M)

(where {m

,...,m

} is a set of messages belong-

ing to message-space M), outputs a tag τ and sig-

natures σ

,...,σ

• CB.Ver: On input (V

,(τ,σ

)), outputs a

boolean value.

This scheme is right if CB.Ver(V

,(τ,σ

)) = 1 for

all i.

A credential bundle scheme can easily be instanti-

ated with any digital signature scheme where there is

a collection of signatures, of messages τ||m

, where

each m

is a bitstring representing an attribute and

τ is an identiﬁer that is unique to each user. Also,

in the above scheme, one could remove some of the

’s from an existing credential bundle to create a

new bundle on a subset of messages/attributes. Hav-

ing an exclusive library for credential bundles in the

automation of an attribute-based signature scheme

would prove extremely useful since little effort would

be involved in creating attributes and bundles, such

as those required to align with the semantics of the

ABS scheme. Maji et al., (Maji et al., 2011) have

used the Boneh Boyen (Boneh and Boyen, 2004),

and Waters (Waters, 2005) signature schemes as the

credential bundle component in their ABS scheme.

The attributes in their credential bundle scheme are

simple Boneh Boyen/Waters signatures on messages

of the form “userid || attr”. Although only Boneh

Boyen, and Waters’ signature schemes have been

used in (Maji et al., 2011), we can essentially have

the general framework of ABS to support any other

signature schemes as the credential bundles, such as

Boneh-Boyen-Shacham signatures, and more (Boneh

et al., 2004; Boyen and Waters, 2006). Further-

more, creating a general template for credential bun-

dles is useful since, although existing ABS scheme

use a bundle which ties its attributes to a user iden-

tity, one could potentially imagine a bundle that ties

in a set of functions to a user identity. This gener-

alized version of a credential bundle would be very

useful in automating constructions of functional en-

SECRYPT 2018 - International Conference on Security and Cryptography

538

cryption (Datta et al., 2018).

Another primitive fundamentally used in the con-

struction of ABS schemes is non-interactive witness

indistinguishability (NIWI) proofs. NIWI proofs are

used to commit to a set of attributes that purportedly

satisfy a boolean predicate while creating an attribute-

based signature. The NIWI proof system is com-

prised of algorithm mentioned below (Groth and Sa-

hai, 2008).

• NIWI.Setup: On input a security parameter, this

outputs a reference string crs.

• NIWI.Prove: Given an input (crs,φ,x), where φ is

a boolean formula and φ(x) = 1, output a proof π.

• NIWI.Verify: On an input of (crs, φ, π), either ac-

cept or reject the proof.

3.2 Data Type/Function Support

Automating the construction of attribute based sig-

nature schemes involves creating abstract data types

for pseudo attributes and pseudo predicates, both of

which are used in the attribute generation and signing

phases.

• A type for a pseudo attribute A

denoted as P

• A type for pseudo predicate,

ϒ denoted as P

The functions to support the new data types are:

• (τ, σ

;a ∈ A) ← Parse(SK

): This function parses

a secret key, SK

as (τ,σ

,(a ∈ A)), where a is an

attribute belonging to an attribute set A.

•

ϒ ← PPCreate(a ∈ A,ϒ): This function takes in

an attribute a, and a boolean predicate ϒ, and cre-

ates a pseudo predicate

ϒ ∈ P

• (a

ϒ) ← PACreate(a ∈ A,ϒ): This function takes

in an attribute a, a boolean predicate ϒ, and re-

turns a pseudo-attribute a

ϒ ∈ P

We envision the above functions as abstract data

types since the key feature of such data types is that

they are characterized by the operation that is per-

formed on them, and do not specify any concrete im-

plementation, thus giving us the ﬂexibility to instanti-

ate them with any implementation of our choice. Ab-

stract data types are accessed through methods and

support multiple implementations too. In general the

widely used methods for an abstract data type may in-

clude initialization, addition or removal of data, and

of retrieval data.

Array, List, Map, Queue, Set, Stack, Table are

some of the most commonly used abstract data types

in high-level languages. A stack for example al-

lows the functions empty(), isEmpty(), push(), top(),

pop() to be performed (without specifying the im-

plementation) when deﬁned as an abstract data type:

empty:: Stack a, isEmpty:: Stack a −→ Bool, push::

a −→ Stack a −→ Stack a, top :: Stack a −→ a, pop::

Stack a −→ (a,Stack a)

In a similar vein, deﬁning PPCreate and

PACreate as abstract data types allows us to repre-

sent attributes and predicates as data structures, with-

out having to tie down an automated tool’s libraries

to a speciﬁc implementation. Possible implemen-

tations for a PPCreate data type include a 2-d ar-

ray/linked list, or a matrix. Possible implementa-

tions for a PACreate data type include a singly/double

linked list, or a 1-d array.

3.3 Monotone Span Programs

Consider a Monotone boolean function

ϒ :

{

0,1

}

−→ 0,1. The Monotone Span Pro-

gram for ϒ over a ﬁeld F is deﬁned as a matrix

M containing the entries in F, alongside a labeling

function deﬁned as a : [l] −→ [n] such that it relates

each row of M with an input variable of ϒ, for every

,...,x

) ∈

{

0,1

}

ϒ(x

,...,x

) = 1 ⇐⇒ ∃~v ∈ F

1×l

:~vM = [1,0,...,0]

(1)

and



∀i : x

a(i)

= 0 ⇒ v

= 0



With M being the monotone matrix of length l and

width of the span program as t, we propose to create

a data type called MSP, that represents a monotone

span program, which can be declared as follows:

MSP M[l ×t] = new M[l][t]

where l and t denote the rows and columns of

the MSP matrix. We propose to create the following

functions for monotone span program matrix:

•

M ← set(M, i, j, a

i j

): This function is used to set

a value a

i, j

in the matrix of type MSP, where i and

j denote the row and column location respectively.

This function outputs

M with the updated values.

• {0, 1} ← checkVector(M, v): This function is

used to check if a vector, v = [1, . . . , 0] is present

in the any of the l rows of the matrix M.

• a

i, j

← get(M, i, j): This function is used to get a

value a

i, j

in the matrix of type MSP, where i and

j denotes the element in the matrix.

• {0, 1} ← span(M, v): This function is used to

check if a vector v spans any of the columns of

the matrix M.

Attribute Based Signatures: The Case for Automation

539

4 GENERAL FRAMEWORK

Let A denote the universe containing the ABS at-

tributes. Let A ∩ A

denote the pseudo attributes sets

where, A ∩ A

0. For each message represented by

m, and a claim predicate ϒ, the pseudo attributes that

are associated with (m, ϒ) are represented by a

ϒA

Let CB denote a credential bundle scheme.

• Φ[V

,m,ϒ] : This is the pairing expression which

represents part of the input of the non-interactive

witness indistinguishability proof, NIWI.Prove,

that goes into the construction of an attribute-

based signature, and typically needs to be encoded

into the Groth-Sahai proof system.

• Com(· · ·): This represents the commitment func-

tion that is deﬁned in the Groth-Sahai proof sys-

tem to create a commitment to the values of wit-

nesses.

• S

: These are intermediate values to which

the prover commits to in the Groth-Sahai proofs.

∈ H, C

∈ G, where G,H are groups.

The generic construction of ABS with a single

attribute-issuing authority parameterized with a uni-

verse of possible attributes A and message space M,

consists of the following ﬁve algorithms as deﬁned

by Maji et al. (Maji et al., 2011):

• ABS.TSetup: This step is to generate the public

reference information TPK.

• ABS.Setup: This algorithm generates a key pair

APK, ASK.

• ABS.AttrGen: This outputs a signing key SK

corresponding to a set of attributes A.

• ABS.Sign: On input

(PK = (T PK, APK), SK

,m ∈ M,ϒ), where

ϒ(A) = 1, outputs a signature σ.

• ABS.Ver: On input

(PK = (T PK, APK), m, ϒ, σ), outputs a boolean

value.

We propose in this paper, to create automated

libraries that would enable the signer and veriﬁer

to perform the above mentioned functionalities se-

quentially. This entails creating a template library

that is agnostic of the speciﬁcs of the public-key

encryption scheme used for the ABS.TSetup, and

ABS.ASetup algorithms (can generate key-pairs for

any scheme), creating a credential bundle library

that is independent of the signature scheme used (ei-

ther Boneh-Boyen (Boneh and Boyen, 2004), Boneh-

Boyen-Shacham (Boneh et al., 2004), etc.), and

more ambitiously, creating a library deﬁning a non-

interactive proof system, that can create commitments

to attributes used in ABS, using any non-interactive

witness indistinguishable proof system, e.g., Groth-

Sahai (Groth and Sahai, 2008).

4.1 Groth-Sahai Proof System

The Groth-Sahai proof system (Groth and Sahai,

2008) is the primary method for instantiating the non-

interactive witness indistinguishable argument in an

ABS scheme. While the Groth-Sahai method can be

used to prove witnesses to any general statement, we

are interested only in non-interactive proofs, where

the witness is an attribute that satisﬁes a Boolean

predicate. These proofs work by giving a commit-

ment to the witness values and then proving that

these committed values satisfy the pairing equations.

For generating Groth-Sahai commitments in an ABS

scheme, the statement Φ [V

,m,ϒ] needs to be efﬁ-

ciently encoded. Let us assume we need to commit

a group Z (which could be either G or H, and will be

clear from the context), Z becomes the formal vari-

able representing the commitment. In this section, we

brieﬂy go over the Groth-Sahai proof system and its

application to ABS (Maji et al., 2011).

Let us consider the pseudo-predicate

ϒ to be a ma-

trix of data type MSP deﬁned in section 3.3. Let the

size of

ϒ be l × t ,with the ith row corresponding to

the a(i)-th attribute. In order to establish the state-

ment Φ [V

,m,ϒ],the following two equations should

be proved:

∃τ,σ

,...,σ

,......,v

:~vM = [1,0,...,0] (2)

i=1



6= 0 ⇒ CB.Ver



vk, a

a(i)



τ,σ

a(i)



= 1



(3)

In addition to the above equation, the signer would

have to commit to vector ~v which can be computed

from his assignment of

ϒ. Once the signer commits

to vector ~v, the new boolean expression formed is a

combination of the two kinds of clauses. One kind of

clause has the following form

∃~v :~vM = [1, ...., 0] (4)

Committing to the values g

and proving the follow-

ing pair of equations for each j ∈ [t] will prove that

the boolean expression formed by committing to the

values is a combination of the clauses.

∏

i=1



Com (g

),h

i, j



(

(g,h) if j = 1





otherwise

(5)

SECRYPT 2018 - International Conference on Security and Cryptography

540

The second clause has the following form:

∃τ,σ,v : [v 6= 0 ⇒ CB.Ver (vk,m,(τ,σ)) = 1] (6)

The clause in Equation 6 can also be written as:

∃τ,σ,v : [v 6= 0 ⇒ DS.Ver (vk, τ||m, σ) = 1] (7)

If we have (τ, σ = (S, r), v) as a witness to the

above expression, the Groth-Sahai system then ex-

presses τ bitwise as τ = Σ

,τ||m and r is expressed

as r = Σ

We create a commitment to both r

,τ

in both

groups as g

, and then prove that each of

them is a single bit by using the following pairing

equations:

e(Com (g

),h) = e (g,Com(h

)) (8)

e(Com (g

),h) = e ((g,Com(h

)) (9)

e(Com (g

),Com(h

)) = e (Com (g

),h) (10)

e(Com (g

),Com(h

)) = e (Com (g

),h) (11)

The prover commits to some of the intermediate

values S

∈ H and C

∈ G, since he cannot directly

compute BC

τ||m

or S

given the committed values;

hence he proves the following equations:

e(Com (D

),h) =

∏



,Com (h

)



(12)

e(Com (g

),Com (S)) = e (g,Com (S

)) (13)

e(Com (C

),h) =

∏



,Com (h

)



(14)

e(Com(g

), h) =e



τ|

,Com(S

)



e(Com(C

),Com(S

))e (Com (D

),Com(S

))

(15)

The coefﬁcients in the above equations are com-

puted publicly.

4.2 Automation of General Framework

Automating the general framework of ABS involves

creation of separate libraries for data types and core

functions. The next step would be to set up the cre-

dential bundles and use some signature scheme, e.g.,

the Boneh Boyen scheme for the construction of ABS.

This automated library can be named as CB. We pro-

pose the following core functions as a part of automat-

ing the general framework of ABS Scheme.This is ef-

ﬁciently encoded in the Groth-Sahai proof system by

using the ’commit’ operation deﬁned in section 4.1

• ABS.TSetup: This library is created such that

it enables the signature trustee to run cr s with

NIWI.Setup and (tvk,tsk) and publishes T PK =

(crs,tvk) as the outcome

• ABS.ASetup: This library is created to perform

the functions of the attribute issuing authority and

publishes APK as avk and sets AS K as ask.

• ABS.AttrGen: This library essentially outputs

the result of CB.Gen(ask, A).

• ABS.Sign: This library performs the sign-

ing operation by creating the boolean

expression Φ[V

,m,ϒ] and computing

∃τ,σ

,...,σ

,......,v

. This template plays a

major part in computing π which is used in the

creation of the signature using NIWI scheme.

This is done by proving the the signature.

NIWI.Prove(crs, Φ [V

,m,ϒ];(τ,σ

,...,σ

))

• ABS.Ver: This library uses the NIWI

proof to compute the output by verifying

NIWI.Verify(crs, Φ [V

,m,ϒ];π) . This is veriﬁed

using the Groth-Sahai proof system as explained

in section 4.2 from bilinear pairing equations and

performing a commit operation.

The automation of Groth-Sahai proofs will in-

volve the following method of creating templates.

The major automation effort would be to perform

the commitment operations in the Groth Sahai NIWI

proofs. The envisioned tool is expected to make the

operation successful by involving a very little man-

ual effort in verifying the signature. It can be cor-

related to having a ”commit” button, and the system

performs the operation and veriﬁes the signature once

the ”commit” button is pressed, returning 1 if true, 0

otherwise.

5 FUTURE WORK AND

CONCLUSION

In this paper, we have outlined the components of

a tool that we propose to build, that will assist in

the automation of the construction of attribute-based

signatures. Developing such a tool is a challenging

task, but will be very useful, given that the construc-

tion of ABS schemes is a tedious, error-prone task.

Furthermore, the fundamental mathematical assump-

tions and basic cryptographic constructs such as span

programs, and non-interactive witness indistinguish-

able proofs that are used in ABS, are used across the

spectrum of cryptographic protocols, well beyond the

realm of ABS. Hence, any effort towards this goal

is likely to beneﬁt other areas within cryptography

Attribute Based Signatures: The Case for Automation

541

too. As a starting point, we have outlined the basic

data types, functions to manipulate those data types,

and proposed a general library template that can con-

struct ABS scheme automatically. Building upon this

preliminary work will require not just implementing

the ideas presented in this paper, but also borrowing

knowledge and theories from the logic and automated

reasoning communities to build a tool that not only

produces correct constructions, but is also grounded

in a rigorous theoretical framework.

REFERENCES

Ambrona, M., Barthe, G., Gay, R., and Wee, H.

(2017). Attribute-based encryption in the generic

group model: Automated proofs and new construc-

tions. In Proceedings of the 2017 ACM CCS, pages

647–664.

Ambrona, M., Barthe, G., and Schmidt, B. (2016). Auto-

mated unbounded analysis of cryptographic construc-

tions in the generic group model. In Advances in

Cryptology - EUROCRYPT 2016, pages 822–851.

Barthe, G., Crespo, J. M., Gr

egoire, B., Kunz, C.,

Lakhnech, Y., Schmidt, B., and Zanella-B

eguelin, S.

(2013a). Fully automated analysis of padding-based

encryption in the computational model. In Proceed-

ings of the 2013 ACM CCS, CCS ’13, pages 1247–

1260.

Barthe, G., Dupressoir, F., Gr

egoire, B., Kunz, C., Schmidt,

B., and Strub, P. (2013b). Easycrypt: A tutorial. In

Foundations of Security Analysis and Design FOSAD,

pages 146–166.

Barthe, G., Fagerholm, E., Fiore, D., Mitchell, J. C., Sce-

drov, A., and Schmidt, B. (2014). Automated analysis

of cryptographic assumptions in generic group mod-

els. In Advances in Cryptology - CRYPTO, pages 95–

112.

Barthe, G., Gr

egoire, B., Heraud, S., and B

eguelin, S. Z.

(2011). Computer-aided security proofs for the work-

ing cryptographer. In Advances in Cryptology -

CRYPTO, pages 71–90.

Barthe, G., Gr

egoire, B., and Schmidt, B. (2015). Auto-

mated proofs of pairing-based cryptography. In Pro-

ceedings of the 22nd ACM Conference on Computer

and Communications Security, CCS, pages 1156–

1168.

Barthe, G., Gr

egoire, B., and Zanella-B

eguelin, S. (2009).

Formal certiﬁcation of code-based cryptographic

proofs. In 36th ACM SIGPLAN-SIGACT POPL 2009,

pages 90–101. ACM.

Blanchet, B. (2006). A computationally sound mechanized

prover for security protocols. In 2006 IEEE Sympo-

sium on Security and Privacy (S&P), pages 140–154.

Boneh, D. and Boyen, X. (2004). Short signatures without

random oracles. In Eurocrypt, pages 56–73. Springer.

Boneh, D., Boyen, X., and Shacham, H. (2004). Short

group signatures. In Crypto, pages 41–55. Springer.

Boyen, X. and Waters, B. (2006). Compact group signature

without random oracles. In Eurocrypt, pages 427–

444. Springer.

Datta, P., Okamoto, T., and Tomida, J. (2018). Full-hiding

(unbounded) multi-inner product functional encryp-

tion from the k-linear assumption. In To appear in

PKC.

Dolev, D. and Yao, A. C. (1983). On the security of pub-

lic key protocols. IEEE Transactions on Information

Theory, 29(2):198–207.

El Kaafarani, A., Ghadaﬁ, E., and Khader, D. (2014). De-

centralized traceable attribute-based signatures. In

Benaloh, J., editor, Topics in Cryptology – CT-RSA

2014, pages 327–348, Cham. Springer International

Publishing.

Escala, A., Herranz, J., and Morillo, P. (2011). Revocable

attribute-based signatures with adaptive security in the

standard model. In Nitaj, A. and Pointcheval, D., ed-

itors, Progress in Cryptology – AFRICACRYPT 2011,

pages 224–241, Berlin, Heidelberg. Springer Berlin

Heidelberg.

Groth, J. and Sahai, A. (2008). Efﬁcient non-interactive

proof systems for bilinear groups. In Eurocrypt, pages

415–432.

Halevi, S. (2005). A plausible approach to computer-aided

cryptographic proofs. Cryptology ePrint Archive, Re-

port 2005/181.

labs, I. The Coq proof assistant. https://coq.inria.fr/.

Maji, H. K., Prabhakaran, M., and Rosulek, M. (2011).

Attribute-based signatures. In Kiayias, A., editor, Top-

ics in Cryptology – CT-RSA 2011, pages 376–392,

Berlin, Heidelberg. Springer Berlin Heidelberg.

Petcher, A. and Morrisett, G. (2015). The foundational

cryptography framework. In Principles of Security

and Trust - 4th International Conference, POST, Pro-

ceedings, pages 53–72.

Waters, B. (2005). Efﬁcient identity-based encryption with-

out random oracles. In Eurocrypt, pages 114–127.

Springer.

SECRYPT 2018 - International Conference on Security and Cryptography

542