Massive Group Message Authentication

with Revocable Anonymity

Boaz Catane and Amir Herzberg

Department of Computer Science, Bar Ilan University, 52900, Ramat Gan, Israel

Keywords:

Digital Signatures, Group Signatures, Revocation, Efﬁcient Implementations.

Abstract:

We present and implement schemes for authenticating messages from a group of users to a recipient, with

revocable anonymity and massive (very high) message rate. Our implementations present a trade-off between

the efﬁciency and the security required: from online group managers that participate in every message sent

to ofﬂine managers, from assuming a trusted group manager and a trusted recipient to securing against both

entities. All implementations have the traceablity feature, allowing distributive and efﬁcient tracing of all mes-

sages originating from a speciﬁc group member without violating anonymity of other members. In addition,

our schemes are efﬁcient and practical.

1 INTRODUCTION

Schemes where messages are sent to a central loca-

tion are widely used for various purposes. In many

cases, only a designated group of users may send mes-

sages to the central location. In addition, sometimes

the designated users’ privacy should be kept. In such

cases an anonymous messaging or reporting scheme

should be used.

Commonly, when questionable or faulty reports

are found in a system, the identity of the originator

of such reports should be revealed. In such cases

schemes allowing anonymity revocation should be

used. Moreover, if the originator is found to be mali-

cious there is also a need to efﬁciently single out all

reports generated by this user.

An example where such schemes can be useful is

when numerous organizations want to anonymously

share sensitive data, such as information regardingcy-

ber security breaches. When an organization (e.g. a

bank) identiﬁes its computer systems were breached,

it would not want this information to leak out. How-

ever, it would like to know if it was a target of a pin-

pointed attack or if similar computer systems of other

organizations were breached as well, as this will af-

fect the organization’s reaction. A scheme that allows

anonymous reporting of cyber attacks, with the abil-

ity to break anonymity in extreme cases (e.g. faulty

reports), can be used. Another application of such

a scheme is a log of keycard access to restricted ar-

eas that permit entry to members of a speciﬁc group

only, when it is inappropriate to track movements of

individual members. Again, in extreme cases such as

faulty reports there is a need to retrospectively break

anonymity and identify the speciﬁc member that en-

tered the restricted zone at a speciﬁc time.

To resolve this and other privacy related problems,

Chaum and Van Heyst introduced group signatures

(Chaum and Van Heyst, 1991). Their scheme enables

members of a group to create indistinguishable mes-

sage signatures, i.e. they provide unlinkability and

anonymity within members of the group. A special

entity, the group manager, is responsible for identify-

ing the group member that originated the signature.

Later works on group signatures provided more ef-

ﬁcient constructions based on different assumptions,

but usually achieve the same goals. See Related Work

(Section 1.4) for further details.

A close observation reveals that some security fea-

tures of group signatures are not vital in scenarios

such as the cyber security database or the keycard ac-

cess log given above:

• Group signatures are publicly veriﬁable. How-

ever, in the given scenarios only a single entity

(the cyber security database or the keycard access

system) should be able to verify authentication as

no other entity is given a signature.

• Many group signature schemes require that the

group manager or the recipient is unable to imper-

sonate members (i.e. create signatures on their be-

half). We argue that in the given scenarios as well

331

Catane B. and Herzberg A..

Massive Group Message Authentication with Revocable Anonymity.

DOI: 10.5220/0004509203310338

In Proceedings of the 10th International Conference on Security and Cryptography (SECRYPT-2013), pages 331-338

ISBN: 978-989-8565-73-0

 2013 SCITEPRESS (Science and Technology Publications, Lda.)

as many others this requirement is not needed:

Since there is a single group manager as well as

a single recipient, trusted parties can be found for

both. A national cyber security database for banks

managed by the government or a keycard access

system run by the army to restrict personnel ac-

cess to sensitive military zones are such examples.

The government or the army are either trusted or

haveenoughpower to frame innocent group mem-

bers without the use of such a system.

1.1 Entities

In our massive group message authentication schemes

the following entities are involved:

Recipient. The central entity to which messages are

sent. When a new message is received, the re-

cipient validates the message was originated by a

group member before saving it. In extreme cases

(e.g. when a fraudulent message is found) the

recipient will send a message it received to the

group manager in order to identify the message

originator.

Group Members. Users that are members of the

group. They send messages to the recipient.

Group Manager. Manages the group by adding and

removing members to or from the group. In ad-

dition, the group manager can revoke anonymity

and retrospectively reveal the identity of the orig-

inator of a given message.

1.2 Contribution

Motivated by the observation that a fully featured

group signature scheme is not needed in many appli-

cations, we present efﬁcient massive group message

authentication schemes that allow anonymity revoca-

tion. The schemes vary in the exact trade-offs be-

tween efﬁciency and the trust given in the group man-

ager or the recipient. We also compare the security

and efﬁciency of our schemes with those of related

schemes.

1.3 Requirements

The requirements for revocable-anonymity group

message authentication schemes are:

Authentication. When receiving a report, the recipi-

ent should be able to verify that the originator of

the report is a group member.

Anonymity. Given a report, the recipient should not

be able to identify the speciﬁc group member that

originated the report.

Anonymity Revocation. The group manager should

be able to retrospectively identify the originator

of a given report. This requirement can be deﬁned

by any or all the following requirements:

Against Peers. Reports sent by group members

will not be veriﬁed by the recipient unless the

group manager is able to identify the true orig-

inator of the report.

Against the Group Manager. Reports sent by

the group manager on behalf of honest (non-

colluding) group members will not be veriﬁed

by the recipient.

Against the Recipient. The recipient will not be

able to send a report to the group manager such

that the manager will identify it as originating

from an honest (non-colluding.) group mem-

ber.

Traceability. Given the identity of a speciﬁc group

member, the manager and the recipient can to-

gether trace all reports originating from that mem-

ber, and without revealing the identities of the

originators of other reports.

Efﬁciency. Scheme operations should have high ef-

ﬁciency. In particular, they should avoid or re-

quire a few group operations (e.g. modular expo-

nentiations) as possible. In addition, when tracing

all reports originated from a given group member,

the recipient should be able to trace the reports

distributively using untrusted agents, i.e. these

agents will not be giventhe recipient’ssecret keys.

Regarding efﬁciency, it seems desirable that in ad-

dition to low computationalcosts (as discussed above)

the group manager will be able to work ofﬂine, i.e.

will not have to participate in every report sent, but

rather only at ofﬂine intervals (e.g. at the initializa-

tion phase). See Section 6 for a detailed efﬁciency

analysis and comparison to related work.

1.4 Related Work

Group signature schemes, in which a group member

can sign messages on behalf of the group without

revealing the signer’s identity, were ﬁrst introduced

by Chaum and Van Heyst (Chaum and Van Heyst,

1991). Later, Bellare et al. (Bellare et al., 2003)

gave a more provable-security oriented formal deﬁ-

nition. They introduced the full-anonymity and full-

traceability security requirements and showed they

imply many other security requirements mentioned in

the literature. They also provided a construction of a

group signature scheme assuming only the existence

of trapdoor permutations, and proved the security of

SECRYPT2013-InternationalConferenceonSecurityandCryptography

332

the scheme in the standard model. The group is as-

sumed to be static, meaning the number and identi-

ties of group members cannot change after the initial

setup. The sizes of all keys depend logarithmically on

the number of group members. Bellare et al. (Bellare

et al., 2005) continued to formalize a deﬁnition and

provide a construction for partially dynamic groups

in which members join (but not leave) the group over

time.

Additional works present efﬁcient schemes, but

rely on non-standard pairing-based assumptions (e.g.

(Ateniese et al., 2005; Boyen and Waters, 2006))

or are secure in the random oracle model (such as

(Camenisch and Groth, 2005)), which is not sound

(Canetti et al., 2004).

Kiayias et al. (Kiayias et al., 2004) were the

ﬁrst to introduce the privacy primitive traceable sig-

natures, which enables tracing of all signatures of a

single group member efﬁciently and without violat-

ing privacy of signatures that do not belong to that

member. Based on that work and on bilinear pairing,

Choi et al. (Choi et al., 2006) present a more efﬁcient

traceable signature scheme using shorter signatures.

In their paper, Przydatek and Wikstr¨om (Przy-

datek and Wikstr¨om, 2010) observe that some fea-

tures of group signatures, such as the public veriﬁa-

bility of signatures, are not necessary in many appli-

cations. They present a relaxed notion of group sig-

natures and provide both generic and concrete imple-

mentations for it. In our paper we follow the same

path: We argue that some observed group signature

features are nonessential, and provide implementa-

tions for a relaxed notion that renounces the nonessen-

tial features. Nevertheless, our work differs in many

aspects from Przydatek and Wikstr¨om, as shown in

Table 1 (regarding security requirements) and in Sec-

tion 6 (regarding efﬁciency).

Cheng et al. (Cheng et al., 2011) present an

interactive and efﬁcient group signature scheme in

which an Opener (i.e. the group manager that breaks

anonymity) is actively involvedin every signature (i.e.

the Opener is online when signing messages). The ad-

vantages of their scheme are the efﬁciency and con-

venience of using regular signature schemes such as

RSA signatures along with the straightforward way

for members to join or leave the group. The disadvan-

tages are the need to interact with an online Opener

for each signature. We show in Section 2 how to

modify their scheme in order to meet the traceability

requirement.

2 ONLINE MANAGER SCHEME

In their paper, Cheng et al. (Cheng et al., 2011)

present an interactive and efﬁcient signature scheme.

We show below that although their scheme does not

satisfy the traceability requirement, it can be easily

modiﬁed in order to satisfy it with minor performance

overhead. When storing (i, H(M), t

) in the signature

table (as stated in their GSig algorithm), the Opener

can sort the data by the values of H(M) and also store

an index of the data according to the group member

identiﬁer i. This will allow the Opener, when receiv-

ing a message by the Database (i.e. the recipient), to

not only identify the originator of the report (by ﬁnd-

ing the record containing the value H(M)), but also

to single out all hash values of reports that originated

from that same member. These values can be given to

the Database. The Database, which is also modiﬁed

to store each report with its hash value and sort the

records according to these values, can efﬁciently ﬁnd

all relevant reports, effectively identifying all reports

originating from the aforementioned member.

Based on this scheme, we present in Figure 1 a

new scheme that ﬁts the needs of a single recipient

serving multiple members of a speciﬁc group. In this

scenario group members send reports anonymouslyto

the recipient while the recipient can verify only that a

group member sent a report, but cannot identify the

member. The scheme is as follows:

1. A group member sends a hash value of the report

with her

signature on that value to the manager.

2. The manager signs the hash value and returns it to

the member.

3. The member sends the report along with its

manager-signed hash value to the recipient.

4. After veriﬁcation of the manager’s signature, the

report and the signature are added as a record to

the recipient’s database.

If anonymity revocation is needed, the recipient

can send the hash value of a report to the manager.

The manager will consult his table, in which he stored

(H(M), i) pairs, and reveal the identity of the report’s

originator. He will then single out all hash values

of reports originating from that member and forward

them to the recipient, who will single out all reports

received from that member.

For clarity of reference, we use she, her, etc. to refer to

the group members, and he, his, etc. to refer to other entities

(the group manager and the recipient).

MassiveGroupMessageAuthenticationwithRevocableAnonymity

333

Table 1: Security requirements comparison.

Security Require-

ments

Przydatek and

Wikstr

om, 2010

Cheng et al.,

2011

Online Man-

ager Scheme

(Section 2)

Ofﬂine Manager

Schemes (Sections

3 and 4)

Enhanced Se-

curity Scheme

(Section 5)

Anonymity Yes

Authentication Yes

Yes Yes

Yes

Traceability No No Yes Yes Yes

Anonymity revocation

- Against peers Yes

- Against the group

manager

Yes Yes No No Yes

- Against the recipient No Yes Yes No Yes

Figure 1: Online manager scheme.

2.1 Evaluation

As with the scheme presented in (Cheng et al., 2011),

the advantages of this scheme is the efﬁciency ob-

tained by using regular digital signatures and ease of

adding or removing group members. Furthermore,

we do not rely on bilinear pairings, but at the cost of

security. Speciﬁcally, this scheme assumes a trusted

group manager. As mentioned, our scheme also has

the traceability requirement. The disadvantage is the

need for an online manager to participate in every re-

port.

3 OFFLINE MANAGER SCHEME

Figure 2 presents an ofﬂine manager scheme in which

group members send reports to the recipient along

with one-time tokens. The tokens are created and

handed out to the members by the manager at the of-

ﬂine phase, and each token consists of a random string

of bits and its corresponding MAC. The MAC is com-

puted using a secret key known only to the manager

and the recipient. When receiving a report and its at-

tached token the recipient acknowledges the report if

and only if he can authenticate the MAC. By authen-

ticating it the recipient is convinced that the manager

issued this token and will be able to identify the mem-

Assuming a trusted group manager.

Figure 2: Ofﬂine manager scheme.

ber that received it and sent it with her report. The

scheme is as follows:

At the beginning of each time period t the following

steps are taken:

1. the manager and the recipient agree on a new se-

cret MAC key k

2. The manager sends each member n tokens, each

consists of a random string and its MAC, gener-

ated using k

During time period t group members may do any of

the following steps:

1. Request more tokens from the manager (who will

respond ofﬂine, i.e. at some point in the future,

but during the current time period t).

2. Send a report:

(a) Send a (report, token) pair to the recipient.

(b) The recipient will authenticate the MAC in the

token and validate it was not used before. Then

it will add the (report, token) pair as a record.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

334

Notes about token reuse: Firstly, schemes in

which a single token can be used m times with m > 1

could be constructed, but for simplicity we consider

only one-time token schemes. Secondly, before ac-

knowledging a report the recipient checks whether the

token was used before. Actually, a more optimistic

approach can be used: When a (report, token) pair is

received the recipient adds it as a record without fur-

ther inspection. Additionally, the recipient performs

occasional searches for tokens that are used multiple

times. If such a token is found the recipient can con-

tact the manager in order to reveal the identify of the

misbehaving member.

Adding or removing members from the group is

done as follows: To join the group a user needs only

to contact the manager,which will give her tokens. To

remove a member from the group the manager needs

only to send the recipient all tokens (actually, all ran-

dom string portions of the tokens) sent to that member

in the current time period t. The recipient will not ac-

cept reports with the corresponding tokens until the

end of t. Note that at the beginning of time period

t + 1 the manager and the recipient will exchange a

new key k

t+1

, rendering tokens from previous time

periods obsolete.

In order to prevent eavesdropping or modiﬁcation

of tokens conﬁdentiality and integrity of messages

should be kept, and group members and the manager

should be able to authenticate each other when com-

municating. Additionally, when group members com-

municate with the recipient they should be able to au-

thenticate the recipient (but not vice versa, else group

members’ privacy is lost). These requirements can

be achieved by using the SSL protocol throughout all

communications, with certiﬁcates for all parties: in

communications between the manager and the group

members both sides should present certiﬁcates, while

in communications between a group member and the

recipient only the recipient should present a certiﬁ-

cate. Note that anonymous communication channels

are assumed (e.g. the recipient cannot identify a group

member by her IP address).

3.1 Evaluation

This ofﬂine manager scheme is efﬁcient, does not re-

quire the manager to participate in every signature,

and requires less communication than the online man-

ager scheme. However, in this scheme the man-

ager and the recipient should be trusted since each of

them can frame members. The manager can lie when

queried about a report’s originator. The recipient can

frame group members by modifying reports (e.g. in-

serting inappropriate content) but without modifying

Figure 3: Ofﬂine manager scheme without SSL.

the related tokens. These modiﬁed reports would look

to the manager as if originated by an honest group

member.

4 OFFLINE MANAGER SCHEME

WITHOUT SSL

The creation of SSL connections for every report (or

keeping alive previously used SSL connections for

long durations) may introduce a substantial overhead.

Thus, we present an improved version of the afore-

mentioned ofﬂine manager scheme (Section 3) which

does not use SSL. This scheme is shown in Figure 3.

The scheme is as follows:

1. Initialization: Each member i shares a symmet-

ric encryption key i.e and a MAC key i.a with

the manager. All communication between group

members and the manager are encrypted and au-

thenticated using these keys.

When users join the group they negotiate keys

with the manager. This can be done using com-

mon methods such as the Difﬁe-Hellman key ex-

change (Difﬁe and Hellman, 1976).

2. Setup: At the beginning of each time period t the

following steps are taken:

(a) the manager and the recipient agree on a new

secret MAC key k

(b) The manager sends n tokens for each member

i. Each token consist of a random string and

its MAC, generated using k

. The tokens are

encrypted and MACed using keys shared with

member i.

MassiveGroupMessageAuthenticationwithRevocableAnonymity

335

3. During time period t group members may do any

of the following steps:

(a) Request more tokens from the manager (who

will respond ofﬂine, i.e. at some point in the

future, but during the current time period t).

(b) Post a report:

i. Send a (report, token) pair to the recipient.

ii. The recipient will verify the MAC is correct

and the token has not been used before. Then

it will add the (report, token) pair as a record.

All reports sent from group members to the re-

cipient are encrypted using the recipient’s pub-

lic encryption key R.pk. In order to achieve

integrity, provably secure non-malleable en-

cryption schemes should be used (such as the

Cramer-Shoup scheme (Cramer and Shoup,

1998)). If the recipient replies to members (e.g.

to state that a report was added) integrity of the

reply can be achieved by the recipient MACing

the reply with a one-time MAC key that was

previously created by the member and sent to

the recipient alongside the report.

4.1 Evaluation

As can be seen, this scheme achieves conﬁdential-

ity, integrity and authenticity as the Ofﬂine Manager

Scheme (Section 3) without the use of the SSL proto-

col.

5 ENHANCED SECURITY

SCHEME

When the manager or the recipient might frame group

members a more secure scheme should be used, such

as the scheme shown in Figure 4. It ensures a higher

degree of security but is less efﬁcient. The scheme is

as follows:

Figure 4: Enhanced security scheme.

1. Ofﬂine phase:

(a) Each member creates n (public key, secret key)

one-time signature pairs to be used later. These

pairs can be created efﬁciently using schemes

such as presented by Lamport (Lamport, 1979).

The member then sends all public keys from

these pairs to the manager, signed with her pri-

vate signing key i.sk.

(b) If the member is a new member the manager

creates a key i.h and stores it along with the

member’s identity i.

for each received public key pk, the values

(pk, r, H

i.h

(r)) signed by his private signature

key; r is a random number and H

i.h

(r) is the

value of a cryptographic hash function com-

puted on r using the key i.h.

2. Online phase:

(a) To send a report, a member sends the follow-

ing to the recipient: M and Sign

(M)) - the

report and its signature created using a previ-

ously unused secret key from a one time signa-

ture pair; pk - the public key corresponding to

the used secret key; the values r and H

i.h

(r);

and Sign

Manager

(pk, r, H

i.h

(r)) - the manager’s

signature on the public key, the random num-

ber and the hash value.

(b) After validating both the manager’s signature

on pk (using the manager’s public key) and

the member’s signature on the report (using the

given key pk) the recipient adds the record



M, Sign

(M), pk, r, H

i.h

(r),

Sign

Manager

(pk, r, H

i.h

(r))



(1)

When there is a need to identify the originator of

a report M the following steps are taken:

1. The recipient sends the manager the values

hM, Sign

(M), pk, r, H

i.h

(r)i that correspond to

the report M.

2. After validating the signature (using the given pk),

the manager tries all member keysi.h until the one

corresponding to the received r, H

i.h

(r) is found.

He then outputs i as the identity of the report’s

originator and the value Sign

i.sk

(pk), i.e. i’s sig-

nature on pk, as a proof of the originator’s iden-

tity.

If there is a need to trace all reports generated

by this member the manager sends the recipient

hi, Sign

i.sk

(pk), i.hi.

3. If all i’s reports are to be traced the recipient val-

idates Sign

i.sk

(pk) (using i’s publicly known sig-

nature veriﬁcation key). Then, for each record the

SECRYPT2013-InternationalConferenceonSecurityandCryptography

336

Table 2: Efﬁciency comparison.

Przydatek and

Wikstr

om,

2010

Cheng et

al., 2011

Online

Manager

Scheme

(Section 2)

Ofﬂine

Manager

Scheme

(Section 3)

Ofﬂine Man-

ager Scheme

without SSL

(Section 4)

Enhanced

Security

Scheme

(Section 5)

Manager par-

ticipates in

every report

No Yes Yes No No No

Number of Group Operations (e.g. modular exponentiations)

Creation of

group sign. or

authentication

token

5 4 (1 by

member, 3

by manager

+ 1 bilinear

pairing)

2 0 0 2 (1 by

member

and 1 by

manager)

Veriﬁcation of

group sign. or

authentication

token

6 0 (1 bilin-

ear pairing)

1 0 0 1

Commun. be-

tween member

and recipient

Member - 19,

recipient - 17,

(full authenti-

cation protocol,

including Zero

Knowledge

Proofs)

0 0 0 Member - 5,

recipient - 6,

(encryption and

decryption by

the Cramer-

Shoup scheme

(Cramer and

Shoup, 1998))

Member -

0, recipient

- 1

recipient computes the value H

i.h

(r) using the re-

ceived i.h and the value r in the report

. Reports

whose stored H

i.h

(r) value can be recomputed us-

ing H, r, and i.h are identiﬁed as belonging to user

5.1 Security

Lemma 1. The given scheme is secure against fram-

ing of honest users.

Proof. Omitted for lack of space.

6 EFFICIENCY COMPARISON

An efﬁciency comparison of the presented and related

schemes is shown in Table 2. The table compares

whether the group manager needs to actively partic-

ipate in each report sent (e.g. personally sign each re-

port), and the number of group operations(e.g. modu-

lar exponentiations or bilinear pairings) needed in ba-

sic scheme operations.

This computation can be distributed between many

agents, each with access to the reports stored by the recipi-

ent and to i.h .

7 CONCLUSIONS

In this paper we presented various practical schemes

for a relaxed notion of group signatures, allowing

a single recipient to validate that received messages

were sent by group members while preserving mem-

bers’ anonymity. If needed, a trusted group manager

can retrospectively break anonymity and reveal the

identity of the originator of a message. In addition,

the group manager is able to efﬁciently trace all mes-

sages originated from a given group member without

affecting the anonymity of other messages. The secu-

rity and efﬁciency of the schemes proposed are com-

pared to state of the art, and are shown to be more

efﬁcient.

ACKNOWLEDGEMENTS

We thank the following organizations for ﬁnancially

supporting this research: The Ministry of Science and

Technology, Israel, and the RSA division of EMC

corporation. In addition, this work is part of the

Kabarnit-Cyber Consortium (2012-2014) under Mag-

net program, funded by the chief scientist of the Is-

raeli Ministry of Industry, Trade and Labor.

MassiveGroupMessageAuthenticationwithRevocableAnonymity

337

REFERENCES

Ateniese, G., Camenisch, J., Hohenberger, S., and

De Medeiros, B. (2005). Practical group signatures

without random oracles. EUROCRYPT06.

Bellare, M., Micciancio, D., and Warinschi, B. (2003).

Foundations of group signatures: Formal deﬁnitions,

simpliﬁed requirements, and a construction based on

general assumptions. In EUROCRYPT, pages 614–

629.

Bellare, M., Shi, H., and Zhang, C. (2005). Foundations of

group signatures: The case of dynamic groups. Topics

in Cryptology–CT-RSA 2005, pages 136–153.

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

without random oracles. Advances in Cryptology-

EUROCRYPT 2006, pages 427–444.

Camenisch, J. and Groth, J. (2005). Group signatures: Bet-

ter efﬁciency and new theoretical aspects. Security in

Communication Networks, pages 120–133.

Canetti, R., Goldreich, O., and Halevi, S. (2004). The ran-

dom oracle methodology, revisited. Journal of the

ACM (JACM), 51(4):557–594.

Chaum, D. and Van Heyst, E. (1991). Group signatures.

In Proceedings of the 10th annual international con-

ference on Theory and application of cryptographic

techniques, pages 257–265. Springer-Verlag.

Cheng, X., Yang, C., and Yu, J. (2011). A new approach

to group signature schemes. Journal of Computers,

6(4):812–817.

Choi, S. G., Park, K., and Yung, M. (2006). Short trace-

able signatures based on bilinear pairings. In IWSEC,

pages 88–103.

Cramer, R. and Shoup, V. (1998). A practical public key

cryptosystem provably secure against adaptive cho-

sen ciphertext attack. In Advances in Cryptology-

CRYPTO’98, pages 13–25. Springer.

Difﬁe, W. and Hellman, M. E. (1976). New Directions

in Cryptography. IEEE Transactions on Information

Theory, IT-22(6):644–654.

Kiayias, A., Tsiounis, Y., and Yung, M. (2004). Traceable

signatures. In Advances in Cryptology-EUROCRYPT

2004, pages 571–589. Springer.

Lamport, L. (1979). Constructing digital signatures from a

one-way function. Technical report, Technical Report

CSL-98, SRI International.

Przydatek, B. and Wikstr¨om, D. (2010). Group message

authentication. Security and Cryptography for Net-

works, pages 399–417.

SECRYPT2013-InternationalConferenceonSecurityandCryptography

338