CONTENTS

I. The TESLA Broadcast

Authentication Protocol

II. Forward-Secure Signatureswith Optimal Signing and Verifying

III. Attacks on RC4 and WEP

RSA LaboratoriesVolume 5, No. 2, Summer / Fall 2002

I. The TESLA Broadcast Authentication ProtocolAdrian Perrig, Ran Canetti, J.D. Tygar, and Dawn Song

A B S T R A C T

One of the main challenges of securing broadcast communication is source authentication, orenabling receivers of broadcast data to verify that the received data really originates from theclaimed source and was not modified en route. This problem is complicated by mutuallyuntrusted receivers and unreliable communication environments where the sender does notretransmit lost packets. The authors present TESLA (Timed Efficient Stream Loss-tolerantAuthentication), an efficient broadcast authentication protocol with low communication andcomputation overhead. TESLA scales to large numbers of receivers and tolerates packet loss.It is based on loose time synchronization between the sender and the receivers, and uses onlysymmetric cryptographic functions. Still, and as is demonstrated herein, TESLA has possiblePKI applications.

II. Forward-Secure Signatures with Optimal Signing and VerifyingGene Itkis and Leonid Reyzin

A B S T R A C T

Ordinary digital signatures have an inherent weakness: if the secret key is leaked, then all _sig-natures, even the ones generated before the leak, are no longer trustworthy. Forward-securedigital signatures were proposed by Anderson and formalized by Bellare and Miner to addressthis weakness. The authors describe the concept of forward security, and introduce the firstforward-secure signature scheme for which both signing and verifying are as efficient theGuillou-Quisquater signature scheme, one of the most efficient ordinary signature schemes.Signing and verifying signatures in their scheme requires just two modular exponentiationswith a short exponent.

III. Attacks on RC4 and WEPScott Fluhrer, Itsik Mantin, and Adi Shamir

A B S T R A C T

RC4 is the most widely used stream cipher in software applications. In this paper, the authorssummarize the known attacks on RC4, and show that it is completely insecure in the naturalmode of operation, which is used in the widely deployed Wired Equivalent Privacy protocol(WEP, which is part of the 802.11b Wi-Fi standard). They describe a new, passive ciphertext-only attack that can find an arbitrarily long key in a negligible amount of time that grows _lin-early (rather than exponentially) with the key size. The attack becomes even faster if WEP isreplaced by its proposed successor WEP2.*

CryptoBytes

RSA Laboratories continues to collaborate on improved protocols for wireless security. Fast Packet Keying is the current WEP successor in the shortterm, and AES-CCM is the proposed successor in the long term. For more details, visit http://www.rsasecurity.com/rsalabs/technotes/wep-fix.html and http://csrc.nist.gov/encryption/modes/proposedmodes/.

*Editor's Note

The TESLA Broadcast Authentication Protocol∗

Adrian Perrig Ran Canetti J. D. Tygar Dawn Song

Abstract

One of the main challenges of securing broad-cast communication is source authentication, orenabling receivers of broadcast data to verifythat the received data really originates from theclaimed source and was not modified en route.This problem is complicated by mutually un-trusted receivers and unreliable communicationenvironments where the sender does not retrans-mit lost packets.

This article presents the TESLA (TimedEfficient Stream Loss-tolerant Authentication)broadcast authentication protocol, an efficientprotocol with low communication and computa-tion overhead, which scales to large numbers ofreceivers, and tolerates packet loss. TESLA isbased on loose time synchronization between thesender and the receivers.

Despite using purely symmetric cryptographicfunctions (MAC functions), TESLA achievesasymmetric properties. We discuss a PKI appli-cation based purely on TESLA, assuming that allnetwork nodes are loosely time synchronized.

∗Most of this work was done at UC Berkeley and IBMResearch. The authors can be reached atadrian+@cs.cmu.edu, canetti@watson.ibm.com,tygar@cs.berkeley.edu, skyxd@cs.cmu.edu.

1 Introduction

Broadcast communication is gaining popularityfor efficient and large-scale data dissemination.Examples of broadcast distribution networks aresatellite broadcasts, wireless radio broadcast, orIP multicast. While many broadcast networks canefficiently distribute data to multiple receivers,they often also allow a malicious user to imper-sonate the sender and inject broadcast packets —we call this a packet injection attack. (Source-Specific Multicast (SSM, EXPRESS) is a no-table exception, and attempts to prevent this at-tack [17, 40].)

Because malicious packet injection is easy inmany broadcast networks, the receivers want toensure that the broadcast packets they receive re-ally originate from the claimed source. A broad-cast authentication protocol enables the receiversto verify that a received packet was really sent bythe claimed sender.

Simply deploying the standard point-to-pointauthentication mechanism (i.e., appending a mes-sage authentication code (MAC) to each packet,computed using a shared secret key) does not pro-vide secure broadcast authentication. The prob-lem is that any receiver with the secret key canforge data and impersonate the sender. Conse-quently, it is natural to look for solutions basedon asymmetric cryptography to prevent this at-tack; a digital signature scheme is an example ofan asymmetric cryptographic protocol. Indeed,signing each data packet provides secure broad-

2

cast authentication; however, it has high over-head, both in terms of the time required to signand verify, and in terms of the bandwidth. Severalschemes were proposed that mitigate this over-head by amortizing a single signature over sev-eral packets, e.g., [14, 25, 28, 33, 38, 39]. How-ever, none of these schemes is fully satisfactoryin terms of bandwidth overhead, processing time,scalability, robustness to denial-of-service attacks,and robustness to packet loss. Even though someschemes amortize a digital signature over multipledata packets, a serious denial-of-service attack isusually possible where an attacker floods the re-ceiver with bogus packets supposedly containinga signature. Since signature verification is oftencomputationally expensive, the receiver is over-whelmed verifying bogus signatures.

Researchers proposed information-theoreticallysecure broadcast authentication mechanisms [10,11, 12, 13, 20, 34, 35, 36]. These protocols have ahigh overhead in large groups with many receivers.

Canetti et al. construct a broadcast authentica-tion protocol based on k different keys to authen-ticate every message with k different MAC’s [7].Every receiver knows m keys and can hence ver-ify m MAC’s. The keys are distributed in sucha way that no coalition of w receivers can forge apacket for a specific receiver. The security of theirscheme depends on the assumption that at mosta bounded number (which is on the order of k) ofreceivers collude.

Boneh, Durfee, and Franklin show that one can-not build a compact collusion resistant broad-cast authentication protocol without relying ondigital signatures or on time synchronization [4].They show that any secure broadcast authenti-cation protocol with per-packet overhead slightlyless than the number of receivers can be convertedinto a signature scheme.

Another approach to providing broadcast au-thentication uses only symmetric cryptography,more specifically on message authentication codes(MACs), and is based on delayed disclosure ofkeys by the sender. This technique was indepen-dently discovered by Cheung [8] in the context ofauthenticating link state routing updates. A re-lated approach was used in the Guy Fawkes proto-col for interactive unicast communication [1]. Inthe context of multicast streamed data it was pro-posed by several authors [2, 3, 5, 27, 28].

The main idea of TESLA is that the sender at-taches to each packet a MAC computed with a keyk known only to itself. The receiver buffers thereceived packet without being able to authenti-cate it. A short while later, the sender discloses kand the receiver is able to authenticate the packet.Consequently, a single MAC per packet suffices toprovide broadcast authentication, provided thatthe receiver has synchronized its clock with thesender ahead of time.

This article is an overview of the TESLA broad-cast authentication protocol. A more detailed de-scription is in a forthcoming book [30] and in ourearlier publications [27, 28]. A standardization ef-fort for TESLA is under way in the Multicast Se-curity (MSEC) working group of the IETF [26].TESLA is used in a wide variety of applications,ranging from broadcast authentication in sensornetworks [29], to authentication of messages inad hoc network routing protocols [18].

2 Background and Assumptions

TESLA requires that the receivers are loosely timesynchronized with the sender. In this section,we review a simple protocol to achieve this timesynchronization. TESLA also needs an efficientmechanism to authenticate keys at the receiver —we first review one-way chains for this purpose.

3

2.1 One-Way Chains

Many protocols need to commit to a sequence ofrandom values. For this purpose, we repeatedlyuse a one-way hash function to generate a one-waychain. One-way chains are a widely-used crypto-graphic primitive. One of the first uses of one-way chains was for one-time passwords by Lam-port [21]. Haller later used the same approach forthe S/KEY one-time password system [16]. One-way chains are also used in many other applica-tions.

Figure 1 shows the one-way chain construction.To generate a chain of length � we randomly pickthe last element of the chain s�. We generate thechain by repeatedly applying a one-way functionF . Finally, s0 is a commitment to the entire one-way chain, and we can verify any element of thechain through s0, e.g. to verify that element si

is indeed the element with index i of the hashchain, we check that F i(si) = s0. More gener-ally, si commits to sj if i < j (to verify that sj ispart of the chain if we know that si is the ith el-ement of the chain, we check that F j−i(sj) = si).We reveal the elements of the chain in this or-der s0, s1, . . . , s�−1, s�. How can we store thischain? We can either create it all at once and storeeach element of the chain, or we can just store s�

and compute any other element on demand. Inpractice, a hybrid approach helps to reduce stor-age with a small recomputation penalty. Jakobs-son [19], and Coppersmith and Jakobsson [9] pro-pose a storage efficient mechanism for one-waychains: a one-way chain with N elements onlyrequires log(N) storage and log(N) computationto access an element.

In TESLA, the elements of the one-way chainare keys, so we call the chain a one-way key chain.Furthermore, any key of the one-way key chaincommits to all following keys, so we call such akey a one-way key chain commitment, or simplykey chain commitment.

s�s�−1s�−2s1s0

F (s�)F (s�−1)F (s2)F (s1). . .

Generate

Use / Reveal

Figure 1: One-way chain example. The sendergenerates this chain by randomly selecting s� andrepeatedly applying the one-way function F . Thesender then reveals the values in the opposite or-der.

2.2 Time Synchronization

TESLA does not need the strong time synchro-nization properties that sophisticated time syn-chronization protocols provide [22, 24, 37], butonly requires loose time synchronization, and thatthe receiver knows an upper bound on the sender’slocal time. We now outline a simple and securetime synchronization protocol that achieves thisrequirement. For simplicity, we assume the clockdrift of both sender and receiver is negligible (oth-erwise the receiver can periodically resynchronizethe time with the sender). We denote the realdifference between the sender and the receiver’stime with δ. In loose time synchronization, thereceiver does not need to know the exact δ butonly an upper bound on it, ∆, which we also referto as the maximum time synchronization error.

We now describe a simple protocol for timesynchronization, where each receiver performs ex-plicit time synchronization with the sender. Thisapproach does not require any extra infrastruc-ture to perform time synchronization. We presenta simple two-round time synchronization protocolthat satisfies the requirement for TESLA, whichis that the receiver knows an upper bound on thesender’s clock. Reiter previously describes thisprotocol [31, 32].

4

t1

t2

t3 tS

tR

∆

δ

Receiver time Sender time

Figure 2: Direct time synchronization betweenthe sender and the receiver. The receiver is-sues a time synchronization request at time tR,at which time the sender’s clock is at time t1.The sender responds to the request at its localtime tS . In TESLA, the receiver is only interestedin an upper bound on the sender’s time. Whenthe receiver has its current time tr, it computesthe upper bound on the current sender’s time asts ≤ tr − tR + tS . The real synchronization er-ror after this protocol is δ. The receiver, however,does not know the propagation delay of the timesynchronization request packet, so it must assumethat the time synchronization error is ∆ (or thefull round-trip time (RTT)).

Figure 2 shows a sample time synchronizationbetween the receiver and the sender. In the pro-tocol, the receiver first records its local time tRand sends a time synchronization request contain-ing a nonce to the sender.1 Upon receiving thetime synchronization request, the sender recordsits local time tS and replies with a signed responsepacket containing tS and the nonce.2

1The security of this time synchronization protocol re-

lies on the unpredictability of the nonce — if an attackercould predict the receiver’s nonce, it could send a timesynchronization request to the sender with that nonce, andreplay the response later to the receiver.

2Interestingly, the processing and propagation delay ofthe response message does not change δ (assuming that

1. Setup. The sender S has a digital signaturekey pair, with the private key K−1

S and thepublic key KS . We assume a mechanism thatallows a receiver R to learn the authenticatedpublic key KS . The receiver chooses a ran-dom and unpredictable nonce.

2. Protocol steps. Before sending the first mes-sage, the receiver records its local time tR.

R → S : Nonce

S → R : {Sender time tS,Nonce}K−1S

To verify the return message, the receiver ver-ifies the digital signature and checks that thenonce in the packet equals the nonce it ran-domly generated. If the message is authentic,the receiver stores tR and tS . To compute theupper bound on the sender’s clock at localtime t, the receiver computes t − tR + tS .

Upon receiving the signed response, the receiverchecks the validity of the signature and verifiesthat the nonce in the response packet equals thenonce in the request packet. If all verificationsare successful, the receiver uses tR and tS to com-pute the upper bound of the sender’s time: whenthe receiver has the current time tr, it computesthe upper bound on the current sender’s time asts ≤ tr − tR + tS . The real synchronization errorafter this protocol is δ, as Figure 2 shows. Thereceiver, however, does not know the propagationdelay of the time synchronization request packet,so it must assume that the time synchronizationerror is ∆ (or the full round-trip time (RTT)).

the sender immediately records and replies with the arrivaltime of the request packet), since the receiver is only in-terested in an upper bound on the sender’s clock. If thereceiver were interested in the lower bound on the sender’sclock, the processing delay and delay of the response mes-sage would matter. For more details on this refer to themore detailed time synchronization description [30].

5

A digital signature operation is computation-ally expensive, and we need to be careful aboutdenial-of-service attacks in which an attackerfloods the sender with time synchronization re-quests. Another problem is request implosion: thesender is overwhelmed with time synchronizationrequests from receivers. We address these issuesin our earlier paper [27].

3 The TESLA Broadcast Authentica-tion Protocol

A viable broadcast authentication protocol hasthe following requirements:

• Low computation overhead for generationand verification of authentication informa-tion.

• Low communication overhead.

• Limited buffering required for the sender andthe receiver, hence timely authentication foreach individual packet.

• Robustness to packet loss.

• Scales to a large number of receivers.

The TESLA protocol meets all these require-ments with low cost — and it has the followingspecial requirements:

• The sender and the receivers must be at leastloosely time-synchronized as outlined in Sec-tion .

• Either the receiver or the sender must buffersome messages.

Despite the buffering, TESLA has a low authen-tication delay. In typical configurations, the au-thentication delay is on the order of one round-trip delay between the sender and receiver.

3.1 Sketch of TESLA protocol

We first outline the main ideas behind TESLA.Broadcast authentication requires a source ofasymmetry, such that the receivers can only ver-ify the authentication information, but not gener-ate valid authentication information. TESLA usestime for asymmetry. We assume that receivers areall loosely time synchronized with the sender —up to some time synchronization error ∆, all par-ties agree on the current time. Here is a sketch ofthe basic approach:

• The sender splits up the time into time in-tervals of uniform duration. Next, the senderforms a one-way chain of self-authenticatingvalues, and assigns the values sequentially tothe time intervals (one key per time inter-val). The one-way chain is used in the re-verse order of generation, so any value of atime interval can be used to derive values ofprevious time intervals. The sender defines adisclosure time for one-way chain values, usu-ally on the order of a few time intervals. Thesender publishes the value after the disclosuretime.

• The sender attaches a MAC to each packet.The MAC is computed over the contents ofthe packet. For each packet, the sender de-termines the time interval and uses the cor-responding value from the one-way chain asa cryptographic key to compute the MAC.Along with the packet, the sender also sendsthe most recent one-way chain value that itcan disclose.

6

• Each receiver that receives the packet per-forms the following operation. It knows theschedule for disclosing keys and, since theclocks are loosely synchronized, can checkthat the key used to compute the MAC is stillsecret by determining that the sender couldnot have yet reached the time interval for dis-closing it. If the MAC key is still secret, thenthe receiver buffers the packet.

• Each receiver also checks that the disclosedkey is correct (using self-authentication andpreviously released keys) and then checks thecorrectness of the MAC of buffered packetsthat were sent in the time interval of the dis-closed key. If the MAC is correct, the receiveraccepts the packet.

One-way chains have the property that if inter-mediate values of the one-way chain are lost, theycan be recomputed using later values. So, evenif some disclosed keys are lost, a receiver can re-cover the key chain and check the correctness ofpackets.

The sender distributes a stream of messages{Mi}, and the sender sends each message Mi ina network packet Pi along with authentication in-formation. The broadcast channel may be lossy,but the sender does not retransmit lost packets.Despite packet loss, each receiver needs to authen-ticate all the messages it receives.

We now describe the stages of the basic TESLAprotocol in this order: sender setup, receiverbootstrap, sender transmission of authenticatedbroadcast messages, and receiver authenticationof broadcast messages.

3.2 Sender Setup

TESLA uses self-authenticating one-way chains.The sender divides the time into uniform intervalsof duration Tint. Time interval 0 will start at timeT0, time interval 1 at time T1 = T0+Tint, etc. Thesender assigns one key from the one-way chainto each time interval in sequence. The one-waychain is used in the reverse order of generation, soany value of a time interval can be used to derivevalues of previous time intervals.

The sender determines the length N of theone-way chain K0,K1, . . . ,KN , and this lengthlimits the maximum transmission duration be-fore a new one-way chain must be created.3 Thesender picks a random value for KN . Using apseudo-random function f , the sender constructsthe one-way function F : F (k) = fk(0). Theremainder of the chain is computed recursivelyusing Ki = F (Ki+1). Note that this gives usKi = FN−i(KN ), so we can compute any valuein the key chain from KN even if we do not haveintermediate values. Each key Ki will be activein time interval i.

3.3 Bootstrapping Receivers

Before a receiver can authenticate messages withTESLA, it needs to be loosely time synchronizedwith the sender, know the disclosure schedule ofkeys, and receive an authenticated key of the one-way key chain.

Various approaches exist for time synchroniza-tion [24, 37, 22]. TESLA, however, only requiresloose time synchronization between the sender

3For details on how to handle broadcast streams ofunbounded duration by switching one-way key chains,see [27]. For this article we assume that chains are suf-ficiently long for the duration of communication.

7

and the receivers, so a simple algorithm is suf-ficient. The time synchronization property thatTESLA requires is that each receiver can placean upper bound of the sender’s local time, as wediscuss in Section .

The sender sends the key disclosure schedule bytransmitting the following information to the re-ceivers over an authenticated channel (either viaa digitally signed broadcast message, or over uni-cast with each receiver):

• Time interval schedule: interval durationTint, start time Ti and index of interval i,length of one-way key chain.

• Key disclosure delay d (number of intervals).

• A key commitment to the key chain Ki (i <j − d where j is the current interval index).

3.4 Broadcasting Authenticated Messages

Each key in the one-way key chain corresponds toa time interval. Every time a sender broadcasts amessage, it appends a MAC to the message, usingthe key corresponding to the current time interval.The key remains secret for the next d−1 intervals,so messages sent in interval j effectively disclosekey Kj−d. We call d the key disclosure delay.

As a general rule, using the same key multi-ple times in different cryptographic operations isill-advised — it may lead to cryptographic weak-nesses. So we do not want to use key Kj bothto derive key Kj−1 and to compute MACs. Us-ing a pseudo-random function family f ′, we con-struct the one-way function F ′: F ′(k) = f ′

k(1).We use F ′ to derive the key to compute theMAC of messages: K ′

i = F ′(Ki). Figure 3

depicts the one-way key chain construction andMAC key derivation. To broadcast message Mj

in interval i the sender constructs packet Pj ={Mj || MAC(K ′

i,Mj) || Ki−d}.

Figure 3 depicts the one-way key chain deriva-tion, the MAC key derivation, the time intervals,and some sample packets that the sender broad-casts.

3.5 Authentication at Receiver

When a sender discloses a key, all parties poten-tially have access to that key. An adversary cancreate a bogus message and forge a MAC usingthe disclosed key. So as packets arrive, the re-ceiver must verify that their MACs are based onsafe keys: a safe key is one that is only known bythe sender, and safe packets or safe messages haveMACs computed with safe keys.

Receivers must discard any packet that is notsafe, because it may have been forged.

We now explain TESLA authentication in de-tail: A sender sends packet Pj in interval i. Whenthe receiver receives packet Pj , the receiver canuse the self-authenticating key Ki−d disclosed inPj to determine i. It then checks the latest possi-ble time interval x the sender could currently bein (based on the loosely synchronized clock). Ifx < i+d (recall that d is the key disclosure delay,or number of intervals that the key disclosure isdelayed), then the packet is safe. The sender hasthus not yet reached the interval where it discloseskey Ki, the key that will verify packet Pj .

The receiver cannot yet verify the authenticityof packet Pj sent in interval i. Instead, it addsthe triplet (i,Mj ,MAC(K ′

i,Mj)) to a buffer, andverifies the authenticity after it learns K ′

i.

8

Pj Pj+1 Pj+2 Pj+3 Pj+4 Pj+5 Pj+6

Ki−1 Ki Ki+1 Ki+2

K′i−1 K′

i K′i+1 K′

i+2

F (Ki) F (Ki+1) F (Ki+2) F (Ki+3)

F ′(Ki−1) F ′(Ki) F ′(Ki+1) F ′(Ki+2)

Interval i − 1 Interval i Interval i + 1 Interval i + 2 time

Figure 3: At the top of the figure is the one-way key chain (using the one-way function F ), and thederived MAC keys (using the one-way function F ′). Time advances left-to-right, and the time is splitinto time intervals of uniform duration. At the bottom of the figure, we can see the packets that thesender sends in each time interval. For each packet, the sender uses the key that corresponds to thetime interval to compute the MAC of the packet. For example for packet Pj+3, the sender computes aMAC of the data using key K ′

i+1. Assuming a key disclosure delay of two time intervals (d = 2), packetPj+3 would also carry key Ki−1.

What does a receiver do when it receives thedisclosed key Ki? First, it checks whether it al-ready knows Ki or a later key Kj (j > i). IfKi is the latest key received to date, the receiverchecks the legitimacy of Ki by verifying, for someearlier key Kv (v < i) that Kv = F i−v(Ki). Thereceiver then computes K ′

i = F ′(Ki) and verifiesthe authenticity of packets of interval i, and ofprevious intervals if the receiver did not yet re-ceive the keys for these intervals (the receiver canderive them from Ki).

Note that the security of TESLA does not relyon any assumptions on network propagation de-lay, since each receiver locally determines thepacket safety, i.e. whether the sender disclosedthe corresponding key. However, if the key dis-closure delay is not much longer than the networkpropagation delay, the receivers will find that thepackets are not safe.

4 Discussion

4.1 TESLA Security Considerations

The security of TESLA relies on the following as-sumptions:

• The receiver’s clock is time synchronized upto a maximum error of ∆. (We suggestthat because of clock drift, the receiver pe-riodically re-synchronizes its clock with thesender.)

• The functions F,F ′ are secure PRFs, and thefunction F furthermore provides weak colli-sion resistance.4

As long as these assumptions are satisfied, itis computationally intractable for an attacker toforge a TESLA packet that the receivers will au-thenticate successfully.

4See our earlier paper for a formal security proof [28].

9

4.2 Achieving Asymmetric Security Proper-ties with TESLA

Broadcast authentication requires an asymmetricprimitive, which TESLA provides through looselysynchronized clocks and delayed key disclosure.TESLA shares many common properties withasymmetric cryptographic mechanisms. In fact,assuming that all nodes in a network are time syn-chronized, any key of the key chain serves as a keychain commitment and is similar to a public key ofa digital signature: any loosely time synchronizedreceiver with an authentic key chain commitmentcan authenticate messages, but not forge a mes-sage with a MAC that receivers would accept.

We can construct an efficient PKI based solelyon TESLA. Consider an environment with n com-municating nodes. We assume that all nodes areloosely time synchronized, such that the maxi-mum clock offset between any two nodes is ∆; andthat all nodes know the authentic key chain com-mitment and key disclosure schedule of the certi-fication authority (CA). We further assume thatthe CA knows the authentic key chain commit-ment and key disclosure schedule of every node.If a node A wants to start authenticating packetsoriginating from another node B, A can contactthe CA for B’s key chain commitment and keydisclosure schedule, which the CA sends authen-ticated with its TESLA instance. After the CAdiscloses the corresponding key, A can authenti-cate B’s TESLA parameters and subsequently au-thenticate B’s packets.

Note that TESLA is not a signature mecha-nism and does not provide non-repudiation, asanybody could forge “authentic” TESLA packetsafter the key is disclosed. However, in conjunctionwith a trusted time stamping mechanism, TESLAcould achieve properties similar to a digital signa-ture. Consider this setup: all nodes in the network

are loosely time synchronized (as above with anupper bound on the synchronization error); andall nodes in the network trust the time stamp-ing server [6, 15, 23]. The time stamping servertimestamps all TESLA packets it receives. Thetime stamping server can broadcast the hooks tothe trust chain authenticated with its TESLA in-stance. A judge who wants to verify that a sendersent packet P performs the following operations:

1. Receive the current value of the time stamp-ing server’s trust chain, ensure that it is safe,and wait for the TESLA key to authenticateit.

2. Based on the trust chain value, verify thatpacket P is part of the trust chain.

3. Verify that packet P was safe when the timestamping server received it (not necessary ifthe time stamping server only timestampssafe packets).

4. Retrieve key from the sender and verify itusing the key chain commitment and disclo-sure schedule recorded by the time stampingserver.

5. Verify that the authenticity of the packet,which implies that the correct sender musthave generated the packet.

TESLA and a time stamping server can thusachieve non-repudiation. This example also showsthat the TESLA authentication can also be per-formed after the key is already disclosed, as longas the verifier can check that the packet arrivedsafely.

10

5 Acknowledgments

We gratefully acknowledge funding support forthis research. This research was sponsored in partthe United States Postal Service (contract USPS102592-01-Z-0236), by the United States DefenseAdvanced Research Projects Agency (contractN66001-99-2-8913), and by the United States Na-tional Science Foundation (grants 99-79852 and01-22599). DARPA Contract N66001-99-2-8913is under the supervision of the Space and NavalWarfare Systems Center, San Diego.

The views and conclusions contained in thisdocument are those of the author and should notbe interpreted as representing official policies, ei-ther expressed or implied, of the United Statesgovernment, of DARPA, NSF, USPS, any of itsagencies.

References

[1] R. Anderson, F. Bergadano, B. Crispo,J. Lee, C. Manifavas, and R. Needham. Anew family of authentication protocols. ACMOperating Systems Review, 32(4):9–20, Oc-tober 1998.

[2] F. Bergadano, D. Cavagnino, and B. Crispo.Chained stream authentication. In SelectedAreas in Cryptography, 7th Annual Interna-tional Workshop, SAC 2000, volume 2012 ofLecture Notes in Computer Science, pages144–157, August 2000.

[3] F. Bergadano, D. Cavalino, and B. Crispo.Individual single source authentication onthe mbone. In ICME 2000, Aug 2000.

[4] D. Boneh, G. Durfee, and M. Franklin. Lowerbounds for multicast message authentication.In Advances in Cryptology — EUROCRYPT

’2001, volume 2045 of Lecture Notes in Com-puter Science, pages 434–450, 2001.

[5] B. Briscoe. FLAMeS: Fast, Loss-TolerantAuthentication of Multicast Streams.Technical report, BT Research, 2000.http://www.labs.bt.com/people/briscorj/papers.html.

[6] A. Buldas, P. Laud, H. Lipmaa, andJ. Villemson. Time-stamping with binarylinking schemes. In Advances in Cryptol-ogy — CRYPTO ’98, volume 1462 of LectureNotes in Computer Science, pages 486–501,1998.

[7] R. Canetti, J. Garay, G. Itkis, D. Miccian-cio, M. Naor, and B. Pinkas. Multicast se-curity: A taxonomy and some efficient con-structions. In INFOCOMM’99, pages 708–716, March 1999.

[8] S. Cheung. An efficient message authen-tication scheme for link state routing. In13th Annual Computer Security ApplicationsConference, pages 90–98, 1997.

[9] D. Coppersmith and M. Jakobsson. Almostoptimal hash sequence traversal. In Pro-ceedings of the Fourth Conference on Finan-cial Cryptography (FC ’02), Lecture Notes inComputer Science, 2002.

[10] Y. Desmedt and Y. Frankel. Shared genera-tion of authenticators and signatures. In Ad-vances in Cryptology — CRYPTO ’91, vol-ume 576 of Lecture Notes in Computer Sci-ence, pages 457–469, 1992.

[11] Y. Desmedt, Y. Frankel, and M. Yung. Multi-receiver / multi-sender network security: Ef-ficient authenticated multicast / feedback. InProceedings IEEE Infocom ’92, pages 2045–2054, 1992.

11

[12] Y. Desmedt and M. Yung. Arbitrated un-conditionally secure authentication can beunconditionally protected against arbiter’sattacks. In Advances in Cryptology —CRYPTO ’90, volume 537 of Lecture Notesin Computer Science, pages 177–188, 1991.

[13] F. Fujii, W. Kachen, and K. Kurosawa. Com-binatorial bounds and design of broadcastauthentication. IEICE Transactions, E79-A(4):502–506, 1996.

[14] R. Gennaro and P. Rohatgi. How to sign dig-ital streams. In Advances in Cryptology —CRYPTO ’97, volume 1294 of Lecture Notesin Computer Science, pages 180–197, 1997.

[15] S. Haber and W. Stornetta. How to time-stamp a digital document. In Advances inCryptology — CRYPTO ’90, volume 537 ofLecture Notes in Computer Science, pages437–455, 1991.

[16] N. Haller. The S/Key one-time passwordsystem. In Proceedings of the Symposiumon Network and Distributed Systems Secu-rity, pages 151–157. Internet Society, Febru-ary 1994.

[17] H. Holbrook and D. Cheriton. IP multicastchannels: EXPRESS support for large-scalesingle-source applications. In Proceedings ofACM SIGCOMM ’99, September 1999.

[18] Y.-C. Hu, A. Perrig, and D. B. Johnson.Ariadne: A secure on-demand routing pro-tocol for ad hoc networks. In Proceedingsof the Eighth ACM International Conferenceon Mobile Computing and Networking (Mo-bicom 2002), September 2002. To appear.

[19] M. Jakobsson. Fractal hash sequence repre-sentation and traversal. In Proceedings of the2002 IEEE International Symposium on In-formation Theory (ISIT ’02), pages 437–444,July 2002.

[20] K. Kurosawa and S. Obana. Characteriza-tion of (k,n) multi-receiver authentication.In Proceedings of the 2nd Australasian Con-ference on Information Security and Privacy(ACISP ’97), volume 1270 of Lecture Notesin Computer Science, pages 205–215, 1997.

[21] L. Lamport. Password authentication withinsecure communication. Communications ofthe ACM, 24(11):770–772, November 1981.

[22] L. Lamport and P. Melliar-Smith. Synchro-nizing clocks in the presence of faults. Jour-nal of the ACM, 32(1):52–78, 1985.

[23] H. Lipmaa. Secure and Efficient Time-Stamping Systems. PhD thesis, Departmentof Mathematics, University of Tartu, Esto-nia, April 1999.

[24] D. Mills. Network Time Protocol (version 3)specification, implementation and analysis.Internet Request for Comment RFC 1305, In-ternet Engineering Task Force, March 1992.

[25] S. Miner and J. Staddon. Graph-based au-thentication of digital streams. In Proceed-ings of the IEEE Symposium on Researchin Security and Privacy, pages 232–246, May2001.

[26] Multicast security ietf working group(msec). http://www.ietf.org/html.charters/msec-charter.html, 2002.

[27] A. Perrig, R. Canetti, D. Song, and J. D.Tygar. Efficient and secure source authen-tication for multicast. In Proceedings of theSymposium on Network and Distributed Sys-tems Security (NDSS 2001), pages 35–46. In-ternet Society, February 2001.

[28] A. Perrig, R. Canetti, J. D. Tygar, andD. Song. Efficient authentication and signa-ture of multicast streams over lossy channels.

12

In Proceedings of the IEEE Symposium onResearch in Security and Privacy, pages 56–73, May 2000.

[29] A. Perrig, R. Szewczyk, V. Wen, D. Culler,and J. D. Tygar. SPINS: Security proto-cols for sensor networks. In Proceedings ofSeventh Annual International Conference onMobile Computing and Networks (Mobicom2001), pages 189–199, 2001.

[30] A. Perrig and J. D. Tygar. Security Protocolsfor Broadcast Networks. Kluwer AcademicPublishers, 2002. To appear.

[31] M. Reiter. A security architecture for fault-tolerant systems. PhD thesis, Departmentof Computer Science, Cornell University, Au-gust 1993.

[32] M. Reiter, K. Birman, and R. van Renesse.A security architecture for fault-tolerant sys-tems. ACM Transactions on Computer Sys-tems, 12(4):340–371, November 1994.

[33] P. Rohatgi. A compact and fast hybrid sig-nature scheme for multicast packet. In Pro-ceedings of the 6th ACM Conference on Com-puter and Communications Security, pages93–100, November 1999.

[34] R. Safavi-Naini and H. Wang. New resultson multireceiver authentication codes. In Ad-vances in Cryptology — EUROCRYPT ’98,volume 1403 of Lecture Notes in ComputerScience, pages 527–541, 1998.

[35] R. Safavi-Naini and H. Wang. Multireceiverauthentication codes: Models, bounds, con-structions and extensions. Information andComputation, 151(1/2):148–172, 1999.

[36] G. Simmons. A cartesian product construc-tion for unconditionally secure authentica-tion codes that permit arbitration. Journalof Cryptology, 2(2):77–104, 1990.

[37] B. Simons, J. Lundelius-Welch, andN. Lynch. An overview of clock syn-chronization. In B. Simons and A. Spector,editors, Fault-Tolerant Distributed Com-puting, number 448 in LNCS, pages 84–96,1990.

[38] D. Song, D. Zuckerman, and J. D. Tygar.Expander graphs for digital stream authen-tication and robust overlay networks. InProceedings of the IEEE Symposium on Re-search in Security and Privacy, pages 258–270, May 2002.

[39] C. Wong and S. Lam. Digital signatures forflows and multicasts. In IEEE ICNP ‘98,1998.

[40] Source-Specific Multicast IETF work-ing group (SSM). http://www.ietf.org/html.charters/ssm-charter.html, 2002.

13

Forward-Secure Signatures with Optimal Signing and Verifying

Gene Itkis Leonid ReyzinBoston University Computer Science Dept.

111 Cummington St.Boston, MA 02215, USA{itkis,reyzin}@bu.edu

Abstract

Ordinary digital signatures have an inherent weakness:if the secret key is leaked, then all signatures, even theones generated before the leak, are no longer trustwor-thy. Forward-secure digital signatures were proposedby Anderson [4] and formalized by Bellare and Miner[8] to address this weakness.

We describe the concept of forward security, as wellas the first forward-secure signature scheme for whichboth signing and verifying are as efficient as for one ofthe most efficient ordinary signature schemes (Guillou-Quisquater [14]), each requiring just two modular ex-ponentiations with a short exponent.

1 Introduction

Limitations of Digital Signatures. Ordinary dig-ital signatures have a fundamental limitation: ifthe secret key of a signer is compromised, all thesignatures (past and future) of that signer be-come suspect. Even though the signer might knowwhich signatures were issued by her and which bythe imposter (who used the stolen key), there isno way for the verifier to distinguish them.

Thus upon such a secret key compromise, thesigner should revoke her public key, and ob-

tain a new one (with the corresponding non-compromised secret). But what to do with thealready issued (before the compromise — in goodfaith) signatures. Re-issuing them with the newkey is expensive or even impossible (imagine hav-ing to do this for a certification authority, or inthe absence of reliable and exhaustive records ofthe past signatures).

What is even worse, a dishonest signer may seea key compromise as a golden opportunity to re-pudiate (some) previously signed documents. Infact, she might even fake a compromise herself (forexample, by anonymously posting her secret keyon the internet and claiming to be the victim of acomputer break-in).

Frequent Rekeying. One approach to preventingthe theft of the secret key is to simply erase it—a securely erased key cannot be stolen. All thesignatures produced with it cannot later becomeinvalid. In other words, by erasing her secret key,the signer guarantees that the issued signaturesremain trustworthy for the future (assuming thatshe is certain the key was not compromised priorto erasure).

The problem with erasing the secret key, ofcourse, is that the signer can no longer producesignatures with it. With ordinary signatures, thismeans that the corresponding public key is now

14

useful only for past signatures, and a new publickey needs to be issued (and appropriately certifiedand disseminated) for the future ones. This makessuch an approach expensive and inconvenient.

Forward-Secure Signatures. The goal of forward-secure signature schemes is to provide the benefitsof frequent rekeying withouth incurring the costsof changing public keys (and associated overhead).First proposed by Anderson in [4] and formalizedby Bellare and Miner in [8], they enable the signerto frequently erase the secret key while maintain-ing the same public key. The notion of a forward-secure signature scheme is akin to the notion of“perfect forward secrecy” for key agreement [15],which protects past traffic even after long-termkeys are compromised.1

To be more precise, in a forward-secure signa-ture scheme the total time that the public keyis valid (for example, one year) is divided intoT time periods (for example, 365 days). At theend of each time period, the signer computes thenext secret key from the current one via a key up-date algorithm, and erases the current secret key.Each signature includes an essential component:the time period during which the signature is is-sued. If the time period is modified within a sig-nature, it will no longer verify. Forward-securityproperty means that even if the adversary obtainsthe current secret key, he cannot forge signaturesfor past time periods.

Applications. Consider, again, the example of asigner who issues digital credentials. Suppose shegenerated her keys on January 1, and her secretkey was compormised on July 1. If she uses an

1The “forward” in “forward security” and “forward se-crecy” is a constant source of debate. Some prefer “back-ward” since such schemes protect communications thathappened before a key compromise. In our opinion, “for-ward” is justified, because if a communicaiton occurs whenthe key is secure, then it will be protected in the future nomatter what happens with the key.

ordinary signature scheme, then she has to revokeher old public key (effective retroactively, fromJanuary 1), and reissue (with a new key) all thecredentials issued between January 1 and July 1.If, on the other hand, she uses a forward-securescheme, then she merely has to revoke her publickey from July 1 forward. The only credentials sheneeds to reissue with a new key are the ones issuedon July 1 before the key compormise was discov-ered. Essentially, the potential liability she couldincur from key compromise is greatly reduced byforward-secure signatures, from one year’s worthof signatures to only one day’s.

Now consider the example of a dishonest signerwho wants to repudiate her signatures. Repudia-tion on the basis of key compromise must be al-lowed to protect the innocent signers whose keysget stolen, because no full-proof protection existsfor secret keys (even tamper-resistant devices canbe compromised or stolen) When ordinary signa-ture schemes are used, this presents a potentialliability for signature recipients for the durationof the key activity or longer—as long as the se-cret key is around.

It is, however, quite reasonable to require sign-ers to securely erase their old keys. Thus, usinga forward-secure signature scheme, potential li-ability for the signature recipients is reduced toonly the current time period. In other words, ifa signature is received on July 1, by July 2 thesigner must have erased the secret key and can nolonger claim that that key is stolen. It is reason-able, then, to shift the liability to the signer andto disallow repudiation on July 2: failing to se-curely erase the key is deemed the signer’s fault.This, of course, assumes that the signer is ex-pected to promptly detect key compromise: if shecan reasonably demonstrate on July 2 that the keywas stolen on July 1 without her knowledge, sheshould be able to repudiate the signature. Thisbrings us to our next topic.

15

Implicit Assumptions. As seen above, secure era-sure of the old secret keys (and all the intermedi-ate results of any computations involving them) iscrucial for all forward-secure schemes. As is well-known, this assumption may present serious chal-lenges in the implementation: one has to makesure that no copies of anything sensitive are acci-dentally left unerased or are recoverable from harddisks and other storage devices ([10] addresses thisproblem).

Similarly, we relied on signer’s ability to de-tect compromises. Just like in regular signatureschemes, the sooner the determination is madeand key revoked, the less damage the adversarycan do. In particular, if forward-secure signa-tures are used to deter repudiation, the signerhas to be provided with the means to detect key-compromise (otherwise, the signer can repudiatea signature by claiming she did not know that keycompromise had occurred). This can be accom-plished with the use of tamper-evident devices,which are much easier to build than tamper-proofones (evidence of tampering may often be ob-tained from external indicators, such as broken-inoffice, a lost laptop, etc.)

Finally, we relied on the verifier’s ability tocheck that the signature has the correct time pe-riod, and that the public key is valid during thattime period. This assumes some synchronizationbetween the signer and the verifier (and possiblythe outside arbiter, if one exists). This assump-tion may present a problem for small devices with-out autonomous clocks, especially when the timeperiod is short. If a signature is “post dated,”(e.g., issued on July 1 but dated July 10), thenthe signer has more time to repudiate it based ona claim of key compromise (in the example above,10 days).

We note that a time period need not actuallycorrespond to physical time. For example, it can

correspond to a particular number of signatures.A bank may require the signer to update the keyafter signing each check, to make sure that eachindividual check cannot be repudiated. Becausethe bank (presumably) knows how many checkshave been issued, both parties can agree on whatthe correct “time” (in this case, check number) is.

Forward-Secure Schemes. Known forward-securesignature schemes can be divided into two cate-gories: those that use arbitrary ordinary signa-ture schemes in a black-box manner, and thosethat modify some specific signature scheme.

In the first category, the forward-secure schemesuse some method in which a master public keyis used to certify (perhaps via a chain of certifi-cates or a Merkle tree) the current public key fora particular time period. Usually, these schemesrequire increases in storage space by noticeablefactors in order to maintain the current (public)certificates and the (secret) keys for issuing futurecertificates. They also require longer verificationtimes than ordinary signatures do, because theverifier needs to verify the entire certificate chainin addition to verifying the actual signature on themessage. The first such scheme was proposed byBellare and Miner [8]. Significant improvementswere proposed by Krawczyk [21] and by Malkin,Micciancio and Miner [22]. The resulting schemesare quite competitive; exact comparison is madedifficult by the multitude of implementation op-tions available—most importantly, by the choiceof the underlying ordinary signature scheme.

In the second category, there are four knownschemes, each based on a different ordinary sig-nature scheme: the scheme of Bellare and Miner[8] based on the Fiat-Shamir [11], the schemeof Abdalla and Reyzin [2] based the 2t-th root[24, 25, 23], the scheme of Itkis and Reyzin [16]based on Guillou-Quisquater [14], and the schemeof Kozlov and Reyzin [20] based on the ideas of

16

[12, 6, 27]. Of these, the scheme of [16] has mostefficient signing and verifying algorithms: each re-quire just two exponentiations with a short expo-nent, just like the underlying ordinary signaturescheme.2 Moreover, it has short secret and pub-lic keys, and requires no additional storage. Wetherefore present it in detail below. More intu-ition and formal proofs can be found in [16].

Further Reading. The seminal paper on forward-secure signatures by Bellare and Miner [8] con-tains an excellent discussion as well as formaldefinitions of the concept. Other forward-securesignature schemes [21, 22, 20] may offer advan-tages depending on the relative importance ofthe speeds and sizes of various components. Thework [3] contains a good exposition of techniquesused to prove security of many forward-secure sig-natures. Some extensions of the forward-securemodel are considered in [1, 27, 18]. Forward-secure encryption is addressed in [19].

2 Construction

2.1 Guillou-Quisquater Signatures

In [14], Guillou and Quisquater proposed the fol-lowing three-round identification scheme. Let kand l be two security parameters (reasonable val-ues ranges are 1024–2048 and 128–160, respec-tively). The prover’s secret key consists of a k-bit modulus n (a product of two random primesp1, p2), an (l + 1)-bit exponent e that is relativelyprime to φ(n) = (p1 − 1)(p2 − 1), and a randoms ∈ Z∗

n. The public key consists of n, e and vwhere v = 1/se mod n.

In the first round, the prover generates a ran-dom r ∈ Z∗

n, computes the commitment y = re

2This scheme was further extended to an intrusion-resilient scheme [17], which provides much stronger guar-antees of protecting not only the past but also the future.

(mod n) and sends y to the the verifier. In thesecond round, the verifier sends a random l-bitchallenge σ to the prover. In the third round, theprover computes and sends to the verifier z = rsσ.To check, the verifier computes y′ = zevσ andchecks if y = y′ (and y �≡ 0 (mod n)).

The standard transformation of Fiat andShamir [11] can be applied to this identificationscheme to come up with the GQ signature scheme,presented in Figure 1. Essentially, the interactiveverifier’s l-bit challenge σ is now computed using acryptographic hash function H : {0, 1}∗ → {0, 1}l(such as SHA-1) applied to the message M andthe commitment y.

The scheme’s security is based on the assump-tions that computing roots modulo composite nis infeasible without knowledge of its factors, andthat H acts like a “random oracle.”

2.2 Making it Forward-Secure

Main Idea. We combine the GQ scheme withShamir’s [26] observation that roots of differentdegrees are essentially independent, as long as thedegrees are relatively prime. In other words, in-stead of just using s (which is a root of 1/v ofdegree e), the signer will simply use roots of 1/vof different degrees in different time periods. Itcan be proven that knowing the secret for onetime period does not help sign in another timeperiod—this will be the basis for forward security.

More precisely, let e1, e2, . . . , eT be distinctintegers, all greater than 2l, all pairwise rela-tively prime and relatively prime with φ(n). Lets1, s2, . . . , sT be such that sei

i ≡ 1/v (mod n) for1 ≤ i ≤ T . In time period i, the signer will simplyuse the GQ scheme with the secret key (n, si, ei)and the verifier will use the GQ scheme with thepublic key (n, v, ei).

17

algorithm GQ.key(k, l)Generate random �k/2�-bit

primes p1, p2

n← p1p2

sR← Z∗

n

eR← [2l, 2l+1)s.t. gcd(e, φ(n)) = 1

v ← 1/se mod nSK ← (n, s, e)PK ← (n, v, e)return (SK ,PK )

algorithm GQ.sign(M, (n, s, e))r

R← Z∗n

y ← re mod nσ ← H(y,M)z ← rsσ mod nreturn (z, σ)

algorithm GQ.ver(M, (n, v, e), (z, σ))if z ≡ 0 (mod n) then return 0y′ ← zevσ mod nif σ = H(y′,M) then return 1

else return 0

Figure 1: The GQ Signature Scheme

This idea is quite simple. However, we still needto address the following two issues: (i) how thesigner computes the si’s, and (ii) how both thesigner and the verifier obtain the ei’s.

Computing si’s. Notice that if the signer wererequired to store all the si’s, this scheme wouldrequire secret storage that is linear in T . How-ever, this problem can be easily resolved. Letfi = ei · ei+1 · . . . · eT . Let s[i,T ] be such thatsfi

[i,T ] ≡ 1/v (mod n). During the j-th time pe-riod, the signer stores sj and s[j+1,T ]. At update

time, the signer computes sj+1 = sfj+2

[j+1,T ] mod n

and s[j+2,T ] = sej+1

[j+1,T ] mod n. This allows secretstorage that is independent of T : only two valuesmodulo n are stored at any time (the fi and ei val-ues are not stored—see below). It does, however,require computation linear in T at each update,because of the high cost of computing sj+1 froms[j+1,T ].

We can reduce the computation at each updateto be only logarithmic in T by properly utilizingprecomputed powers of s[j+1,T ]. This will require

us, however, to store 1 + log2 T secrets insteadof just two. This optimization concerns only theefficiency of the update algorithm and affects nei-ther the other components of the scheme nor thesecurity, and is therefore presented separately inSection .

Obtaining ei’s. In order for the scheme to besecure, the ei’s need to be relatively prime witheach other and with φ(n), and greater than 2l.Unlike in the GQ scheme, where the single valuee is included in the public key, we do not want toinclude all the ei values in the public key, becausethis will lengthen the key too much (by T (l + 1)bits). Therefore, we simply require the signer toinclude the correct ei value in the signature. Al-though a forger may attempt to use an incorrect ei

value in a forgery, this is not a problem: it can beproven that forgery for time period i is impossiblefor any e value, as long as it is guaranteed to berelatively prime with the values ei+1, ei+2, . . . , eT .

The last conditions can be verified in a numberof different ways. The simplest is to divide theentire space of l + 1-bit integers into T intervals

18

(the i-th interval is the set of integers between2l(1+(i−1)/T ) and 2l(1+i/T ))), and pick each ei

as prime from the i-th interval. Then the verifiersimply needs to check that the alleged ei in thesignature is indeed in the correct interval—it isthen guaranteed to be relatively prime with thevalues ei+1, ei+2, . . . , eT (because they are primesgreater than the alleged ei value). Note that theverifier need not perform any primality testing.

The signer need not store all the ei’s. Only theone for the current time period is needed for sign-ing. The ones for future periods are needed duringthe key update procedure only. They can be re-covered as needed; the signer need simply storeenough information to be able to recover them.In most applications, it is probably simplest togenerate each ei as the first prime after the begin-ning of the i-th interval, i.e., the first prime after2l(1 + (i− 1)/T ). Then one can either regenerateei’s from scratch, or, if some of storage is avail-able, store the short offset between the beginningof the interval, 2l(1 + (i− 1)/T , and the ei valueitself. We note that as l is about 128, (l + 1)-bitprimes should be quick to generate.

The resulting scheme is presented in Figure 2.Note that, to ensure that each ei is relativelyprime with φ(n), we simply use “safe” primesas factors of n: i.e., primes p1 and p2 such thatp1 = q1 + 1 and p2 = q2 + 1, where q1 and q2

are themselves prime. Then φ(n) = 4q1q2, andhas only two odd prime factors. One can relaxthe condition: instead of having p1 and p2 be safeprimes, we can simply require that p1−1 and p2−1have no odd prime factors of size less than 2l+1.This will speed up key generation.

The scheme is provably forward-secure basedon the so-called “strong RSA” assumption [7, 12].The assumption is that it is hard to extract a rootof v modulo n of any degree between 2 and 2l+1).The proof, given in [16], is in the random oracle

model [9]: it assumes that the hash function Hbehaves like a random function.

Other methods for obtaining ei’s. The followingother methods for finding ei’s offer potential ben-efits to the signer at a small cost to the verifier.

If both the signer and the verifier have readilyavailable access to a table of first T odd primes(which is particularly plausible if T is small), theneach ei can be simply picked as a power if thei-th prime. In other words, if we let εi be thei-th odd prime (starting our counting at ε1 = 3,ε2 = 5, . . . ), we can let ei = εαi

i , where αi is a largeenough value to ensure that ei > 2l (for example,αi = llog2 εi).

The algorithms would change as follows: thekey generation and update algorithms would nowgenerate ei as εαi

i , and would therefore to have toperform any primality testing on ei’s. The sign-ing algorithm would remain the same, but wouldnot need to output ej as part of the signature,thus shortening the signature. The verificationalgorithm, instead of obtaining ej from the signa-ture and verifying that it is in the correct inverval,would simply have to compute ej directly as ε

αj

j .

Yet another method is available if the table ofsmall primes is inconvenient for a particular ap-plication. Let S be some small integer value (tobe explained shortly), and let εi be a first primein the interval [(i − 1)S, iS). Again, let ei = εαi

i ,where αi is a large enough value to ensure thatei > 2l. S needs to be picked large enough toguarantee that there exists at least one prime ineach interval [(i − 1)S, iS) for 1 ≤ i ≤ T . Forexample, S = 34 will work for T = 1024, becausethe largest gap between the first 1024 primes is34; by the same reasoning, S = 72 will work forT = 104, S = 114 will work for T = 105, andS = 154 will work for T = 220 > 106.

19

algorithm IR.key(k, l, T )Generate random �k/2�-bit safe primes p1, p2: generate primes q1, q2, s.t. pi ← 2qi+1 are primen← p1p2

s[1,T ]R← Z∗

n

Generate primes e1, . . . , eT s.t. 2l(1 + (i− 1)/T ) ≤ ei < 2l(1 + i/T ).f2 ← e2 · . . . · eT mod φ(n), where φ(n) = 4q1q2

s1 ← sf2

[1,T ] mod n ; s[2,T ] ← se1

[1,T ] mod n

v ← 1/s1e1 mod n

SK 1 ← (n, s1, s[2,T ], e1) (n and e1 are included for convenience and need not be kept secret)PK ← (n, v, T )Securely erase all the intermediate results, leaving only SK 1,PK unerased.

In particular, q1, q2, p1, p2, φ(n) must be erased.Note that the values n and e1, . . . , eT need not be kept secret or erased.

algorithm IR.sign(M,SK j)Let SK j = (n, sj, s[j+1,T ], ej)r

R← Z∗n

y ← rej mod nσ ← H(y,M, j, ej)z ← rsj

σ mod nreturn (z, σ, j, ej)

algorithm IR.ver(M,PK , (z, σ, j, e))Let PK = (n, v, T )if e ≥ 2l(1 + j/T ) or e < 2l or e is even then return 0if z ≡ 0 (mod n) then return 0y′ ← zevσ mod nif σ = H(y′,M, j, e) then return 1 else return 0

algorithm IR.update(SK j)Let SK j = (n, sj, s[j+1,T ], ej)if j = T then return “error”Recover ej+1, . . . , eT

sj+1 ← sej+2·...·eT

[j+1,T ] mod n; s[j+2,T ] ← sej+1

[j+1,T ] mod n

SK j+1 ← (n, sj+1, s[j+2,T ], ej+1)Securely erase SK j and all the intermediate results. Leave only SK j+1 unerased.

Figure 2: Our forward-secure signature scheme (without efficiency improvements). Highlighted in redare the differences from the GQ (Fig. 1).

The algorithms would change as follows: thekey generation and update algorithms would nowfirst generate each εi as a prime from the interval[(i − 1)S, iS), and then compute ei as εαi

i . Thus,they would perform primality testing on the shortvalue εi, rather than the long value ei. The sign-ing algorithm would remain the same, but wouldoutput εj as part of the signature, instead of ej .

The verification algorithm would obtain εj fromthe signature, check that it is odd and greaterthan (j − 1)S, and compute ej as εαi

i . Note that,again, the verification algorithm would not needto perform primality testing.

20

3 Optimizing key update

The key update in our scheme requires comput-ing si such that sei

i ≡ 1/v mod n. The solutionwe used in the previous section took T − i− 1 ex-ponentiations. This computation can be reduceddramatically if the storage is increased slightly.Specifically, in this section we demonstrate howreplacing the single secret s[j,T ] with log2 T secretscan reduce the complexity of the update algorithmto only log2 T exponentiations.

Abstracting the Problem. Consider all subsets ofZT = {1, 2, . . . , T}. Let each such subset S ⊆ ZT

correspond to the secret value sS = s∏

i/∈S ei

[1,T ] . Forexample, s[1,T ] corresponds to ZT , s[i,T ] corre-sponds to {i, i+1, . . . , T}, v−1 corresponds to theempty set, and each si corresponds to the single-ton set {i}. Raising some secret value sS to powerei corresponds to dropping i from S.

Thus, instead of secrets and the exponentiationoperation, we can consider sets and the operationof removing an element. Our problem, then, canbe reformulated as follows: design an algorithmthat, given ZT , outputs (one-by-one, in order) thesingleton sets {i} for 1 ≤ i ≤ T . The only way tocreate new sets is to remove elements from knownsets. The algorithm should minimize the num-ber of element-removal operations (because theycorrespond to the expensive exponentiation oper-ations).

Pebbling. Let each subset of ZT correspond to anode in a graph. Connect two sets by a directededge if the destination can be obtained from thesource by dropping a single element. The result-ing graph is the T -dimensional hypercube, withdirections on the edges (going from higher-weightnodes to lower-weight nodes; see Fig. 3).

Figure 3: Hypercube for the subsets of {1, 2, 3, 4}.

Consider now ommitting some of the edges ofthis hypercube, together with the ∅ node corre-sponding to the value v. The resulting graphlooks much simpler (see Fig. 4) and contains allthe edges need for our algorithm.

Figure 4: Simplified tree on the non-empty sub-sets of {1, 2, 3, 4}.

Represent each set stored as a pebble at thecorresponding node in a graph. Then removingan element from a set corresponds to moving thecorresponding pebble down the corresponding di-rected edge. If the original set is preserved, thena “clone” of a pebble is left at the original node.

Our goal now can be reformulated as follows interms of pebbles: find a pebbling strategy that,starting at the node ZT , reaches every node {i}in order. Moreover, we wish to optimize this strat-egy by minimizing the following three parameters:

21

Figure 5: Pebbling the tree on the interval {1, ..., 16}. The configuration corresponds to the time whenthe first singleton {1} is output. The pebbles are at the nodes {2}; {3, 4}; {4, 5, 6, 7, 8}; and {6, ..., 16},and correspond to the four stored values s2, s[3,4], s[4,8], and s[6,16].

(a) storage requirements — the number of pebblesused at any given time; (b) total number of expo-nentiations — the total number of pebble moves;and (c) the worst-case running time of the updatealgorithm — the max number of pebble movesbetween any two consecutive hits of a singleton.

The Pebbling Algorithm. Suppose we start witha single pebble at the root of the tree. Each pebblemoves down the tree as follows. When reachinga branch (a node with two children) the pebblesplits into two siblings — one taking the left edgeand the other taking the right. The right sibling“donates” its moves to the left one, until the leftsibling reaches the next branch. Then (when theleft sibling splits again) the right pebble proceeds

down its right path. A pebble is discarded uponreaching a leaf.

Thus, left-moving pebbles always move twoedges per time period, while right-moving peb-bles stay still while their left-moving pebbles aremoving, and then move one-edge per time perioduntil the next branch (their average speed thus is2/3).

To use pebbling for key update, simply replacethe s[i+2,T ] value in the secret key with a list L ofpebbles, generated and updated according to thedetailed algorithms Figure 6. The secret si+1 isgenerated during key update from L (instead ofvia long exponentiation from s[i+2,T ]).

22

Additional Steps for IR.key:Define data structure Pebble = {s, pb, pe, rb, re}

// s is the secret that the pebble contains; the other four variables are named as follows:// “p” stands for “position,” “r” for “responsibility,” “b” for “begin” and “e” for “end”

Let Pebble R← {s[1,T ], 1, 1, T, T}; let L be a list of Pebbles, containing the single element R

for i← −(T − 2)/2 to 0PebbleStep(L)

New Steps for IR.update (instead of modular exponentiations):PebbleStep(L)Remove the first element of L; its s value is sj+1 to be put into SK j+1

Procedure PebbleStep(L)for each Pebble P in L, in order

if P.pb = P.pe do nothing // Pebble doesn’t move because it is at destinationelse if P.pb = P.rb then MoveLeft(P ) // Move left twice, unless you hit bottom after first move

if P.pb �= P.pe then MoveLeft(P ) and skip over the next pebble in Lelse MoveRight(P )

Procedure MoveLeft(P )if P.pe = P.re // Need to split this pebble into two

Create a new Pebble P1, and insert it into L immediately following PP1.s← P.s, P1.pb ← P.pb, P1.pe ← P.pe , P1.re ← P.re, P1.rb ← (P.rb + P.re + 1)/2P.re ← (P.rb + P.re − 1)/2

P.s← P.sepe mod n; P.pe ← P.pe − 1

Procedure MoveRight(P )P.s← P.sepb mod n; P.pb ← P.pb + 1

Figure 6: Pebbling techniques to speed up key update

In [16] we prove that this strategy guaranteesthat at any moment there are at most 1 + log2 Tpebbles and that all the pebbles always arrive atthe leaves at the right times. The amount of stepsin any time period does not exceed log2 T .

We also show that using pebbling does not com-promise security, because none of the secrets con-tained in the pebbles can assist the adversary inforging past signatures (in fact, all the secrets inthe pebbles at time period i can be derived froms[i,T ]).

23

References

[1] Michel Abdalla, Sara Miner, and ChanathipNamprempre. Forward-secure threshold sig-nature schemes. In David Naccache, ed-itor, Progress in Cryptology — CT-RSA2001, volume 2020 of Lecture Notes inComputer Science, pages 143–158. Springer-Verlag, April 8-12 2001.

[2] Michel Abdalla and Leonid Reyzin. Anew forward-secure digital signature scheme.In Tatsuaki Okamoto, editor, Advancesin Cryptology—ASIACRYPT 2000, volume1976 of Lecture Notes in Computer Science,pages 116–129, Kyoto, Japan, 3–7 December2000. Springer-Verlag. Full version availablefrom the Cryptology ePrint Archive, record2000/002, http://eprint.iacr.org/.

[3] Jee Hea An, Michel Abdalla, MihirBellare, and Chanathip Namprempre.From identification to signatures viathe Fiat-Samir transform: Minimizingassumptions for security and forward-security. Available from http://www-cse.ucsd.edu/users/mihir/papers/id-sig.html.

[4] Ross Anderson. Invited lecture. Fourth An-nual Conference on Computer and Commu-nications Security, ACM; summary appearsin [5], 1997.

[5] Ross Anderson. Two re-marks on public key cryptology.http://www.cl.cam.ac.uk/users/rja14/,2001.

[6] Giuseppe Ateniese, Jan Camenisch, MarcJoye, and Gene Tsudik. A practical and prov-ably secure coalition-resistant group signa-ture scheme. In Mihir Bellare, editor, Ad-vances in Cryptology—CRYPTO 2000, vol-

ume 1880 of Lecture Notes in Computer Sci-ence, pages 255–270. Springer-Verlag, 20–24 August 2000.

[7] Niko Baric and Birgit Pfitzmann. Collision-free accumulators and fail-stop signa-ture schemes without trees. In WalterFumy, editor, Advances in Cryptology—EUROCRYPT 97, volume 1233 of LectureNotes in Computer Science, pages 480–494.Springer-Verlag, 11–15 May 1997.

[8] Mihir Bellare and Sara Miner. Aforward-secure digital signature scheme.In Michael Wiener, editor, Advances inCryptology—CRYPTO ’99, volume 1666of Lecture Notes in Computer Science,pages 431–448. Springer-Verlag, 15–19 Au-gust 1999. Revised version is available fromhttp://www.cs.ucsd.edu/˜mihir/.

[9] Mihir Bellare and Phillip Rogaway. Ran-dom oracles are practical: A paradigm fordesigning efficient protocols. In Proceedingsof the 1st ACM Conference on Computerand Communication Security, pages 62–73,November 1993. Revised version appears inhttp://www.cs.ucsd.edu/˜mihir/.

[10] Giovanni Di Crescenzo, Niels Ferguson, Rus-sell Impagliazzo, and Markus Jakobsson.How to forget a secret. In STACS ’99: 16thAnnual Symposium on Theoretical Aspectsin Computer Science, volume 1563 of LectureNotes in Computer Science. Springer-Verlag,March 1999.

[11] Amos Fiat and Adi Shamir. How toprove yourself: Practical solutions to iden-tification and signature problems. In An-drew M. Odlyzko, editor, Advances inCryptology—CRYPTO ’86, volume 263 ofLecture Notes in Computer Science, pages186–194. Springer-Verlag, 1987, 11–15 Au-gust 1986.

24

[12] Eiichiro Fujisaki and Tatsuaki Okamoto. Sta-tistical zero knowledge protocols to provemodular polynomial relations. In Burton S.Kaliski Jr., editor, Advances in Cryptology—CRYPTO ’97, volume 1294 of Lecture Notesin Computer Science, Springer-Verlag, 1997.

[13] Shafi Goldwasser, editor. Advances inCryptology—CRYPTO ’88, volume 403of Lecture Notes in Computer Science.Springer-Verlag, 1990, 21–25 August 1988.

[14] Louis Claude Guillou and Jean-JacquesQuisquater. A “paradoxical” indentity-based signature scheme resulting from zero-knowledge. In Goldwasser [13], pages 216–231.

[15] C. Gunther. An identity-based key-exchangeprotocol. In G. Brassard, editor, Ad-vances in Cryptology—CRYPTO ’89, volume435 of Lecture Notes in Computer Science.Springer-Verlag, 1990, 20–24 August 1989.

[16] Gene Itkis and Leonid Reyzin. Forward-secure signatures with optimal signing andverifying. In Joe Kilian, editor, Advancesin Cryptology—CRYPTO 2001, volume 2139of Lecture Notes in Computer Science,pages 332–354. Springer-Verlag, 19–23 Au-gust 2001.

[17] Gene Itkis and Leonid Reyzin. SIBIR:Signer-base intrusion-resilient signa-tures. In Yung [28]. Available fromhttp://eprint.iacr.org/2002/054/.

[18] Gene Itkis and Leonid Reyzin. SIBIR:Signer-base intrusion-resilient signa-tures. In Yung [28]. Available fromhttp://eprint.iacr.org/2002/054/.

[19] Jonathan Katz. A forward-secure public-key encryption scheme. Technical Re-port 2002/060, Cryptology e-print archive,http://eprint.iacr.org, 2002.

[20] Anton Kozlov and Leonid Reyzin. Forward-secure signatures with fast key update. Un-published Manuscript, 2002.

[21] Hugo Krawczyk. Simple forward-secure sig-natures from any signature scheme. In Sev-enth ACM Conference on Computer andCommunication Security, 2000.

[22] Tal Malkin, Daniele Micciancio, and SaraMiner. Efficient generic forward-secure sig-natures with an unbounded number of timeperiods. In Advances in Cryptology—EUROCRYPT 2002, Springer-Verlag, 2002.

[23] Silvio Micali. A secure and efficient digi-tal signature algorithm. Technical ReportMIT/LCS/TM-501, Massachusetts Instituteof Technology, Cambridge, MA, March 1994.

[24] Kazuo Ohta and Tatsuaki Okamoto. A mod-ification of the Fiat-Shamir scheme. In Gold-wasser [13], pages 232–243.

[25] Heidroon Ong and Claus P. Schnorr. Fastsignature generation with a Fiat Shamir-likescheme. In I. B. Damgard, editor, Advancesin Cryptology—EUROCRYPT 90, volume473 of Lecture Notes in Computer Science,pages 432–440. Springer-Verlag, 1991.

[26] Adi Shamir. On the generation of crypto-graphically strong pseudorandom sequences.ACM Transactions on Computer Systems,1(1):38–44, February 1983.

[27] Dawn Xiaodon Song. Practical forward se-cure group signature schemes. In EighthACM Conference on Computer and Com-munication Security, pages 225–234. ACM,November 5–8 2001.

[28] Moti Yung, editor. Advances inCryptology—CRYPTO 2002, LectureNotes in Computer Science. Springer-Verlag,18–22 August 2002.

25

Attacks On RC4 and WEP

Scott FluhrerCisco Systems, Inc.,

170 West Tasman Drive,San Jose, CA 95134,sfluhrer@cisco.com

Itsik MantinComputer Science department,

The Weizmann Institute,Rehovot 76100, Israel

itsik@wisdom.weizmann.ac.il

Adi ShamirComputer Science department,

The Weizmann Institute,Rehovot 76100, Israel.

shamir@wisdom.weizmann.ac.il

Abstract

RC4 is the most widely used stream cipher in software ap-

plications. In this paper we summarize the known attacks

on RC4, and show that it is completely insecure in a natu-

ral mode of operation which is used in the widely deployed

Wired Equivalent Privacy protocol (WEP, which is part of

the 802.11b Wi-Fi standard). The new passive ciphertext-

only attack can find an arbitrarily long key in negligible

time which grows linearly (rather than exponentially) with

the key size, and it gets even faster if WEP is replaced by

its “improved” version WEP2.

1 The RC4 Stream Cipher

A large number of stream ciphers were proposedand implemented over the last twenty years. Mostof these designs were based on linear feedbackshift registers, which are easy to analyze, havegood statistical properties, and are very efficientin hardware, but are relatively slow in software.There was a clear need for a different design whichwould be more software friendly, and in 1987 RonRivest developed the RC4 stream cipher, whosesoftware implementation is extremely compactand efficient. Its design was kept a trade secretuntil 1994, when someone anonymously postedit to the Cypherpunks mailing list. RC4 is cur-rently the most widely-used stream cipher in the

world: It is used to protect Internet traffic us-ing the SSL (Secure Sockets Layer) protocol, it isintegrated into Microsoft Windows, Lotus Notes,Apple AOCE, Oracle Secure SQL, and many othersoftware applications, and it was chosen to be partof the Cellular Digital Packet Data specification.

RC4 has a secret internal state which is a per-mutation S of all the N = 2n possible n-bit values,where n is typically chosen as 8. In addition, thestate contains two indices 0 ≤ i, j < N . The ini-tial state is derived from a key (whose typical sizeis between 40 and 256 bits) by a Key-SchedulingAlgorithm (KSA), and then the pseudo-randomgeneration algorithm (PRGA) alternately modi-fies the state (by exchanging two out of the Nvalues) and produces an output (by picking oneof the N values in S). For n = 8, this gives RC4a huge state of about 1700 bits.

More specifically, the PRGA initializes i andj to 0, and then repeatedly increments i asa counter, increments j pseudo randomly (byadding the value of S pointed to by i), exchangesthe two values of S pointed to by i and j, and out-puts the value of S pointed to by S[i] + S[j]1 (seeFigure 1). Note that every entry of S is swappedat least once (possibly with itself) within any Nconsecutive rounds, and thus the permutation S

1Here and in the rest of this note all the numeric addi-tions are carried out modulo N .

26

evolves fairly rapidly during the output generationprocess.

S[i] S[j]

i jOutput

t

S[t]

2550 1

S[0]S[1]

Figure 1: RC4 PRGA Round Operation

The KSA structure is very similar to the PRGAstructure described above. It initializes S tothe identity permutation and i and j to 0, andthen applies N rounds in which i is sequentiallystepped across S, and j is updated by adding to itS[i] and the next word of the key (in cyclic order).

We denote the size of the key by �, and the n-bit RC4 variant by RC4n. The value in positionp of the permutation S is denoted by S[p]. Usingthis notation, the RC4 algorithms are specified inFigure 2.

KSA(K)Initialization:

S ← 〈0, 1, . . . , N − 1〉j ← 0

Scrambling:For i ← 0 . . . N − 1

j ← j + S[i] + K[i mod �]S[i] ↔ S[j]

PRGA(S)Initialization:

i ← 0j ← 0

Generation loop:i ← i + 1j ← j + S[i]S[i] ↔ S[j]t ← S[i] + S[j]Output z ← S[t]

Figure 2: The Key-Scheduling Algorithm and the Pseudo-

Random Generation Algorithm

2 Security Overview of RC4

Since RC4 is such a widely used stream cipher,it had attracted considerable attention in the re-search community since it was first proposed.However, so far no one had found an attack on thePRGA part of RC4 which is even close to beingpractical: For n = 8 and sufficiently long keys, the

best known attack requires more than 2700 timeto find its initial state. However, many interest-ing properties of RC4 were found over the years.Due to space limitations, these properties are onlybriefly described in this note, and a more compre-hensive overview of RC4 security, including a de-tailed description of all the published results, canbe found in [Man01].

Finney specifies in [Fin94] a class of states thatRC4 can never enter. This class contains all thestates for which i = a, j = a+1 and S[a+1] = 1 (afraction of 1/N2 of all the RC4 states are in thisclass). Analysis of states of this type indicatesthat these states are connected by short cyclesof length N(N − 1) and thus this class is closedunder the RC4 round operation. Since the statetransition in RC4 is invertible and the initial state(i = j = 0) is not of this type, RC4 can neverenter these states for any key. If RC4 could beinitialized to such a state, the generated streamwould have a very short period and its internalstates could be elegantly extracted (as noted byPudovkina and described in [Man01]).

The huge RC4 internal state is not random, andthus the size of the effective key does not properlyreflect its security. A good benchmark for the se-curity of RC4 variants is the time complexity of a“branch and bound” attack that eliminates largeclusters of internal state candidates that contra-dict the generated outputs. Such an attack is an-alyzed in [MT98] and [KMP+98], and is based onthe “guess on demand” paradigm. These attackssimulate the generation process by keeping trackof all the known permutation values and guess-ing/branching when an unknown value is neededin order to continue the simulation. The timecomplexity of this attack is analytically derivedin [KMP+98], and the results are compatible withexperimental data obtained by scaled-down simu-lations. This attack is very inefficient (i.e., worsethan exhaustive search for typical key sizes), and

27

can be carried out in practice only for RC4n≤5

(e.g. for n = 5 its time complexity is 253, but forthe common choice of n = 8 its time complexityis 2779).

Mantin and Shamir use a variant of this at-tack in [MS01] (and more extensively in [Man01]).They present some interesting classes of RC4states that make it possible to deduce several per-mutation values with high probability. Then theyuse the attack of Knudsen et al ([KMP+98]) inorder to complete the rest of the internal state.This 2-phase attack is practical for the 5-bit ver-sion. More analysis of RC4 round operation is de-scribed in [MT98]. In addition, Jenkins in [Jen98]shows a significant correlation between the secretand known parts of the RC4 state. For example,this correlation implies that given i and z, theprobability of S[i] to be their difference (i − z) istwice the expected 1/N . This correlation is ex-plained by Mantin in [Man01] as a special case ofa more general correlation.

A significant research effort is dedicated to thestatistical analysis of RC4 outputs, and in partic-ular to the construction of distinguishers betweenRC4 and truly random bit generators. Golic de-scribes in [Gol97] a linear statistical weakness ofRC4, caused by a positive correlation between thesecond binary derivative of the LSB and 1. Thisweakness implies that RC4 outputs of length 240

can be reliably distinguished from random strings.This result is further improved by Fluhrer andMcGrew in [FM00]. They analyze the distributionof triplets consisting of the two outputs producedat times t and t + 1, and the known value of i ≡ t(mod N), and notice small biases in the distribu-tion of (7N−8) of these N3 triplets: some of theseprobabilities are positively biased ( 1

N3 (1 + 1/N)),while others are negatively biased ( 1

N3 (1− 1/N)).These biases enable distinguishing between RC4and a truly random source by analyzing sequencesof about 230 output words.

Interesting as they are, all these statisticalanomalies of the RC4 PRGA have little practicalimpact on its cryptographic strength, since theydo not make it possible to derive either the plain-texts or the keys which correspond to given ci-phertexts. However, the RC4 KSA is much moreproblematic, since it was designed to be unnec-essarily simple: it initializes the secret S and jto known values, uses the key bytes in cyclic or-der to increment j, performs a single pass over S,and starts producing outputs immediately after-wards. As a result, the first few output bytes ofthe PRGA are either biased or related to some keybytes, and thus the analysis of these bytes makesit possible to attack RC4 in some modes of op-eration. The best protective mechanism againstthese attacks (which is used in some but not allimplementations of RC4) is to discard a long pre-fix of PRGA outputs after completing the KSApart. Such dummy steps (which produce no out-puts) are used in many other stream cipher de-signs, such as the A5/1 scheme which is used inGSM cellular phones and analyzed in [BSW00].

We now describe some of these prefix attackson RC4 in more detail. Roos notes in [Roo95]that for keys which have K[0] + K[1] = 0, thefirst output is equal to K[2] + 3 with probabil-ity 2−2.85. The cryptanalyst can use this fact todeduce two bytes of information about the key(K[0] + K[1] and K[2]) with probability 2−10.85

instead of the trivial 2−16, and thus reduce theeffective key length in exhaustive search by aboutfive bits.

Mantin and Shamir describe in [MS01] a majorbias in the distribution of RC4’s second outputword: it is zero with twice the expected probabil-ity of 1/N , and thus RC4 outputs can be distin-guished from random strings by analyzing about28 words of output produced by unrelated andunknown keys. In addition, this bias makes itpossible to deduce the second plaintext word in

28

many broadcast applications (such as groupwareor email) in which the same message is encryptedmultiple times under different keys. A similar biasoccurs in the first pair of output words, which areboth zero with probability of 3/N2 instead of theexpected 1/N2. The existence of the second worddistinguisher and its improved performance (com-pared to previously known distinguishers whichrequire 222 times more data) demonstrates the dif-ference between the PRGA and the KSA mecha-nisms of RC4.

Mantin in [Man01] and Mironov in [Mir02] an-alyze the distribution of KSA outputs. Both ofthem calculate, for every permutation value, thedistribution of its location in the KSA final per-mutation and show that the probability of thevalue a to end up in location b in S at the endof the KSA process is

P [S∗[b] = a] =

{p(qa + qb − qa+b) a ≤ b

p(qa + qb) a > b

where S∗ is the KSA output permutation, xdef=

N − 1 − x, p = 1/N and q = 1 − p.

In particular, the probability that value 1reaches location 0 is 37% more than the expectedprobability of 1/N , the probability that value 255reaches location 0 is 26% less than the expectedprobability, and the probability that the KSAoutput permutation is 〈1, 2, . . . , 255, 0〉 is about270 times larger than the expected probability.Mantin also shows how this analysis can be usedto connect states which are N PRGA (rather thanKSA) rounds away. In addition, he analyzes theKSA execution on short keys and shows more bi-ases, caused by the cyclic usage of short keys.

Fluhrer, Mantin and Shamir present in [FMS01]another weakness of the KSA. They identify largeclasses of weak keys, in which a small part of thesecret key determines a large number of bits in

the permutation S produced by the KSA. In ad-dition, the PRGA translates these patterns in itsinitial S into patterns in the prefix of the outputstream, and thus RC4 has the undesirable prop-erty that for these weak keys its initial outputsare disproportionally affected by a small numberof key bits. The length of these weak keys isdivisible by some non-trivial power of two, i.e.,� = 2qm for some q > 0. When RC4n uses sucha weak key of � words, fixing Θ(n + q�) bits of K(as a particular pattern) determines Θ(qN) bitsof the initial permutation with probability of onehalf and determines various prefixes of the outputstream with various probabilities (depending ontheir length). In addition, this weakness impliesthat RC4 has low sampling resistance (as definedin [BSW00]), and thus it is more vulnerable totime/memory/data tradeoff attacks.

3 802.11b and Wired Equivalent

Privacy

The IEEE 802.11 wireless network standard(which is also known as Wi-Fi) [Com99] is anextremely popular way to connect multiple PC’sat home or in the office without using cables.Since such a wireless network is very vulnerableto eavesdropping and misuse, the standard speci-fies the Wired Equivalent Privacy (WEP) encryp-tion protocol which can be used to make the se-curity of wireless communication comparable tothat of a wired network. Since its publication,the security of WEP was subjected to a continu-ous debate between its designers at the WirelessEthernet Compatibility Alliance (WECA) and thecryptographic community.

WEP uses a 40-bit secret key (which was thelargest easily exportable key when WEP was de-signed), shared between all the users and the net-work access point. For every packet, the sender

29

chooses a new 24 bit Initialization Vector (IV),and the 64-bit RC4 key is the concatenation ofthe chosen IV (occurring first) and the shared key(occurring last). Such an IV-based mode of oper-ation is commonly used in stream ciphers in or-der to generate different PRGA outputs from thesame long term key, and the frequent resetting ofthe PRGA is designed to overcome the unreliablenature of the Wireless LAN environment. In ad-dition, WEP computes a CRC-32 checksum overthe data payload, appends it to the plaintext andencrypts both parts in order to verify the integrityof the data.

Several vulnerabilities of this WEP protocolwere discovered and analyzed in the last few years.These vulnerabilities are only briefly described inthis note (see [Arb] for detailed overview of thepublished results). The simplest weakness is thesmall size of the secret key and the IV: A 40-bitkey can be recovered by an exhaustive search inless than one day. In addition, the limited size(224) of the IV space implies that IVs (and thuskey-streams) are reused during the encryption ofdifferent packets. Consequently, this mode can beattacked by constructing a dictionary of all the 224

IVs along with their corresponding key streams.In addition, WEP defines no easy mechanism forchanging the shared key, and thus the key is usu-ally changed only infrequently, increasing the at-tacker’s chance to construct this dictionary. Otherknown attacks exploit the poor authentication tospoof messages. However, these are secondary at-tacks which do not allow the attacker to derivethe key with an attack which is faster than ex-haustive search. The first “real” attack whichmakes it possible to derive an arbitrarily long keyin time which grows only linearly (rather than ex-ponentially) with its length in the weakest attackmodel of known plaintext and IV (rather than thestronger related key or chosen IV attacks) was de-veloped in [FMS01], and is outlined in the nextsection.

4 The WEP Attack

In order to carry out the attack, the cryptanalystneeds the first output word of a large number ofRC4 streams along with the IV that was used togenerate each one of them. Since in WEP theIVs are transmitted in the clear and the first mes-sage word in most packets is a known constant(see [SIR01]), these requirements are automati-cally satisfied.

Let us begin by defining our notation. To indi-cate an RC4 state after using keywords [0, . . . , r](i.e., after r + 1 rounds) during KSA we use thesubscript r in Sr, ir, jr and tr (thus the KSAoutput S∗ is also denoted SN−1). In addition,we define several functions over permutations, re-lated to applying the first PRGA round to thegiven permutation. I(S), J(S), T (S) and Z(S)are the state indices, the output index and theoutput word of the first PRGA round, given S

as an input. Thus I(S)def= 1, J(S)

def= S[1],

T (S) def= S[1]+S[S[1]] and Z(S) is usually S[T (S)](unless T (S) is I(S) or J(S)). K represents the�-word RC4 key, which is a concatenation of theinitialization vector IV (whose length is denotedby �′′) and the secret key SK (whose length isdenoted by �′).

4.1 The Basic Idea

The basic step of the attack (which we call thesub-attack) assumes knowledge of some prefix ofthe RC4 keywords, and derives the next keyword(which we sometimes denote as the target key-word). The attack starts with the known IV asa basis, and repeatedly applies the sub-attack inorder to recover all the keywords in the secret keySK.

30

The sub-attack: Let us assume that the first xwords of the KSA key are known. This makes itpossible to simulate the first x rounds of the KSAand compute the permutation Sx−1 and the in-dices ix−1 and jx−1 at that point. The next valueof i is also known (ix = x) but the next value ofj (jx) depends on the unknown target keywordK[x] (since jx = jx−1 + Sx−1[x] + K[x]) and thuseach of the values jx and K[x] can be easily de-rived from the other. Now let us concentrate onthe value Sx[x]. This value is swapped into thisposition in round x and thus it was in position jx

just before this round. Consequently, given Sx[x],we can compute which value was in position jx

in the known permutation Sx−1, and by invertingthis permutation, we can recover jx itself.

Thus the target keyword depends on jx, whichdepends on Sx[x]. The main idea of the sub-attackis to identify and isolate cases where the first out-put word (which is assumed to be known) is corre-lated with Sx[x] and thus with the target keyword.By analyzing such cases, the sub-attack uses theknown output word to guess the target keywordwith a significant success probability. This at-tack is probabilistic rather than deterministic, butit can be repeated with multiple IVs in order tomake the statistical information about the targetkeyword more robust.

4.2 The Details

We apply this attack by concentrating on cases inwhich the first output byte z has a relatively highprobability to be equal to Sx[x]. In order to createsuch a situation, we have to guarantee that:

- z is defined with high probability only by knownpermutation values.

- The most likely value of z is equal to Sx[x].

Because i scans through the permutation, thevalues that occur to the right of x at round x par-ticipate in an exchange (and are almost alwayschanged) at some later round. However, valuesthat occur to the left of x (including position x it-self) have a reasonably high probability to remainuntouched until the end of the KSA, since the in-dex j chooses N − x random values among theN possible values in the remaining rounds, andthus it misses any particular value with probabil-ity which is at least the constant e−1 (and whichgets even higher as x increases).

The first output word z is determined by onlythree permutation values (those in locations I(S),J(S) and T (S)), as illustrated in Figure 3. In

S[0]J(S)

I(S) J(S)

B Z(S)

T(S)

Figure 3: RC4 first output word

order to satisfy the first requirement, we wantI(Sx) and J(Sx) to be in positions 0, . . . , x ofSx. In order to satisfy the second requirement,we want to make sure that the index T (Sx) ofthe output word is exactly x. In other words, weare interested in cases in which 1, Sx[1] < x andSx[1] + Sx[Sx[1]] = x. When this happens we saythat the state of RC4 is in an x-resolved condi-tion, and the first output word has a high prob-ability to be Sx[x]. In addition, since the stateafter x rounds is completely determined by thefirst (known) x keywords, we can define for everyx a class of keys, which we denote as x-good keys2,which are guaranteed to lead to a x-resolved stateafter x KSA rounds (on class of such keys is de-scribed in Figure 4).

2RC4 keys, i.e., a concatenation of IVs with shared

WEP keys.

31

When an x-good key occurs, the values in po-sitions 1, S[1] and S[1] + S[S[1]] have a rela-tively high probability to remain untouched dur-ing rounds x+ 1, . . . , N − 1. The probability thatthree locations will not be pointed to by a pseudorandom index during the remaining N − 1 − xrounds is better than ((1 − 1

N )N )3 ≈ e−3 ≈ 5%.Thus, when an x-good key occurs, the outputword is equal to Sx[x] with probability of at least5%. As specified above, the target keyword canthen be guessed from the first output word zthrough the relations K[x] = jx−jx−1−Sx−1[x] =S−1

x−1[Sx[x]] − jx−1 − Sx−1[x] = S−1x−1[z] − jx−1 −

Sx−1[x]. This guess is correct with probabilitybetter than 5%, which is twelve times higher thanthe 1/256 probability of guessing an incorrectvalue for n = 8. We can thus carry out a vot-ing process, in which each x-good key votes forsome target keyword candidate, and we can iden-tify the correct keyword with probability betterthan 0.5 by examining just 60 x-good keys3.

Hence, if we know some x-prefix of the RC4key, we can derive the next keyword by analyzingonly 60 pairs of an x-good key and the first out-put word it produces. By starting with the knownIV part of the key and repeatedly using this tech-nique, we can recover the keywords one by oneuntil the whole key is extracted. The time com-plexity of the attack is negligible, and the maindifficulty in applying this attack is the collectionof sufficiently many good keys. We thus have toestimate how many (IV, z) pairs are needed in or-der to completely restore the �′-word secret keywhen it is preceeded by an �′′-word non-secret IV.

The full analysis of this issue is described in[FMS01]. As shown in that paper, the fraction

3An important observation is that x-good keys can becorrectly identified by tracking the first x KSA rounds. Ifwe had to carry out the voting process with random ratherthan good keys, the probability distribution of votes wouldhave been much flatter.

of x-good keys for n = 8 increases from 2−14.42

for x = 3 to 2−10.44 for x = 16, (the probabilityincreases with x since for large x there are moreacceptable values for J(Sx)). The number of pairsrequired for the sub-attack is 60 · 1

fraction , whichvaries between 220.32 (for x = 3) and 216.35 (forx = 16). Notice that an x1-good key is not nec-essarily x2-good, and thus the same collection of(IV, z) pairs can be used to find the 60 good pairsfor all the possible values of x. Consequently, thetotal number of pairs which are needed by thecomplete attack is the maximum, rather than thesum, of the corresponding numbers in the sub-attacks. In particular, we can attack WEP (forn = 8) with an arbitrarily long key and ran-domly chosen 3-word IVs by collecting only 220.32

(IV, z) pairs. If we modify WEP by using 16-word IVs and 16-word shared key (as used in the“improved” version which is unofficially known asWEP2), the data complexity of the attack actu-ally drops to 216.35.

Some implementations of WEP use counters(instead of randomizers) in order to generate theIVs. In order to analyze the security of such vari-ants, we introduce several classes of IVs that arelikely to lead to x-good keys. Consider for exam-ple all the IVs of the form (x, 255, V, . . .).

Figure 4 describes the state evolution when anRC4 key with such a prefix is used.

Since J(S2) = S2[1] = 0 < x and T (S2) = S2[1] +S2[S2[1]] = x, the state after 3 KSA rounds is x-resolved, and thus most keys that start with thispattern are x-good.

If the IVs are generated by a multibyte counterin little endian order (and hence the first byte ofthe IV increments the fastest), then the attackercan search for IVs of the form (x, 255, V ) for �′′ ≤x ≤ �−1 and different V s. By looking only at suchIVs the attacker gets a single good pair for every

32

x

255

V

2550 1 2

ixj

1 2 255x

j0

i

0

2 255xi

0 1

j

T(S)J(S) I(S)

K

Figure 4: First KSA rounds for keys of the structure

〈x, 255, V, . . .〉. The 1 in position x is likely to be swapped with

Sx−1[jx] during round x.

x after going through all the combinations of thefirst two words (216 pairs), and he gets 60 goodpairs after searching through at most 222 pairs.

If the IVs are generated by a multibyte counterin big endian order (and hence the last byte ofthe IV increments the fastest), then the amountof data that is required for the attack depends on�′′. For �′′ = 3 it is 216� (e.g., 220 for � = 16).However, this approach works well only for shortIVs. Other cases can be obtained by exploitingother 3-good keys (such as the (V,N − V,N − 2)and the (V,N −V +1, N −1) sets) or by guessingthe first unknown keywords and then looking forIVs that lead to a resolved permutation under theguessed assignment4.

5 Summary

Shortly after the publication of a preliminary ver-sion of [FMS01], Stubblefield, Ioannidis and Ru-bin ([SIR01]) implemented the attack and success-fully derived a 128 bit WEP key by passively ob-serving a real network during a single evening.Several optimization techniques can reduce therequired amount of data to the number of pack-ets sent on a fully loaded network in less than

4This approach is further described in [FMS01].

// This procedure recovers the key// Parameters meaning:// Pairs: a set of 〈IV, z〉 pairs,// �′′, �′: the sizes of the IV and the secret key SKAttack(Pairs, �′′, �′)

kp ← NULL // an (x − �′′)-word known prefix of SKFor x ← �′′..� − 1 // The size of the known prefix

c ← SubAttack(x, Pairs, �′, kp)kp ← kp ◦ c

Return kp

// This procedure recovers the next keyword// Parameters meaning: as in the main procedureSubAttack(x, Pairs, �′′, kp)

For Every 〈IV, z〉 ∈ PairsK ← IV ◦ prefix // Known prefix of the RC4 key[ix−1, jx−1, Sx−1] ← KSA(K,x)// Apply x KSA rounds on the key K (|K| ≥ x)If (1 < x, Sx−1[1] < x, Sx−1[1] + Sx−1[Sx−1[1]] = x)

Vote for S−1x−1[z] − jx−1 − Sx−1[x]

Return Most popular candidate

Figure 5: The pseudo-code of the attack.

15 minutes. The implications of this attack weredescribed by Ron Rivest in a tech-note that waspublished several weeks later at the RSA web site([Riv01]):“Those who are using the RC4-based WEP orWEP2 protocols to provide confidentiality of their802.11b communications should consider theseprotocols to be “broken”, and to plan remedial ac-tions as necessary to mitigate the attendant risks.Actions to be considered should include using en-cryption at higher protocol layers and upgradingto improved 802.11b standards when these be-come available”.

One proposal to modify WEP in response tothis attack is TKIP. In this proposal, the key sup-plied to the KSA is constructed by concatenatingthe 3 byte IV with a hash of the secret key and theIV. Furthermore, the IV is limited to values thattend not to form x-resolved conditions for small x,and the secret key is updated at least once every10,000 packets.

33

While we believe that the core idea of RC4 re-mains sound, we are worried about the lack of ro-bustness of the KSA process which makes the en-cryption algorithm completely insecure in severalnatural modes of operation. We recommend ei-ther a complete overhaul of the KSA part of RC4,or at least a modification which discards the firstN bytes (or more) produced by the PRGA.

References

[Arb] W. A. Arbaugh. 802.11security vulnerabilities.http://www.cs.umd.edu/∼waa/wireless.html.

[BSW00] A. Biryukov, A. Shamir, and D. Wag-ner. Real time cryptanalysis of A5/1on a PC. In FSE’2000, 2000.

[Com99] LAN/MAN Standard Comitee. Wire-less LAN medium access control(MAC) and physical layer (PHY)specifications, 1999 edition. IEEEstandard 802.11, 1999.

[Fin94] H. Finney. an RC4 cycle that can’thappen, September 1994.

[FM00] S. R. Fluhrer and D. A. McGrew. Sta-tistical analysis of the alleged RC4keystream generator. In FSE’2000,2000.

[FMS01] S. R. Fluhrer, I. Mantin, andA. Shamir. Weaknesses in the keyscheduling algorithm of RC4. InSAC’2001, 2001.

[Gol97] J. D. Golic. Linear statistical weak-ness of alleged RC4 key-stream gener-ator. In EUROCRYPT’97, 1997.

[Jen98] R. J. Jenkins. ISAAC andRC4. Technical report, 1998.http://burtleburtle.net/bob/rand/isaac.html.

[KMP+98] L. R. Knudsen, W. Meier, B. Preneel,V. Rijmen, and S. Verdoolaege. Anal-ysis methods for (alleged) RC4. InASIACRYPT’98, 1998.

[Man01] I. Mantin. The security ofthe stream cipher RC4. Mas-ter’s thesis, The Weizmann In-stitue of Science, October 2001.http://www.wisdom.weizmann.ac.il/∼itsik/RC4/thesis.html.

[Mir02] I. Mironov. (Not so) random shufflesof RC4. In Crypto’02, 2002.

[MS01] I. Mantin and A. Shamir. A prac-tical attack on broadcast RC4. InFSE’2001, 2001.

[MT98] S. Mister and S. E. Tavares. Crypt-analysis of RC4-like ciphers. InSAC’98, 1998.

[Riv01] R. Rivest. RSA security responseto weaknesses in key scheduling algo-rithm of RC4. Tech note, RSA DataSecurity, Inc, October 2001.

[Roo95] A. Roos. A class of weak keys in theRC4 stream cipher. sci.crypt posting,September 1995.

[SIR01] A. Stubblefield, J. Ioannidis, andA. D. Rubin. Using the fluhrer,mantin and shamir attack to breakWEP. Technical Report TD-4ZCPZZ,AT&T Labs, August 2001.

34

RSA Laboratories CryptobytesVolume 5, No.2 — Summer/Fall 2002

A B O U T R S A L A B O R A T O R I E S

An academic environment within a commercial organization,RSA Laboratories is the research center of RSA Security Inc.,the company founded by the inventors of the RSA public-keycryptosystem. Through its research program, standards develop-ment, and educational activities, RSA Laboratories providesstate-of-the-art expertise in cryptography and security technol-ogy for the benefit of RSA Security and its customers.

Please see www.rsasecurity.com/rsalabs for more information.

N E W S L E T T E R A V A I L A B I L I T Y A N D

C O N T A C T I N F O R M A T I O N

CryptoBytes is a free publication and all issues, both currentand previous, are available at www.rsasecurity.com/rsalabs/cryptobytes. While print copies may occasionally be distributed,publication is primarily electronic.

For more information, please contact:

cryptobytes-editor@rsasecurity.com.

©2002 RSA Security Inc. All rights reserved.

RSA and RSA Security are registered trademarks of RSA Security Inc. All other trademarks are the

property of their respective owners.

CRYPTOBYTES VOLUME 5, NO. 2, 2002