The Year in Crypto

Home , Acoustic cryptanalysis, BSAFE, Dual EC DRBG, Encryption software, Forward secrecy, Nadia Heninger

The Year in Crypto

Daniel J. Bernstein University of Illinois at Chicago Technische Universiteit Eindhoven

Nadia Heninger University of Pennsylvania

Tanja Lange Technische Universiteit Eindhoven Candidate Indistinguishability Obfuscation and Functional Encryption for all circuits

Sanjam Garg Craig Gentry Shai Halevi UCLA IBM Research IBM Research [email protected] [email protected] [email protected] Mariana Raykova Amit Sahai Brent Waters IBM Research UCLA University of Texas at Austin [email protected] [email protected] [email protected] July 21, 2013

Abstract In this work, we study indistinguishability obfuscation and functional encryption for general circuits: Indistinguishability obfuscation requires that given any two equivalent circuits C0 and C1 of similar size, the obfuscations of C0 and C1 should be computationally indistinguishable. In functional encryption, ciphertexts encrypt inputs x and keys are issued for circuits C. Using the key SKC to decrypt a ciphertext CTx = Enc(x), yields the value C(x) but does not reveal anything else about x. Furthermore, no collusion of secret key holders should be able to learn anything more than the union of what they can each learn individually. We give constructions for indistinguishability obfuscation and functional encryption that supports all polynomial-size circuits. We accomplish this goal in three steps: We describe a candidate construction for indistinguishability obfuscation for NC1 circuits. The • security of this construction is based on a new algebraic hardness assumption. The candidate and assumption use a simpliﬁed variant of multilinear maps, which we call Multilinear Jigsaw Puzzles. We show how to use indistinguishability obfuscation for NC1 together with Fully Homomorphic • Encryption (with decryption in NC1) to achieve indistinguishability obfuscation for all circuits. Finally, we show how to use indistinguishability obfuscation for circuits, public-key encryption, • and non-interactive zero knowledge to achieve functional encryption for all circuits. The functional encryption scheme we construct also enjoys succinct ciphertexts, which enables several other applications.

The first and fifth authors were supported in part from NSF grants 1228984, 1136174, 1118096, 1065276, 0916574 and 0830803, a Xerox Faculty Research Award, a Google Faculty Research Award, an equipment grant from Intel, and an Okawa Foundation Research Grant. The views expressed are those of the author and do not reflect the official policy or position of the National Science Foundation, or the U.S. Government. The second and third authors were supported by the Intelligence Advanced Research Projects Activity (IARPA) via Department of Interior National Business Center (DoI/NBC) contract number D11PC20202. The U.S. Government is authorized to reproduce and distribute reprints for Governmental purposes notwithstanding any copyright annotation thereon. Disclaimer: The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of IARPA, DoI/NBC, or the U.S. Government. The fourth author is supported by NSF Grant No.1017660. The sixth author is supported by NSF CNS-0915361 and CNS-0952692, CNS-1228599, DARPA N11AP20006, Google Faculty Research award, the Alfred P. Sloan Fellowship, Microsoft Faculty Fellowship, and Packard Foundation Fellowship.

Understanding Cryptography

mathematical problems factoring, discrete log, . . .

cryptographic primitives RSA, Diﬃe-Hellman, DSA, AES, RC4, SHA-1, . . .

protocols TLS, SSH, PGP, . . .

library implementations OpenSSL, BSAFE, NaCl, . . .

software applications Apache, Firefox, Chrome, . . . The Cryptopocalypse arXiv:1306.4244v1 [cs.CR] 18 Jun 2013 mrvmn oprdto compared improvement sotie,ornwagrtmipoe h opeiydisc complexity the fields. improves finite algorithm of range new our obtained, is exp some performed we [Jou13b], in given already heuristics hnany than opeiyfrteDPi nt edo ml characteristic small of field finite type in of DLP the for complexity ed a esle nsbxoeta ie i.e. time, subexponential progr in major solved first A be years. can 35 algorithm fields past exponential the an during From improved attention. greatly of consequence, lot wit a As together a cryptography. attracted then, key Since public h of [DH76]. a pillars Hellman as major and proposed Diffie first was of (DLP) article problem logarithm discrete The 1Introduction in ecn prah h m The approach. descent fficient e s more asymptotically the an of uses use the in o the systems ingredients polynomial field; the bilinear finite of Among resolution the algebraic degree. of extension representation the particular of root square nsalt eimcaatrsi nt ed n composite of and complexity fields a gives finite [Jou13b] characteristic algorithm medium efficient to small Cop8 on [Adl79, fields prime to fields finite characteristic fixed h etse ute eue hst heuristic a to this reduced further step next The h e etrso u loih r h following. the are • algorithm our of features key The lhuhw nito h aeo nt ed fsalcharact small of fields finite of case the on insist we Although In [Jou13b]. in used ones the to close very are heuristics The • • ntepeetwr,w rsn e iceelgrtmalgo logarithm discrete new a present we work, present the In eety rcia n hoeia rgeshv enmad been have progress theoretical and practical Recently, eke h edrpeetto n h ytmtcequation systematic the and representation field the keep We h ieridpnec fsm nt edeeet related elements field finite some probabil of smoothness independence linear the the uniformly that ex for probabilities the fact the to similar the heuristics: are polynomials key form; three appropriate on the relies result particu complexity The In elementary. are blocks algorithms. building algorithmic The n O L (log ( avnBruec,Perc ady non ox Emmanue Joux, Antoine Gaudry, Pierrick Barbulescu, Razvan ε Aq u a s i - p o l y n o m i a la l g o r i t h mf o rd i s c r e t el o g a r i t h m )for n ) where #> mrvmnsoe F nsalt eimcharacteristic medium to small in FFS over Improvements .I ean ue-oyoili h ieo h nu,bto but input, the of size the in super-polynomial remains It 0. n nfiiefilso ml characteristic small of fields finite in stebtsz ftecriaiyo h nt ed uhaco a Such field. finite the of cardinality the of bit-size the is L (1 / 4+ o (1)). L L L (1 (1 (1 1 / / / )rnigtm ntefl ag ffiiefils from fields, finite of range full the in time running 3) )where 2) 4+ niiullgrtmphase. logarithm individual o h rbe fcmuigdsrt oaihshas logarithms discrete computing of problem the rmnst aiaete npatclinstances. practical on them validate to eriments ,Gr3 d9,J0,JLSV06]. JL06, Adl94, Gor93, 4, 1)we h hrceitci mle hnthe than smaller is characteristic the when (1)) n17,tefsetDPagrtm aebeen have algorithms DLP fastest the 1976, in .B yq u a s i - p o l y n o m i a l ,w em e a nac o m p l e x i t y e[ J o u 1 3 a ,G G M Z 1 3 ,J o u 1 3 b ]w i t ha ne m p h a s i s eelgrtmcmuain namc larger much a in computations logarithm rete o-called hf a c t o r i z a t i o n ,i th a sb e c o m eo n eo ft h et w o s a h elzto htteDPi finite in DLP the that realization the was ess admplnmaso h aedge;and degree; same the of polynomials random i eutgvsa gives result ain r rbe ncytgah nteseminal the in cryptography in problem ard ft h i sa p p r o a c h ,w efi n dt h eu s eo fav e r y ereetnin.Tems eea and general most The extensions. degree L diint h ruet nfvro these of favor in arguments the to addition ih,i h aevi si Ju3]that [Jou13b] in as vein same the in rithm, rsi,weeqaiplnma complexity quasi-polynomial where eristic, sec faplnmasrpeetto of representation polynomials a of istence N oteato fPGL of action the to sof[Jou13b]. a,w vi h s fGönrbasis Gröbner of use the avoid we lar, te fsm o-nfrl distributed non-uniformly some of ities ( α )=exp ytmtcequation systematic ! O ((log quasi-polynomial r ao asymptotic major a ffers lThomé N 2 peiyi smaller is mplexity ( ) F α ;andtheuseof q lglog (log ). N heuristic ) 1 − α ) " . Fact: All the public-key crypto we use relies on three assumptions:

factoring integers into primes discrete log modulo primes discrete log in elliptic curve groups factoring discrete log modulo primes elliptic curve discrete log factoring Until December 2012:

Discrete log over small characteristic ﬁelds (Not actually used in any deployed crypto.)

• Factoring, discrete log have subexponential-time algorithms. • No big algorithmic improvement since 1993. • All progress has been Moore’s law, implementation details, etc. Discrete log over small characteristic ﬁelds (Not actually used in any deployed crypto.)

2012-12-24 1175-bit and 1425-bit Joux ∗ 2013-02-11 F21778 Joux ∗ 2013-02-19 F21971 GGMZ 2013-02-20 L(1/4 + o(1), c) Joux ∗ 2013-03-22 F24080 Joux ∗ 2013-04-11 F26120 GGMZ ∗ 2013-05-21 F26168 Joux O(log n) ∗ 2013-06-18 n algorithm for Fpn Barbulescu, Gaudry, Joux, Thom´e Extrapolated impact of hypothetical factoring algorithm improvements Current general-purpose factoring running time for integer N: L((64/9)1/3, 1/3) = exp (64/9)1/3(ln N)1/3 ∗ (ln ln N)2/3

Small-characteristic ﬁeld DL improvement from L(1/3) → L(1/4) → nO(log n).

bit length of N 1024 2048 4096 1/3 current state → L((64/9) , 1/3) 86 116 156 1/3 improved constant → L((32/9) , 1/3) 68 92 124 1/4 improved exponent → L((64/9) , 1/4) 49 63 81 bit-security of key • Researchers in area agree that small-characteristic techniques can’t be adapted to factoring or large primes

• Reminder that sometimes big progress can be made on old problems.

• There is no proof that factoring/discrete log are hard. (Polynomial heirarchy would collapse if they were NP-hard.)

• Elliptic curve discrete log totally diﬀerent story: index calculus unlikely to work. (Already Miller 1986, Koblitz 2000.)

Some recommendations:

• Don’t hard-code algorithms or key sizes.∗ If you must, use conservative choices.

• Listen to cryptographers. This is old news.

• Think about adopting elliptic curves. (More on this later.) . . . and fails. Close to #epicfail.

“It’s really annoying and complicated, the encryption software. . . . He kept harassing me, but at some point he just got frustrated, so he went to Laura.”

—Glenn Greenwald, quoted in “How Laura Poitras helped Snowden spill his secrets”, New York Times Magazine, 18 August 2013

Picture credit: Reuters via www.popularresistance.org

January 2013

A user actually tries to use crypto! Close to #epicfail.

“It’s really annoying and complicated, the encryption software. . . . He kept harassing me, but at some point he just got frustrated, so he went to Laura.”

—Glenn Greenwald, quoted in “How Laura Poitras helped Snowden spill his secrets”, New York Times Magazine, 18 August 2013

Picture credit: Reuters via www.popularresistance.org

January 2013

A user actually tries to use crypto! . . . and fails. “It’s really annoying and complicated, the encryption software. . . . He kept harassing me, but at some point he just got frustrated, so he went to Laura.”

—Glenn Greenwald, quoted in “How Laura Poitras helped Snowden spill his secrets”, New York Times Magazine, 18 August 2013

Picture credit: Reuters via www.popularresistance.org

January 2013

A user actually tries to use crypto! . . . and fails. Close to #epicfail. January 2013

A user actually tries to use crypto! . . . and fails. Close to #epicfail.

“It’s really annoying and complicated, the encryption software. . . . He kept harassing me, but at some point he just got frustrated, so he went to Laura.”

—Glenn Greenwald, quoted in “How Laura Poitras helped Snowden spill his secrets”, New York Times Magazine, 18 August 2013

Picture credit: Reuters via www.popularresistance.org sessions per byte of cookie (with all the sessions being au- en-US/docs/NSS/NSS_3.14.3_release_notes for tomatically generated). Note that the malware does not further details. need the ability to inject chosen plaintext into an existing Microsoft performed an investigation and determined that the TLS session for this attack. issue had been adequately addressed in previous modifications to their TLS and DTLS implementations How the attacks work: Our new attacks exploit the fact that, Apple were notified of our attacks in December 2012. The sta- when badly formatted padding is encountered during decryp- tus of patch development by Apple is currently unknown. tion, a MAC check must still be performed on some data to pre- GnuTLS corrected the programming errors in decryption that vent the known timing attacks. But what data should be used we identified in version 3.1.6 (released 02/01/2013) and ad- for that calculation? The TLS 1.1 and 1.2 RFCs recommend dressed the attacks in versions 2.12.23, 3.0.28 and 3.1.7, re- checking the MAC as if there was a zero-length pad. As noted leased 04/02/13. in those RFCs: PolarSSL addressed the attacks in version 1.2.5, released 03/02/13. This leaves a small timing channel, since MAC performance depends to some extent on the size of the CyaSSL addressed the attacks in CyaSSL version 2.5.0, re- data fragment, but it is not believed to be large leased 04/02/2013. enough to be exploitable, due to the large block size of MatrixSSL addressed the attacks in version 3.4.1, released existing MACs and the small size of the timing signal. 06/02/13. Opera addressed the attacks in Opera version 12.13, re- We confirm that there are indeed small timing differences, leased 30/01/2013. For further details, see www.opera.com/ but, contrary to what is written in the RFCs, they can be ex- docs/changelogs/unified/1213/. ploited. In short, provided there is a fortuitous alignment of F5 were notified of the attacks in December 2012. They various factors such as the size of MAC tags, the block cipher’s have informed us that their TLS dataplane traffic is not vul- block size, and the number of header bytes, then there will be a nerable due to cryptographic offload, but that local manage- time difference in the time that it takes to process TLS records ment ports and virtual editions may be vulnerable. For fur- having good and bad padding, and this difference will show ther details, see http://support.f5.com/kb/en-us/ up in the time at which error messages appear on the network. solutions/public/14000/100/sol14190.html. This timing side-channel can then be “wrangled” into reveal- BouncyCastle addressed the attacks in version 1.48 of the Java ing plaintext data via careful statistical analysis of multiple tim- library, released 10/02/2013. The C# version of BouncyCas- ing samples. As we shall show, other natural—AlFardan methods and for Paterson, han- tle was fixed in CVS at a similar time, and will be included in dling MAC checking“Lucky Thirteen: in the breaking event of the bad TLS paddingand DTLS recordalso lead protocols”, to release 1.8 at a later date. IEEE Symposium on Security and Privacy 2013 exploitable timing differences. Oracle (Java) addressed the attacks as part of a special critical It is not clear to us whether the attacks we present here were patch update of JavaSE, released 19/02/2013. already known to the TLS community. We suspect not, in view In addition, a number of other companies and organisations of the attacks’ complexity and the state-of-the-art in attacks at were given advance notice of the attacks prior to them being the time of writing of the TLS 1.1 RFC. However, this ques- made public. tion seems moot in view of the fact that attacks exist for RFC- We will continue to update this section as the disclosure pro- compliant implementations and present a threat to the security cess progresses. of TLS and DTLS. Our new attacks demonstrate that properly implementing MEE-TLS-CBC so as to avoid all exploitable timing differences 1.3 Further Details on Related Work is in fact quite difficult, and is not achieved by any of the implementations we examined. A complicating factor, in addition TLS, and in particular the TLS Handshake Protocol, has to dealing with padding, is the need for careful sanity checking been the subject of much analysis using a variety of security of various fields during decryption. We provide a detailed pre- paradigms, see for example [29, 18, 27, 5]. In general, these scription for dealing with these issues. We also discuss other, analyses are at too high a level of abstraction to capture our more easily-implemented countermeasures. attacks. Padding oracle attacks began with Vaudenay [37], who 1.2 Disclosure (as at 27/02/2013) showed that the presence of a padding oracle, that is, an oracle telling an attacker whether the padding was correctly for- Given the large number of affected implementations, we first matted or not, could be leveraged to build a decryption capa- notified the IETF TLS Working Group chairs, the IETF Secu- bility. Canvel et al. [6] showed that such an oracle could be rity Area directors and the IRTF Crypto Forum Research Group obtained for the then-current version of OpenSSL by exploiting (CFRG) chairs of our attacks in November 2012. We then be- a timing difference in TLS decryption processing. In essence, gan the process of contacting individual vendors: in OpenSSL, if the padding was incorrectly formatted, then no OpenSSL addressed the attacks in versions 1.0.1d, 1.0.0k and MAC check was performed, while if the padding was correct, 0.9.8y, released 05/02/2013. See http://www.openssl. then the MAC check was done. In turn, this meant faster pro- org/news/secadv_20130205.txt for further details. duction of an error message in the “invalid padding” case than NSS addressed the attacks in version 3.14.3, released in the “valid padding” case. Thus the padding oracle was re- 15/02/2013. See https://developer.mozilla.org/ vealed through a timing side-channel. A complication for full

February 2013: timing-padding-oracle attacks against TLS

This leaves a small timing channel, since MAC performance depends to some extent on the size of the data fragment, but it is not believed to be large enough to be exploitable, due to the large block size of existing MACs and the small size of the timing signal. —RFC 5246, “The Transport Layer Security (TLS) Protocol, Version 1.2”, 2008 sessions per byte of cookie (with all the sessions being au- en-US/docs/NSS/NSS_3.14.3_release_notes for tomatically generated). Note that the malware does not further details. need the ability to inject chosen plaintext into an existing Microsoft performed an investigation and determined that the TLS session for this attack. issue had been adequately addressed in previous modifications to their TLS and DTLS implementations How the attacks work: Our new attacks exploit the fact that, Apple were notified of our attacks in December 2012. The sta- when badly formatted padding is encountered during decryp- tus of patch development by Apple is currently unknown. tion, a MAC check must still be performed on some data to pre- GnuTLS corrected the programming errors in decryption that vent the known timing attacks. But what data should be used we identified in version 3.1.6 (released 02/01/2013) and ad- for that calculation? The TLS 1.1 and 1.2 RFCs recommend dressed the attacks in versions 2.12.23, 3.0.28 and 3.1.7, re- checking the MAC as if there was a zero-length pad. As noted leased 04/02/13. in those RFCs: PolarSSL addressed the attacks in version 1.2.5, released 03/02/13. This leaves a small timing channel, since MAC performance depends to some extent on the size of the CyaSSL addressed the attacks in CyaSSL version 2.5.0, re- data fragment, but it is not believed to be large leased 04/02/2013. enough to be exploitable, due to the large block size of MatrixSSL addressed the attacks in version 3.4.1, released existing MACs and the small size of the timing signal. 06/02/13. Opera addressed the attacks in Opera version 12.13, re- We confirm that there are indeed small timing differences, leased 30/01/2013. For further details, see www.opera.com/ February 2013: timing-padding-oracle attacks against TLS but, contrary to what is written in the RFCs, they can be ex- docs/changelogs/unified/1213/. ploited. In short, provided there is a fortuitous alignment of F5 were notified of the attacks in December 2012. They Thisvarious leaves factors a small such timing as the channel, size of since MAC MAC tags, performance the block depends cipher’s to have informed us that their TLS dataplane traffic is not vul- someblock extent size, on and the the size number of the of data header fragment, bytes, but then it there is not will believed be a to be large enough to be exploitable, due to the large block size of nerable due to cryptographic offload, but that local manage- existingtime difference MACs and the in the small time size that of it the takes timing to process signal. TLS records ment ports and virtual editions may be vulnerable. For fur- having—RFC good 5246, “The and Transport bad padding, Layer Security and this(TLS) difference Protocol, Version will 1.2”, show 2008 ther details, see http://support.f5.com/kb/en-us/ up in the time at which error messages appear on the network. solutions/public/14000/100/sol14190.html. This timing side-channel can then be “wrangled” into reveal- BouncyCastle addressed the attacks in version 1.48 of the Java ing plaintext data via careful statistical analysis of multiple tim- library, released 10/02/2013. The C# version of BouncyCas- ing samples. As we shall show, other natural—AlFardan methods and for Paterson, han- tle was fixed in CVS at a similar time, and will be included in dling MAC checking“Lucky Thirteen: in the breaking event of the bad TLS paddingand DTLS recordalso lead protocols”, to release 1.8 at a later date. IEEE Symposium on Security and Privacy 2013 exploitable timing differences. Oracle (Java) addressed the attacks as part of a special critical It is not clear to us whether the attacks we present here were patch update of JavaSE, released 19/02/2013. already known to the TLS community. We suspect not, in view In addition, a number of other companies and organisations of the attacks’ complexity and the state-of-the-art in attacks at were given advance notice of the attacks prior to them being the time of writing of the TLS 1.1 RFC. However, this ques- made public. tion seems moot in view of the fact that attacks exist for RFC- We will continue to update this section as the disclosure pro- compliant implementations and present a threat to the security cess progresses. of TLS and DTLS. Our new attacks demonstrate that properly implementing MEE-TLS-CBC so as to avoid all exploitable timing differences 1.3 Further Details on Related Work is in fact quite difficult, and is not achieved by any of the implementations we examined. A complicating factor, in addition TLS, and in particular the TLS Handshake Protocol, has to dealing with padding, is the need for careful sanity checking been the subject of much analysis using a variety of security of various fields during decryption. We provide a detailed pre- paradigms, see for example [29, 18, 27, 5]. In general, these scription for dealing with these issues. We also discuss other, analyses are at too high a level of abstraction to capture our more easily-implemented countermeasures. attacks. Padding oracle attacks began with Vaudenay [37], who 1.2 Disclosure (as at 27/02/2013) showed that the presence of a padding oracle, that is, an oracle telling an attacker whether the padding was correctly for- Given the large number of affected implementations, we first matted or not, could be leveraged to build a decryption capa- notified the IETF TLS Working Group chairs, the IETF Secu- bility. Canvel et al. [6] showed that such an oracle could be rity Area directors and the IRTF Crypto Forum Research Group obtained for the then-current version of OpenSSL by exploiting (CFRG) chairs of our attacks in November 2012. We then be- a timing difference in TLS decryption processing. In essence, gan the process of contacting individual vendors: in OpenSSL, if the padding was incorrectly formatted, then no OpenSSL addressed the attacks in versions 1.0.1d, 1.0.0k and MAC check was performed, while if the padding was correct, 0.9.8y, released 05/02/2013. See http://www.openssl. then the MAC check was done. In turn, this meant faster pro- org/news/secadv_20130205.txt for further details. duction of an error message in the “invalid padding” case than NSS addressed the attacks in version 3.14.3, released in the “valid padding” case. Thus the padding oracle was re- 15/02/2013. See https://developer.mozilla.org/ vealed through a timing side-channel. A complication for full

3 To mitigate this vulnerability, conﬁgure the client-side SSL proﬁle to prefer RC4-SHA ciphers.

Successful upgrade: RC4 was used for >50% of TLS traﬃc in February 2013.

February 2013: TLS algorithm agility to the rescue!

Typical vendor response: Successful upgrade: RC4 was used for >50% of TLS traﬃc in February 2013.

February 2013: TLS algorithm agility to the rescue!

Typical vendor response:

To mitigate this vulnerability, conﬁgure the client-side SSL proﬁle to prefer RC4-SHA ciphers. February 2013: TLS algorithm agility to the rescue!

Typical vendor response:

To mitigate this vulnerability, conﬁgure the client-side SSL proﬁle to prefer RC4-SHA ciphers.

Successful upgrade: RC4 was used for >50% of TLS traffic in February 2013. We hope that this work will help spur the adoption of to 220 bytes of the TLS application plaintext. TLS 1.2 and its authenticated encryption algorithms, as Our attack exploits statistical biases occurring in the well as the transition from WPA to (the hopefully more first 256 bytes of RC4 keystream. Such biases, i.e., devi- secure) WPA2. ations from uniform in the distributions of the keystream bytes at certain positions, have been reported and the- oretically analyzed by [17], [15], and [23]. The corre- 1.1 Overview of Results sponding authors also propose algorithms to exploit such We present two plaintext recovery attacks on RC4 that biases for plaintext recovery. In this paper, we discuss are exploitable in specific but realistic circumstances shortcomings of their algorithms, empirically obtain a when this cipher is used for encryption in TLS. Both at- complete view of all single-byte biases occurring in the tacks require a fixed plaintext to be RC4-encrypted and first 256 keystream positions, and propose a generalized transmitted many times in succession (in the same, or in algorithm that fully exploits all these biases for advanced multiple independent RC4 keystreams). Interesting can- plaintext recovery. As a side result of our research, in didates for such plaintexts include passwords and, in the Section 3.1 we report on significant biases in the RC4 March 2013:setting attacks of secure against web RC4 browsing, in TLS HTTP cookies. keystream that seemingly follow specific patterns and A statistical analysis of ciphertexts forms the core of that have not been identified or analysed previously. our attacks. We stress that the attacks are ciphertext- For concreteness, we describe how our single-byte only: no sophisticated timing measurement is needed on bias attack could be applied to recover cookies in HTTPS the part of the adversary, the attacker does not need to be traffic. Crucial here is to find an automated mechanism located close to the server, and no packet injection capa- for efficiently generating a large number of encryptions bility is required (all premises for Lucky 13). Instead, it of the target cookie. In line with the scenario employed suffices for the adversary to record encrypted traffic for by the BEAST and Lucky 13 attacks against CBC-mode later offline analysis. Provoking the required repeated encryption in TLS [3, 10], a candidate mechanism is encryption and transmission of the target plaintext, how- for JavaScript malware downloaded from an attacker- controlled website and running in the victim’s browser ever, might require—AlFardan, more explicit Bernstein, action: Paterson, e.g., resettingPoettering, Schuldt, TCP connections or guiding the victim“On to the a websitesecurity of with RC4 in TLS”,to repeatedly send HTTPS requests to a remote server. specially prepared JavaScript (see examplesUSENIX Security below). Symposium 2013The corresponding cookies are automatically included in Since both our attacks require large amounts of cipher- each of these requests in a predictable location, and can text, their practical relevance could be questioned. How- thus be targeted in our attack. If client and server are ever, they do show that the strength of RC4 in TLS is configured to use TLS session resumption, the renewal of much lower than the employed 128-bit key would sug- RC4 keys could be arranged to happen with particularly gest. We freely admit that our attacks are not particularly high frequency — as required for our attack to be suc- deep, nor sophisticated: they only require an understand- cessful.5 Alternatively, the attacker can cause the TLS ing of how TLS uses RC4, solid statistics on the biases session to be terminated after the target encrypted cookie in RC4 keystreams, and some experience of how modern is sent; the browser will automatically establish a new browsers handle cookies. We consider it both surprising TLS session when the next HTTPS request is sent. and alarming that such simple attacks are possible for As a second example, consider the case where IMAP such an important and heavily-studied protocol as TLS. passwords6 are attacked. In a setup where an email client We further discuss the implications of our attack in Sec- regularly connects to an IMAP server for (password- tion 6 and in the full version of this paper [4]. authenticated) mail retrieval, let the adversary reset the TCP connection between client and server immediately after the encrypted password is transmitted. In some 1.1.1 Our single-byte bias attack client configurations this might trigger an automatic re- Our first attack targets the initial 256 bytes of RC4 ci- sumption of the session, including a retransmission of the phertext. It is fixed-plaintext and multi-session, meaning (encrypted) password. If this is the case, the adversary that it requires a fixed sequence of plaintext bytes to be is in the position to harvest a large set of independently independently encrypted under a large number of (ran- encrypted copies of the password —one per reset— pre- dom) keys. This setting corresponds to what is called a cisely fulfilling the precondition of our attack. “broadcast attack” in [17, 15, 23]. As we argue below, Our single-byte bias attack is on the verge of prac- such attacks are a realistic attack vector in TLS. Observe ticality. In our experiments, the first 40 bytes of TLS that, in TLS, the first 36 bytes of the RC4 keystream are application data after the Finished message were re- used to encrypt a TLS Handshake Finished message. covered with a success rate of over 50% per byte, using This message is not fixed across TLS sessions. As a con- 226 sessions. With 232 sessions, the per-byte success rate sequence, our methods can be applied only to recover up is more than 96% for the first 220 bytes (and is 100%

306 22nd USENIX Security Symposium USENIX Association Taiwan Citizen Digital Certiﬁcate Government-issued smart cards allow citizens to • ﬁle income taxes, • update car registrations, • transact with government agencies, • interact with companies (e.g. Chunghwa Telecom) online.

FIPS-140 and Common Criteria Level 4+ certiﬁed. As reported at 29C3:

Collected 3 million certiﬁciates with RSA public keys.

Factored 103 keys using GCD algorithm:

N1 = pq1 N2 = pq2

gcd(N1, N2) = p

Oops, bad RNG. End of story? Most commonly shared factor appears 46 times

c0000000000000000000000000000000 00000000000000000000000000000000 00000000000000000000000000000000 000000000000000000000000000002f9 Next most common factor appears 7 times

c9242492249292499249492449242492 24929249924949244924249224929249 92494924492424922492924992494924 492424922492924992494924492424e5 Factoring RSA keys from certiﬁed smart cards: Coppersmith in the wild Daniel J. Bernstein, Yun-An Chang, Chen-Mou Cheng, Li-Ping Chou, Nadia Heninger, Tanja Lange, and Nicko van Someren. Asiacrypt 2013.

Factored 80 more keys using guessing, trial division, and nifty math tricks.

• Nontrivial GCD is not the only way RSA can fail with bad randomness. • Faulty hardware RNG in Renesas AE45C1 microcontroller. • Failure of some Chunghwa Telecom HiCOS PKI smart cards to post-process output. 4 follow-up papers on ePrint ⇒ success on distracting the cryptographers.

June 19, 2013, Meanwhile at the NSA

The SIMON and SPECK Families of Lightweight Block Ciphers Ray Beaulieu and Douglas Shors and Jason Smith and Stefan Treatman-Clark and Bryan Weeks and Louis Wingers.

http://eprint.iacr.org/2013/404 June 19, 2013, Meanwhile at the NSA

The SIMON and SPECK Families of Lightweight Block Ciphers Ray Beaulieu and Douglas Shors and Jason Smith and Stefan Treatman-Clark and Bryan Weeks and Louis Wingers.

http://eprint.iacr.org/2013/404

4 follow-up papers on ePrint ⇒ success on distracting the cryptographers. Advertisement: Hear more about NaCl tomorrow at You-Broke-The-Internet assembly Operating systems session.

2013-12-29 13:00 Hall E

July 2013: TweetNaCl

The NaCl library in 100 tweets! https://twitter.com/tweetnacl July 2013: TweetNaCl

The NaCl library in 100 tweets! https://twitter.com/tweetnacl

Advertisement: Hear more about NaCl tomorrow at You-Broke-The-Internet assembly Operating systems session.

2013-12-29 13:00 Hall E August 2013 ""0 t 10 (!WI. 01!()9) S:.tbpocna 10 Tcst!1'y aelb:e, G~ Jury United States"" .,District Court Eastern District of Virginia SUBPOENA TO TESTIFY BEFORE THE GR,.-\ND JURY TO:

DaHas, TX 75204

YOU ARECQMMA.,'lDED 10 appear and testify before !be Uoited States district court at the time, date.;me place shown below to lesify before the court's grand jury. When you arrive, you must remain at the C::Ill" until the judge or II court offioer allows yO\! to leave.

Pltte: UNITED ST AYES DlSTRlCT COURT II: tnd Time: July lG, lUll 9:30 AM ~Dl COllrthouseSqulrf Alex8ndriJ. Vir,inI8l2314______J- ______

You mUll also brin& with)'O\l the folJowill& docume:1ts. clcctroni~!y l10red lnformu ion. or objecu (bll!!'.K ifr.Ol "?plica.bl,,):

In .. ddifion to your !,l:"l'SunHI"flpear"nce,you arc direeled to b ring 10 the grano jury the public lind private encryptiun I;c)'5 used by l:.Ivabil.CQn. in any SSl.. (See orl! S<:>ekel L:.I,,

Any utt:cr in form:Hlon necessary to ~ccompl!$fl tht insull2t1 on :lncl use of tile ptnltrap device ordered by Jud?;e BIlc;h"nnn 011 June 28, 2013, unubtrusively :o nd wiln minimum ;ntenerenl:"t to the serviee" th2t arc >lctorded persons with respect 10 whom Ihe inst:lllati(ln and use illo take place;

If such information i3 electronically slof'1:d or unable to ~ physically transported to the ;:rand jury, you mtty provide ~ co fly of t be information to the Feder... l BurtllU of [nv~tig

Julv (I 2013 CL£RJ(

·f'!.c n&me, lId=, email.Md!el-:phonenu.mbecofthcUr.ill:d StIIleS ~lom e y,-orllSSistc! United Stu~~y'who requests thi s s~bpoal;l, tL"t':

". 1'I0~n.)' JU.Ul1 W. Wi1li" m$l;"ittd Sr",r~ Attonu,.'s SII,hljn: ] [00 J\lm l '~un ,\Venlle ,\ll·. • ~"drh. , Vlq~;r.i~ 1131~ p03} 299·nOO -_. .. - ...... TLS RSA Key Exchange Why forward secrecy is important

hello

certiﬁcate, public RSA key

RSAEncRSAkey (AES key)

AESEncAESkey (website contents)

An adversary with Lavabit’s private key can • impersonate Lavabit.com to anyone • decrypt traﬃc from now on and from any point in the past. TLS Diﬃe-Hellman Key Exchange Why forward secrecy is important

hello, g x

g y , certiﬁcate, public RSA key

x y RSASignRSAkey (g , g )

AESEncg xy (website contents)

An adversary with Lavabit’s private key can • impersonate Lavabit.com to anyone Forward secrecy: cannot retroactively decrypt historical traﬃc if the private keys were forgotten. Your Homework:

• If you’re an end-user, a website enables forward secrecy if you see a cipher suite with DHE (Diﬃe-Hellman ephemeral) or ECDHE (elliptic-curve Diﬃe-Hellman ephemeral). ccc.de has enabled forward secrecy. • If you run a website, enable forward secrecy! See e.g. https://bettercrypto.org

microsoft.com does not oﬀer forward secrecy.

• If you build a privacy tool, use end-to-end crypto.

August 2013: MEGAMOS crypto

Baris Ege, Flavio Garcia, Roel Verdult break VW car immobilizers.

Paper stopped from being published since it contained ”secret” crypto algorithm. August 2013: CRYPTO Rump session

Using full-disk encryption Email with PGP Elliptic curves in your browser for forward secrecy Hardware tokens for crypto Using bitcoins to pay Everybody use CRYPTO Screw the NSA

Full song: http://www.youtube.com/watch?v=0ricox_ozb4 Scary Paper of the Year: Stealthy Dopant-Level Hardware Trojans by Becker, Regazzoni, Paar, and Burleson, CHES 2013 DUAL EC RNG: history part I

Earliest public source (?) June 2004, draft of ANSI X9.82:

ϕ gives all but the top 16 bits ⇒ about 215 points sQ match given string. Claim: DUAL EC RNG: common public history part II

Various public warning signals: • Gjøsteen (March 2006): output sequence is biased. “While the practical impact of these results are modest, it is hard to see how these flaws would be acceptable in a pseudo-random bit generator based on symmetric cryptographic primitives. They should not be accepted in a generator based on number-theoretic assumptions.” • Brown (March 2006): security “proof” “This proof makes essential use of Q being random.” If d with dQ = P is known then dRi = Si+1, concludes that there might be distinguisher. • Sidorenko & Schoenmakers (May 2006): output sequence is even more biased. Answer: Too late to change, already implemented. • Shumow & Ferguson (August 2007): Backdoor if d is known. • NIST standard gets appendix about choosing points verifiably at random, continues to recommend fixed P and Q. Later NYT names Dual EC DRBG. . . but surely nobody uses that piece of shit?!

NIST’s DRBG Validation List: RSA’s BSAFE has Dual EC DRBG enabled and default.

NIST re-opens discussions on SP800.90; recommmends against using Dual EC. RSA suggests changing default in BSAFE.

September 2013: NSA Bullrun program but surely nobody uses that piece of shit?!

NIST’s DRBG Validation List: RSA’s BSAFE has Dual EC DRBG enabled and default.

NIST re-opens discussions on SP800.90; recommmends against using Dual EC. RSA suggests changing default in BSAFE.

September 2013: NSA Bullrun program

Later NYT names Dual EC DRBG. . . NIST’s DRBG Validation List: RSA’s BSAFE has Dual EC DRBG enabled and default.

NIST re-opens discussions on SP800.90; recommmends against using Dual EC. RSA suggests changing default in BSAFE.

September 2013: NSA Bullrun program

Later NYT names Dual EC DRBG. . . but surely nobody uses that piece of shit?! NIST re-opens discussions on SP800.90; recommmends against using Dual EC. RSA suggests changing default in BSAFE.

September 2013: NSA Bullrun program

Later NYT names Dual EC DRBG. . . but surely nobody uses that piece of shit?!

NIST’s DRBG Validation List: RSA’s BSAFE has Dual EC DRBG enabled and default. September 2013: NSA Bullrun program

Later NYT names Dual EC DRBG. . . but surely nobody uses that piece of shit?!

NIST’s DRBG Validation List: RSA’s BSAFE has Dual EC DRBG enabled and default.

NIST re-opens discussions on SP800.90; recommmends against using Dual EC. RSA suggests changing default in BSAFE. Given ri = ϕ(x(si Q)), ri+1 = ϕ(x(si+1Q)), and NSA backdoor d = logP (Q).

1. Expand ri to candidate Qi = si Q, [50% chance; if fail move on to next candidate]