[{"pdf:PDFVersion":"1.5","xmp:CreatorTool":"LaTeX with hyperref package","pdf:docinfo:title":"Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice","pdf:hasXFA":"false","X-TIKA:Parsed-By-Full-Set":["org.apache.tika.parser.DefaultParser","org.apache.tika.parser.pdf.PDFParser","org.apache.tika.parser.image.ImageParser","org.apache.tika.parser.ocr.TesseractOCRParser"],"X-TIKA:content_handler":"ToTextContentHandler","pdf:num3DAnnotations":"0","dc:format":"application/pdf; version=1.5","pdf:docinfo:creator_tool":"LaTeX with hyperref package","access_permission:fill_in_form":"true","pdf:hasCollection":"false","pdf:encrypted":"false","dc:title":"Imperfect Forward Secrecy: How Diffie-Hellman Fails in Practice","pdf:containsNonEmbeddedFont":"false","xmp:CreateDate":"2015-08-21T15:06:23Z","pdf:hasMarkedContent":"false","pdf:ocrPageCount":"0","access_permission:can_print_faithful":"true","xmp:ModifyDate":"2015-08-21T15:08:05Z","PTEX.Fullbanner":"This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian) kpathsea version 6.1.1","access_permission:extract_for_accessibility":"true","resourceName":"sample-technical.pdf","X-TIKA:Parsed-By":["org.apache.tika.parser.DefaultParser","org.apache.tika.parser.pdf.PDFParser"],"pdf:eofOffsets":"1386628","X-TIKA:embedded_depth":"0","X-TIKA:content":"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nImperfect Forward Secrecy: How Diffie-Hellman Fails in Practice\n\n\nImperfect Forward Secrecy:\nHow Diffie-Hellman Fails in Practice\n\nDavid Adrian¶ Karthikeyan Bhargavan∗ Zakir Durumeric¶ Pierrick Gaudry† Matthew Green§\nJ. Alex Halderman¶ Nadia Heninger‡ Drew Springall¶ Emmanuel Thomé† Luke Valenta‡\nBenjamin VanderSloot¶ Eric Wustrow¶ Santiago Zanella-Béguelin‖ Paul Zimmermann†\n\n∗ INRIA Paris-Rocquencourt † INRIA Nancy-Grand Est, CNRS, and Université de Lorraine\n‖Microsoft Research ‡University of Pennsylvania § Johns Hopkins ¶University of Michigan\n\nFor additional materials and contact information, visit WeakDH.org.\n\nABSTRACT\nWe investigate the security of Diffie-Hellman key exchange as\nused in popular Internet protocols and find it to be less secure\nthan widely believed. First, we present Logjam, a novel flaw\nin TLS that lets a man-in-the-middle downgrade connections\nto “export-grade” Diffie-Hellman. To carry out this attack,\nwe implement the number field sieve discrete log algorithm.\nAfter a week-long precomputation for a specified 512-bit\ngroup, we can compute arbitrary discrete logs in that group\nin about a minute. We find that 82% of vulnerable servers use\na single 512-bit group, allowing us to compromise connections\nto 7% of Alexa Top Million HTTPS sites. In response, major\nbrowsers are being changed to reject short groups.\nWe go on to consider Diffie-Hellman with 768- and 1024-bit\n\ngroups. We estimate that even in the 1024-bit case, the com-\nputations are plausible given nation-state resources. A small\nnumber of fixed or standardized groups are used by millions\nof servers; performing precomputation for a single 1024-bit\ngroup would allow passive eavesdropping on 18% of popular\nHTTPS sites, and a second group would allow decryption\nof traffic to 66% of IPsec VPNs and 26% of SSH servers. A\nclose reading of published NSA leaks shows that the agency’s\nattacks on VPNs are consistent with having achieved such\na break. We conclude that moving to stronger key exchange\nmethods should be a priority for the Internet community.\n\n1. INTRODUCTION\nDiffie-Hellman key exchange is widely used to establish\n\nsession keys in Internet protocols. It is the main key exchange\nmechanism in SSH and IPsec and a popular option in TLS.\nWe examine how Diffie-Hellman is commonly implemented\nand deployed with these protocols and find that, in practice,\nit frequently offers less security than widely believed.\nThere are two reasons for this. First, a surprising number\n\nof servers use weak Diffie-Hellman parameters or maintain\nsupport for obsolete 1990s-era export-grade crypto. More\ncritically, the common practice of using standardized, hard-\n\nPermission to make digital or hard copies of part or all of this work for personal or\nclassroom use is granted without fee provided that copies are not made or distributed\nfor profit or commercial advantage and that copies bear this notice and the full cita-\ntion on the first page. Copyrights for third-party components of this work must be\nhonored. For all other uses, contact the Owner/Author(s). Copyright is held by the\nowner/author(s).\nCCS’15, October 12–16, 2015, Denver, Colorado, USA.\nACM 978-1-4503-3832-5/15/10.\nDOI: http://dx.doi.org/10.1145/2810103.2813707.\n\ncoded, or widely shared Diffie-Hellman parameters has the\neffect of dramatically reducing the cost of large-scale attacks,\nbringing some within range of feasibility today.\nThe current best technique for attacking Diffie-Hellman\n\nrelies on compromising one of the private exponents (a, b)\nby computing the discrete log of the corresponding public\nvalue (ga mod p, gb mod p). With state-of-the-art number\nfield sieve algorithms, computing a single discrete log is more\ndifficult than factoring an RSA modulus of the same size.\nHowever, an adversary who performs a large precomputation\nfor a prime p can then quickly calculate arbitrary discrete logs\nin that group, amortizing the cost over all targets that share\nthis parameter. Although this fact is well known among\nmathematical cryptographers, it seems to have been lost\namong practitioners deploying cryptosystems. We exploit it\nto obtain the following results:\nActive attacks on export ciphers in TLS. We introduce\nLogjam, a new attack on TLS by which a man-in-the-middle\nattacker can downgrade a connection to export-grade cryp-\ntography. This attack is reminiscent of the FREAK attack [7]\nbut applies to the ephemeral Diffie-Hellman ciphersuites and\nis a TLS protocol flaw rather than an implementation vulner-\nability. We present measurements that show that this attack\napplies to 8.4% of Alexa Top Million HTTPS sites and 3.4%\nof all HTTPS servers that have browser-trusted certificates.\nTo exploit this attack, we implemented the number field\n\nsieve discrete log algorithm and carried out precomputation\nfor two 512-bit Diffie-Hellman groups used by more than\n92% of the vulnerable servers. This allows us to compute\nindividual discrete logs in about a minute. Using our discrete\nlog oracle, we can compromise connections to over 7% of Top\nMillion HTTPS sites. Discrete logs over larger groups have\nbeen computed before [8], but, as far as we are aware, this\nis the first time they have been exploited to expose concrete\nvulnerabilities in real-world systems.\n\nWe were also able to compromise Diffie-Hellman for many\nother servers because of design and implementation flaws and\nconfiguration mistakes. These include use of composite-order\nsubgroups in combination with short exponents, which is\nvulnerable to a known attack of van Oorschot andWiener [51],\nand the inability of clients to properly validate Diffie-Hellman\nparameters without knowing the subgroup order, which TLS\nhas no provision to communicate. We implement these\nattacks too and discover several vulnerable implementations.\nRisks from common 1024-bit groups. We explore the im-\nplications of precomputation attacks for 768- and 1024-bit\ngroups, which are widely used in practice and still considered\n\nhttps://weakdh.org\n\n\np\n\npolynomial\nselection\n\nsieving linear\nalgebra\n\nlog db\n\nprecomputation\n\ny, g descent\n\nx\n\nindividual log\n\nFigure 1: The number field sieve algorithm for discrete log consists of a precomputation stage that depends only on\nthe prime p and a descent stage that computes individual logs. With sufficient precomputation, an attacker can quickly break\nany Diffie-Hellman instances that use a particular p.\n\nsecure. We provide new estimates for the computational re-\nsources necessary to compute discrete logs in groups of these\nsizes, concluding that 768-bit groups are within range of aca-\ndemic teams, and 1024-bit groups may plausibly be within\nrange of state-level attackers. In both cases, individual logs\ncan be quickly computed after the initial precomputation.\nWe then examine evidence from published Snowden docu-\n\nments that suggests NSA may already be exploiting 1024-bit\nDiffie-Hellman to decrypt VPN traffic. We perform measure-\nments to understand the implications of such an attack for\npopular protocols, finding that an attacker who could perform\nprecomputations for ten 1024-bit groups could passively de-\ncrypt traffic to about 66% of IKE VPNs, 26% of SSH servers,\n16% of SMTP servers, and 24% of popular HTTPS sites.\nMitigations and lessons. As a short-term countermeasure\nin response to the Logjam attack, all mainstream browsers\nare implementing a more restrictive policy on the size of\nDiffie-Hellman groups they accept. We further recommend\nthat TLS servers disable export-grade cryptography and\ncarefully vet the Diffie-Hellman groups they use. In the\nlonger term, we advocate that protocols migrate to stronger\nDiffie-Hellman groups, such as those based on elliptic curves.\n\n2. DIFFIE-HELLMAN CRYPTANALYSIS\nDiffie-Hellman key exchange was the first published public-\n\nkey algorithm [14]. In the simple case of prime groups,\nAlice and Bob agree on a prime p and a generator g of a\nmultiplicative subgroup modulo p. Alice sends ga mod p,\nBob sends gb mod p, and each computes a shared secret\ngab mod p. While there is also a Diffie-Hellman exchange\nover elliptic curve groups, we address only the “mod p” case.\nThe security of Diffie-Hellman is not known to be equiva-\n\nlent to the discrete log problem (except in certain groups [13,\n33,34]), but computing discrete logs remains the best known\ncryptanalytic attack. An attacker who can find the discrete\nlog x from y = gx mod p can easily find the shared secret.\nTextbook descriptions of discrete log can be misleading\n\nabout the computational tradeoffs, for example by balancing\nparameters to minimize overall time to compute a single\ndiscrete log. In fact, as illustrated in Figure 1, a single large\nprecomputation on p can be used to efficiently break all\nDiffie-Hellman exchanges made with that prime.\nThe typical case Diffie-Hellman is typically implemented\nwith prime fields and large group orders. In this case, the\nmost efficient discrete log algorithm is the number field sieve\n(NFS) [21, 24, 43].1 There is a closely related number field\n\nsieve algorithm for factoring [12,31], and in fact many parts of\nthe implementations can be shared. The general technique is\ncalled index calculus and has four stages with different compu-\ntational properties. The first three steps are only dependent\non the prime p and comprise most of the computation.\nFirst is polynomial selection, in which one finds a polyno-\n\nmial f(z) defining a number field Q(z)/f(z) for the computa-\ntion. (For our cases, f(z) typically has degree 5 or 6.) This\nparallelizes well and is only a small portion of the runtime.\nIn the second stage, sieving, one factors ranges of integers\n\nand number field elements in batches to find many relations of\nelements, all of whose prime factors are less than some bound\nB (called B-smooth). Modern implementations use special-q\nlattice sieving, which for each special q explores a sieving\nregion of 22I candidates, where I is a parameter. Sieving\nparallelizes well since each special q is handled independently\nof the others, but is computationally expensive, because we\nmust search through and attempt to factor many elements.\nThe time for this step depends on heuristic estimates of\nthe probability of encountering B-smooth numbers in this\nsearch; it also depends on I and on the number of special q\nto consider before having enough relations.\nIn the third stage, linear algebra, we construct a large,\n\nsparse matrix consisting of the coefficient vectors of prime\nfactorizations we have found. A nonzero kernel vector of the\nmatrix modulo the order q of the group will give us logs of\nmany small elements. This database of logs serves as input\nto the final stage. The difficulty depends on q and the matrix\nsize and can be parallelized in a limited fashion.\nThe final stage, descent, actually deduces the discrete log\n\nof the target y. We re-sieve until we can find a set of relations\nthat allow us to write the log of y in terms of the logs in the\nprecomputed database. This step is accomplished in three\nphases: an initialization phase, which tries to write the target\nin terms of medium-sized primes, a middle phase, in which\nthese medium-sized primes are further sieved until they can\nbe represented by elements in the database of known logs,\nand a final phase that actually reconstructs the target using\nthe log database. Crucially, descent is the only NFS stage\nthat involves y (or g), so polynomial selection, sieving, and\nlinear algebra can be done once for a prime p and reused to\ncompute the discrete logs of many targets.\n\n1Recent spectacular advances in discrete log algorithms\nhave resulted in a quasi-polynomial algorithm for small-\ncharacteristic fields [3], but these advances are not known to\napply to the prime fields used in practice.\n\n2\n\n\n\nThe running time of this algorithm is Lp(1/3, (64/9)1/3) =\nexp\n(\n(1.923 + o(1))(log p)1/3(log log p)2/3). This is obtained\n\nby tuning many parameters, including the degree of f , the\nsieving region parameter I, and, most importantly, the\nsmoothness bound B. Early articles (e.g. [21]) encountered\ntechnical difficulties with descent and reported that the com-\nplexity of this step would equal that of the precomputation;\nthis may have contributed to misconceptions about the perfor-\nmance of the NFS for discrete logs. More recent analyses have\nimproved the complexity of descent to Lp(1/3, 1.442) [10],\nand later to Lp(1/3, 1.232) [2], which is much cheaper than\nthe precomputation in practice.\nThe numerous parameters of the algorithm allow some\n\nflexibility to reduce time on some computational steps at the\nexpense of others. For example, sieving more will result in\na smaller matrix, making linear algebra cheaper, and doing\nmore work in the precomputation makes the final descent\nstep easier. In §3.3, we show how exploiting these tradeoffs\nallows us to quickly compute 512-bit discrete logs in order\nto perform an effective man-in-the-middle attack on TLS.\nImproperly generated groups A different family of\nalgorithms runs in time exponential in group order, and they\nare practical even for large primes when the group order is\nsmall or has many small prime factors. To avoid this, most\nimplementations use “safe” primes, which have the property\nthat p− 1 = 2q for some prime q, so that the only possible\nsubgroups have order 2, q, or 2q. However, as we show in\n§3.5, improperly generated groups are sometimes used in\npractice and susceptible to attack.\nThe baby-step giant-step [45] and Pollard rho [42] algo-\n\nrithms both take √q time to compute a discrete log in any\n(sub)group of order q, while Pollard lambda [42] can find\nx < t in time\n\n√\nt. These parallelize well [50], and precom-\n\nputation can speed up individual log calculations. If the\nfactorization of the subgroup order q is known, one can\nuse any of the above algorithms to compute the discrete\nlog in each subgroup of order qei\n\ni dividing q, and then re-\ncover x using the Chinese remainder theorem. This is the\nPohlig-Hellman algorithm [41], which costs\n\n∑\ni\nei\n√\n\nqi using\nbaby-step giant-step or Pollard rho.\nStandard primes Generating primes with special proper-\nties can be computationally burdensome, so many implemen-\ntations use fixed or standardized Diffie-Hellman parameters.\nA prominent example is the Oakley groups [40], which give\n“safe” primes of length 768 (Oakley Group 1), 1024 (Oakley\nGroup 2), and 1536 (Oakley Group 5). These groups were\npublished in 1998 and have been used for many applications\nsince, including IKE, SSH, Tor, and OTR.\nWhen primes are of sufficient strength, there seems to be\n\nno disadvantage to reusing them. However, widespread reuse\nof Diffie-Hellman groups can convert attacks that are at the\nlimits of an adversary’s capabilities into devastating breaks,\nsince it allows the attacker to amortize the cost of discrete\nlog precomputation among vast numbers of potential targets.\n\n3. ATTACKING TLS\nTLS supports Diffie-Hellman as one of several possible\n\nkey exchange methods, and about two-thirds of popular\nHTTPS sites allow it, most commonly using 1024-bit primes.\nHowever, a smaller number of servers also support legacy\n“export-grade” Diffie-Hellman using 512-bit primes that are\nwell within reach of NFS-based cryptanalysis. Furthermore,\n\nSource Popularity Prime\nApache 82% 9fdb8b8a004544f0045f1737d0ba2e0b\n\n274cdf1a9f588218fb435316a16e3741\n71fd19d8d8f37c39bf863fd60e3e3006\n80a3030c6e4c3757d08f70e6aa871033\n\nmod_ssl 10% d4bcd52406f69b35994b88de5db89682\nc8157f62d8f33633ee5772f11f05ab22\nd6b5145b9f241e5acc31ff090a4bc711\n48976f76795094e71e7903529f5a824b\n\n(others) 8% (463 distinct primes)\n\nTable 1: Top 512-bit DH primes for TLS. 8.4% of Alexa\nTop 1M HTTPS domains allow DHE_EXPORT, of which\n92.3% use one of the two most popular primes, shown here.\n\nfor both normal and export-grade Diffie-Hellman, the vast\nmajority of servers use a handful of common groups.\nIn this section, we exploit these facts to construct a novel\n\nattack against TLS, which we call the Logjam attack. First,\nwe perform NFS precomputations for the two most popular\n512-bit primes on the web, so that we can quickly compute\nthe discrete log for any key-exchange message that uses one\nof them. Next, we show how a man-in-the-middle, so armed,\ncan attack connections between popular browsers and any\nserver that allows export-grade Diffie-Hellman, by using a\nTLS protocol flaw to downgrade the connection to export-\nstrength and then recovering the session key. We find that\nthis attack with our precomputations can compromise about\n7.8% of HTTPS servers among Alexa Top Million domains.\n\n3.1 TLS and Diffie-Hellman\nThe TLS handshake begins with a negotiation to determine\n\nthe crypto algorithms used for the session. The client sends a\nlist of supported ciphersuites (and a random nonce cr) within\nthe ClientHello message, where each ciphersuite specifies a key\nexchange algorithm and other primitives. The server selects\na ciphersuite from the client’s list and signals its selection in\na ServerHello message (containing a random nonce sr).\nTLS specifies ciphersuites supporting multiple varieties of\n\nDiffie-Hellman. Textbook Diffie-Hellman with unrestricted\nstrength is called “ephemeral” Diffie-Hellman, or DHE, and\nis identified by ciphersuites that begin with TLS_DHE_*.2 In\nDHE, the server is responsible for selecting the Diffie-Hellman\nparameters. It chooses a group (p, g), computes gb, and sends\na ServerKeyExchange message containing a signature over the\ntuple (cr, sr, p, g, gb) using the long-term signing key from\nits certificate. The client verifies the signature and responds\nwith a ClientKeyExchange message containing ga.\n\nTo ensure agreement on the negotiation messages, and to\nprevent downgrade attacks [52], each party computes the\nTLS master secret from gab and calculates a MAC of its view\nof the handshake transcript. These MACs are exchanged\nin a pair of Finished messages and verified by the recipients.\nThereafter, client and server start exchanging application\ndata, protected by an authenticated encryption scheme with\nkeys also derived from gab.\nTo comply with 1990s-era U.S. export restrictions on cryp-\n\ntography, SSL 3.0 and TLS 1.0 supported reduced-strength\n2TLS also supports a rarely used “static” Diffie-Hellman\nformat, where the server’s key exchange value is fixed and\ncontained in its certificate. New ciphersuites that use elliptic\ncurve Diffie-Hellman (ECDHE) are gaining in popularity, but\nwe focus exclusively on the traditional prime field variety.\n\n3\n\n\n\nFigure 2: The Logjam attack. A man-in-the-middle can\nforce TLS clients to use export-strength DH with any server\nthat allows DHE_EXPORT. Then, by finding the 512-bit dis-\ncrete log, the attacker can learn the session key and arbitrarily\nread or modify the contents. Datafs refers to False Start [30]\napplication data that some TLS clients send before receiving\nthe server’s Finished message.\n\nDHE_EXPORT ciphersuites that were restricted to primes no\nlonger than 512 bits. In all other respects, DHE_EXPORT\nprotocol messages are identical to DHE. The relevant export\nrestrictions are no longer in effect, but many libraries and\nservers maintain support for backwards compatibility. Many\nTLS servers are still configured with two groups: a strong\n1024-bit group for regular DHE key exchanges and a 512-bit\ngroup for legacy DHE_EXPORT. This has been considered\nsafe because most modern TLS clients do not offer or accept\nDHE_EXPORT ciphersuites.\nTo understand how HTTPS servers in the wild use Diffie-\n\nHellman, we modified the ZMap [15] toolchain to offer DHE\nand DHE_EXPORT ciphersuites and scanned TCP/443 on\nboth the full public IPv4 address space and the Alexa\nTop 1M domains. The scans took place in March 2015. Of\n539,000 HTTPS sites among Top 1M domains, we found that\n68.3% supported DHE and 8.4% supported DHE_EXPORT.\nOf 14.3 million IPv4 HTTPS servers with browser-trusted\ncertificates, 23.9% supported DHE and 4.9% DHE_EXPORT.\nWhile the TLS protocol allows servers to generate their own\n\nDiffie-Hellman parameters, the overwhelming majority use\none of a handful of primes. As shown in Table 1, just two 512-\nbit primes account for 92.3% of Alexa Top 1M domains that\nsupport DHE_EXPORT, and 92.5% of all servers with browser-\ntrusted certificates that support DHE_EXPORT. (Non-export\nDHE follows a similar distribution with longer primes.) The\nmost popular 512-bit prime was hard-coded into many ver-\nsions of Apache. Introduced in 2005 with Apache 2.1.5, it\nwas used until 2.4.7, which disabled export ciphersuites. We\nfound it in use by about 564,000 servers with browser-trusted\ncertificates. The second most popular 512-bit prime is the\ndefault used for DHE_EXPORT when using mod_ssl. It was\nintroduced in version 2.3.0 in 1999. We found it in use by\nabout 89,000 servers with browser-trusted certificates.\n\n3.2 Active Downgrade to Export-Grade DHE\nGiven the widespread use of these primes, an attacker with\n\nthe ability to compute discrete logs in 512-bit groups could\nefficiently break DHE_EXPORT handshakes for about 8% of\nAlexa Top 1M HTTPS sites, but modern browsers never\n\nnegotiate export-grade ciphersuites. To circumvent this, we\nshow how an attacker who can compute 512-bit discrete\nlogs in real time can downgrade a regular DHE connection\nto use a DHE_EXPORT group, and thereby break both the\nconfidentiality and integrity of application data.\nThe attack, which we call Logjam, is depicted in Figure 2\n\nand relies on a flaw in the way TLS composes DHE and\nDHE_EXPORT. When a server selects DHE_EXPORT for a\nhandshake, it proceeds by issuing a signed ServerKeyExchange\nmessage containing a 512-bit p512, but the structure of this\nmessage is identical to the message sent during standard DHE\nciphersuites. Critically, the signed portion of the server’s\nmessage fails to include any indication of the specific cipher-\nsuite that the server has chosen. Provided that a client offers\nDHE, an active attacker can rewrite the client’s ClientHello to\noffer a corresponding DHE_EXPORT ciphersuite accepted by\nthe server and remove other ciphersuites that could be chosen\ninstead. The attacker rewrites the ServerHello response to\nreplace the chosen DHE_EXPORT ciphersuite with a matching\nnon-export ciphersuite and forwards the ServerKeyExchange\nmessage to the client as is. The client will interpret the\nexport-grade tuple (p512, g, gb) as valid DHE parameters cho-\nsen by the server and proceed with the handshake. The\nclient and server have different handshake transcripts at this\nstage, but an attacker who can compute b in close to real\ntime can then derive the master secret and connection keys\nto complete the handshake with the client, and then freely\nread and write application data pretending to be the server.\nThere are two remaining challenges in implementing this\n\nactive downgrade attack. The first is to compute individual\ndiscrete logs in close to real time, and the second is to delay\nhandshake completion until the discrete log computation has\nhad time to finish. We address these in the next subsections.\nComparison with previous attacks Logjam is remi-\nniscent of the recent FREAK [7] attack, in which an attacker\ndowngrades a regular RSA key exchange to one that uses\nexport-grade 512-bit ephemeral RSA keys, relying on a bug\nin several TLS client implementations. The attacker then\nfactors the ephemeral key to hijack future connections that\nuse the same key. The cryptanalysis takes several hours on\ncommodity hardware and is usable until the server generates\na fresh ephemeral RSA key (typically when it restarts).\nIn contrast, Logjam is due to a protocol flaw in TLS, not\n\nan implementation bug. From a client perspective, the only\ndefense is to reject small primes in DHE handshakes. (Prior\nto this work, most popular browsers accepted p of size ≥ 512\nbits.) Logjam affects fewer servers than FREAK, but, as we\nshall see, the cost per compromised connection is far lower,\nsince the precomputation for each 512-bit group can be used\nindefinitely against all servers that use that group, and since\neach individual discrete log only takes about a minute.\nLogjam and FREAK both follow the same pattern as other\n\ncross-protocol attacks discovered in TLS. As early as SSL 3.0,\nSchneier and Wagner noted a related vulnerability that they\ncalled key exchange rollback [52]. Mavrogiannopoulos et al.\nshowed how explicit-curve ECDHE handshakes could be con-\nfused with DHE handshakes [35]. All these attacks could\nbe prevented by additionally signing the ciphersuite in the\nServerKeyExchange message. We expect that TLS 1.3 will fix\nthis protocol flaw. More generally, Logjam can also be inter-\npreted as a backwards compatibility attack [23] where one\nparty uses only strong cryptography but the other supports\nboth strong and weak ciphersuites.\n\n4\n\n\n\n3.3 512-bit Discrete Log Computations\nWe modified CADO-NFS [1] to implement the number field\n\nsieve discrete log algorithm from §2 and applied it to three\n512-bit primes, including the top two DHE_EXPORT primes\nshown in Table 1. Precomputation took 7 days for each prime,\nafter which computing individual logs took a median of 70 sec-\nonds. We list the runtime for each stage of the computation\nbelow. The times were about the same for each prime.\n\nPrecomputation As illustrated in Figure 1, the precom-\nputation phase includes the polynomial selection, sieving, and\nlinear algebra steps. For this precomputation, we deliberately\nsieved more than strictly necessary. This enabled two opti-\nmizations: first, with more relations obtained from sieving,\nwe eventually obtain a larger database of known logs, which\nmakes the descent faster. Second, more sieving relations also\nyield a smaller linear algebra step, which is desirable because\nsieving is much easier to parallelize than linear algebra.\nFor the polynomial selection and sieving steps, we used\n\nidle time on 2000–3000 CPU cores in parallel, of which most\nCPUs were Intel Sandy Bridge. Polynomial selection ran\nfor about 3 hours, which in total corresponds to 7,600 core-\nhours. Sieving ran for 15 hours, corresponding to 21,400\ncore-hours. This sufficed to collect 40,003,519 relations of\nwhich 28,372,442 were unique, involving 15,207,865 primes\nof at most 27 bits (hence bound B from §2 is 227).\nFrom this data set, we obtained a square matrix with\n\n2,157,378 rows and columns, with 113 nonzero coefficients per\nrow on average. We solved the corresponding linear system on\na 36-node cluster with two 8-core Intel Xeon E5-2650 CPUs\nper node, connected with Infiniband FDR. We used the block\nWiedemann algorithm [11,49] with parameters m = 18 and\nn = 6. Using the unoptimized implementation from CADO-\nNFS [1] for linear algebra over GF(p), the computation\nfinished in 120 hours, corresponding to 60,000 core-hours.\nWe expect that optimizations could bring this cost down by\nat least a factor of three.\nIn total, the wall-clock time for each precomputation was\n\nslightly over one week. Each resulting database of known\nlogs for the descent occupies about 2.5 GB in ASCII format.\n\nDescent Once this precomputation was finished, we were\nable to run the final descent step to compute individual dis-\ncrete logs in about a minute for targets in each of these groups.\nIn order to save time on individual computations, we imple-\nmented a client-server architecture using the ZeroMQ mes-\nsaging library. The server maintains the precomputed data\nin RAM and returns logs for values passed to it by clients.\nWe implemented the descent calculation in a mix of Python\n\nand C. The first and second stages are parallelized and run\nsieving in C, and the final discrete log is deduced in Python.\nWe ran the server on a machine with two 18-core Intel Xeon\nE5-2699 CPUs and 128 GB of RAM. On average, computing\nindividual logs took about 70 seconds, but the time varied\nfrom 34 to 206 seconds (see Fig. 3). This is divided between\nabout 20 seconds for descent initialization and the remainder\non the middle phase. Further optimizations—such as more\neffective parallelization on the middle phase or additional\nsieving—should bring the median time well below a minute.\nFor purposes of comparison, a single 512-bit RSA factor-\n\nization using the CADO-NFS implementation takes about\neight days of wall-clock time on the computer used for the\ndescent, and about three hours parallelized across 1,800 cores\nof Amazon EC2 c4.8xlarge instances.\n\n30 60 90 120 150\n\n0\n\n0.5\n\n1\n\nSeconds\n\nC\nD\nF\nof\n\nke\ny\ns\n\nFigure 3: Individual discrete log time for 512-bit DH.\nAfter a week-long precomputation for each of the two top\nexport-grade primes (see Table 1), we can quickly break\nany key exchange that uses them. Here we show times for\ncomputing 3,500 individual logs; the median is 70 seconds.\n\n3.4 Active Attack Implementation\nWe implemented a man-in-the-middle network attacker\n\nthat sits between a TLS client (web browser) and any server\nthat supports DHE_EXPORT and uses the most common 512-\nbit Apache group. Our implementation follows the message\nsequence in Figure 2: it downgrades the connection towards\nthe server, computes the session keys, and takes over the\nconnection towards the client by impersonating the server.\nThe main challenge is to compute the shared secret gab\n\nbefore the handshake completes in order to forge a Finished\nmessage from the server. With our descent implementation,\nthe computation takes an average of 70 seconds, but there\nare several ways an attacker can work around this delay:\nNon-browser clients. Different TLS clients impose different\ntime limits for the handshake, after which they kill the\nconnection. Command-line clients such as curl and git\noften run unattended, so they have long or no timeouts, and\nwe can hijack their connections without difficulty.\nTLS warning alerts. Web browsers tend to have shorter\ntimeouts, but we can keep their connections alive by sending\nTLS warning alerts, which are ignored by the browser but\nreset the handshake timer. For example, this allows us to keep\nFirefox’s TLS connections alive indefinitely. (Other browsers\nwe tested close the connection after a minute.) Although\nthe victim connection still takes much longer than usual,\nthe attacker might choose to compromise a request for a\nbackground resource that does not delay rendering the page.\nEphemeral key caching. Many TLS servers do not use a\nfresh value b for each connection, but instead compute gb\n\nonce and reuse it for multiple negotiations. Without enabling\nthe SSL_OP_SINGLE_DH_USE option, OpenSSL will reuse gb\n\nfor the lifetime of a TLS context. While both Apache and\nNginx internally apply this option, certain load balancers,\nsuch as stud [48], do not. The F5 BIG-IP load balancers\nand hardware TLS frontends will reuse gb unless the “Single\nDH” option is checked [53]. Microsoft Schannel caches gb for\ntwo hours—this setting is hard-coded. For these servers, an\nattacker can compute the discrete log of gb from one connec-\ntion and use it to attack later handshakes, avoiding the need\nto do the computation online. By randomly sampling IPv4\nhosts serving browser-trusted certificates that support DHE,\nwe found that 17% reused gb at least once over the course\nof 20 handshakes, and that 15% only used one value. How-\never, for DHE_EXPORT, only 0.1% reused gb, likely because\nMicrosoft IIS does not support 512-bit export ciphersuites.\n\n5\n\n\n\nTLS False Start. Even when clients enforce shorter time-\nouts and servers do not reuse values for b, the attacker can\nstill break the confidentiality of user requests if the client\nsupports the TLS False Start extension [30]. This extension\nreduces connection latency by having the client send early\napplication data (such as an HTTP request) without waiting\nfor the server’s Finished message to arrive. Recent versions\nof Chrome, Internet Explorer, and Firefox implement False\nStart, but their policies on when to enable it vary between\nversions. Firefox 35, Chrome 41, and Internet Explorer (Win-\ndows 10) send False Start data with DHE. In these cases, a\nman-in-the-middle can record the handshake and decrypt the\nFalse Start payload at leisure. We note that this initial data\nsent by a browser often contains sensitive user authentication\ninformation, such as passwords and cookies.\n\n3.5 Other Weak and Misconfigured Groups\nIn our scans, we found several other exploitable security\n\nissues in the DHE configurations used by TLS servers.\n512-bit primes in non-export DHE We found 2,631\nservers with browser-trusted certificates (and 118 in the\nTop 1M domains) that used 512-bit or weaker primes for\nnon-export DHE. In these instances, active attacks may\nbe unnecessary. If a browser negotiates a DHE ciphersuite\nwith one of these servers, a passive eavesdropper can later\ncompute the discrete log and obtain the TLS session keys\nfor the connection. An active attack may still be necessary\nwhen the client’s ordering of ciphersuites would result in the\nserver not selecting DHE. In this case, as in the DHE_EXPORT\ndowngrade attack, an active attacker can force the server to\nchoose a vulnerable DHE ciphersuite.\nAs a proof-of-concept, we implemented a passive eaves-\n\ndropper for regular DHE connections and used it to decrypt\ntest connections to www.fbi.gov. Until April 2015, this server\nused the default 512-bit DH group from OpenSSL, which\nwas the third group for which we performed the NFS pre-\ncomputation. The website no longer supports DHE.\nAttacks on composite-order subgroups Failure to\ngenerate Diffie-Hellman primes according to best practices\ncan result in devastating attacks. Not every TLS server\nuses “safe” primes. Out of approximately 70,000 distinct\nprimes seen across both export and non-export TLS scans,\n4,800 were not safe, meaning that (p− 1)/2 was composite.\n(Incidentally, we also found 9 composite p.) These groups\nare not necessarily vulnerable, as long as g generates a group\nwith at least one sufficiently large subgroup order to rule out\nthe Pohlig-Hellman algorithm as an attack.\nIn some real-life configurations, however, choosing such\n\nprimes can lead to an attack. For efficiency reasons, some\nimplementations use ephemeral keys gx with a short exponent\nx; commonly suggested sizes for x are as small as 160 or 224\nbits, intended to match the estimated strength of a 1024- or\n2048-bit group. For safe p, such exponent lengths are not\nknown to decrease security, as the most efficient attack will\nbe the Pollard lambda algorithm. But if the order of the\nsubgroup generated by g has small factors, they can be used\nto recover information about exponents. From a subset of\nfactors {qe1\n\n1 . . . q\nek\nk } with\n\n∏\ni\nqei\n\ni = z, Pohlig-Hellman can\nrecover x mod z in time\n\n∑\ni\nei\n√\n\nqi. If x ≤ z, this suffices to\nrecover x. If not, Pollard lambda can use this information\nto recover x in time\n\n√\nx/z. This attack was first described\n\nas hypothetical by van Oorschot and Wiener [51].\n\nTo see if TLS servers in the wild were vulnerable to this\nattack, we tested various non-safe primes found in our scans.\nFor each non-safe prime p, we opportunistically factored\np− 1 using Bernstein’s batch method [5]. We then ran the\nGMP-ECM implementations of the Pollard p− 1 algorithm\nand the ECM factoring methods [54] for 5 days parallelized\nacross 28 cores and discovered 36,447 prime factors.\nWe then examined the generators g used with each prime p.\n\nWe classified a tuple (p, g, y) sent by a server as interesting\nif the prime factorization of p− 1 had revealed prime factors\nof the order of g, and ordered them by the estimated work\nrequired using Pohlig-Hellman and Pollard lambda to recover\na target private exponent x of length ranging from 64 to 256\nbits. There were 753 (p, g) pairs where we knew factors of\nthe subgroup generated by g; these had been used for 40,903\nconnections across all of our scans.\nWe implemented the van Oorschot andWiener algorithm in\n\nSage [47] using a parallel Pollard rho implementation that we\nwrote in C using the GMP library. We used the distinguished\npoints method for collision detection; for a prime known in\nadvance, this implementation can be arbitrarily sped up by\nprecomputing a table of distinguished points.\nWe computed partial information about the server secret\n\nexponent used in 460 exchanges and were able to recover\nthe whole exponent used by 159 different hosts, 53 of which\nauthenticated with valid browser-trusted certificates. In all\ncases, the vulnerable hosts used 512-bit prime moduli; three\nof them used 160-bit exponents and the rest used 128 bits.\nThe order of the largest-order subgroup ranged from 46 bits\n(which finishes in seconds) to 81 bits (which took between\n50 and 176 hours) implementation. The Pollard lambda\ncalculations used interval width varying from 40 to 70 bits.\nOur computations would have allowed us to hijack con-\n\nnections to a variety of vulnerable TLS servers, including\nweb interfaces for VPN devices (48 hosts), communications\nsoftware (21 hosts), web conferencing servers (27 hosts), and\nFTP servers (6 hosts). As a proof-of-concept, we modified\nour man-in-the-middle attacker of §3.3 to impersonate a\nvulnerable server and capture user credentials. Compared\nto an attack using NFS, we could compute the discrete log\nwith a delay hardly noticeable for browser users.\nMisconfigured groups The Digital Signature Algorithm\n(DSA) [38] uses primes p such that p− 1 has a large prime\nfactor q and g generates only a subgroup of order q. When\nusing properly generated DSA parameters, these groups are\nsecure for use in Diffie-Hellman key exchanges. Notably, DSA\ngroups are hard-coded in Java’s sun.security.provider\npackage and are used by default in many Java-based TLS\nservers. However, some servers in our scans used Java’s DSA\nprimes as p but mistakenly used the DSA group order q in the\nplace of the generator g. We found 5,741 hosts misconfigured\nthis way.\nThis substitution of q for g is likely due to a usability prob-\n\nlem: the canonical ASN.1 representation of Diffie-Hellman\nkey exchange parameters (coming from PKCS#3) is a se-\nquence (p, g), while that of DSA parameters (coming from\nPKIX) is (p, q, g); we conjecture that the confusion between\nthese formats led to a simple programming error.\nIn a DSA group, the subgroup generated by q is likely\n\nto have many small prime factors in its order, since for p\ngenerated according to [38], (p − 1)/q is a random integer.\nFor Java’s sun.security.provider 512-bit prime, using q as\na generator leaks 290 bits of information about exponents at\n\n6\n\nwww.fbi.gov\n\n\na cost of roughly 240 operations. Luckily, since the provider\ngenerates exponents of length max(n/2, 384) for n-bit p,\nthis does not suffice to recover a full exponent. Still, this\nmisconfiguration bug results in a significant loss of security\nand serves as a cautionary tale for programmers.\n\n4. STATE-LEVEL THREATS TO DH\nThe previous sections demonstrate the existence of practi-\n\ncal attacks against Diffie-Hellman key exchange as currently\nused by TLS. However, these attacks rely on the ability to\ndowngrade connections to export-grade crypto or on the use\nof unsafe parameters. In this section we address the following\nquestion: how secure is Diffie-Hellman in broader practice,\nas used in other protocols that do not suffer from downgrade,\nand when applied with stronger groups?\nTo answer this question we must first examine how the\n\nnumber field sieve for discrete log scales to 768- and 1024-bit\ngroups. As we argue below, 768-bit groups, which are still in\nrelatively widespread use, are now within reach for academic\ncomputational resources, and performing precomputations\nfor a small number of 1024-bit groups is plausibly within\nthe resources of state-level attackers. The precomputation\nwould likely require special-purpose hardware, but would not\nrequire any major algorithmic improvements beyond what is\nknown in the academic literature. We further show that even\nin the 1024-bit case, the descent time—necessary to solve\nany specific discrete log instance within a common group—\nwould be fast enough to break individual key exchanges in\nclose to real time.\nIn light of these results, we examine several standard Inter-\n\nnet security protocols—IKE, SSH, and TLS—to determine\nthe vulnerability of their key exchanges to attacks by resource-\nful attackers. Although the cost of the precomputation for a\n1024-bit group is several times higher than for an RSA key\nof equal size, we observe that a one-time investment could be\nused to attack millions of hosts, due to widespread reuse of\nthe most common Diffie-Hellman parameters. Unfortunately,\nour measurements also indicate that it may be very difficult\nto sunset the use of fixed 1024-bit Diffie-Hellman groups that\nhave long been embedded in standards and implementations.\nFinally, we apply this new understanding to a set of re-\n\ncently published documents leaked by Edward Snowden [46]\nto evaluate the hypothesis that the National Security Agency\nhas already implemented such a capability. We show that\nthis hypothesis is consistent with the published details of\nthe intelligence community’s cryptanalytic capabilities, and,\nindeed, matches the known capabilities more closely than\nother proposed explanations, such as novel breaks on RC4\nor AES. We believe that this analysis may help shed light\non unanswered questions about how NSA may be gaining\naccess to VPN, SSH, and TLS traffic.\n\n4.1 Scaling NFS to 768- and 1024-bit DH\nEstimating the cost for discrete log cryptanalysis at longer\n\nkey sizes is far from straightforward, due in part to the\ncomplexity of parameter tuning and to tradeoffs between the\nsieving and linear algebra steps, which have very different\ncomputational characteristics. (Much more attention has\ngone to understanding 1024-bit factorization, but, even there,\nmany published estimates are crude extrapolations of the\nasymptotic complexity.) We attempt estimates for 768- and\n1024-bit discrete log based on the existing literature and\nour own experiments, but further work is needed for greater\n\nconfidence, particularly for the 1024-bit case. We summarize\nall the costs, measured or estimated, in Table 2.\nDH-768: Feasible with academic power For the 768-\nbit case, we base our estimates on the recent discrete log\nrecord at 596 bits [8] and the integer factorization record of\n768 bits from 2009 [29]. While the algorithms for factorization\nand discrete log are similar, the discrete log linear algebra\nstage is many times more difficult, as the matrix entries are\nno longer Boolean. We can reduce overall time by sieving\nmore, thus generating a smaller input matrix to the linear\nalgebra step. Since sieving parallelizes better than linear\nalgebra, this tradeoff is desirable for large inputs.\nA 596-bit factorization takes about 5 core-years, most\n\nof it spent on sieving. In comparison, the record 596-bit\ndiscrete log effort tuned parameters such that they spent\n50 core-years on sieving. This reduced their linear algebra\ncalculation to 80 core-years. We used this same strategy in\nour 512-bit experiments in §3.3.\nSimilarly, the 768-bit RSA factoring record spent more\n\ntime on sieving in order to save time on the linear algebra\nstep. The cost of sieving was around 1500 core-years, and\nthe matrix that was produced had 200M rows and columns.\nAs a result, the linear algebra took 150 core-years, but tak-\ning algorithmic improvements since 2009 into account and\noptimizing for the total time,3 we estimate that factoring an\nRSA-768 integer would take 900 core-years in total.\nFor a 768-bit discrete log, we can expect that ten times as\n\nmuch sieving as the RSA case would reduce the matrix to\naround 150M rows. We extrapolate from experiments with\nexisting software that this linear algebra would take 28,500\ncore-years, for a total of 36,500 core-years. This is within\nreach by computing power available to academics.\nThe descent step takes relatively little time. We experi-\n\nmented with both CADO-NFS and a new implementation\nwith GMP-ECM based on the early-abort strategy described\nin [6]. Using these techniques, the initial descent phase took\nan average of around 1 core-day. The remaining phase uses\nsieving much as in the precomputation; extrapolating from\nexperiments, the rest of the descent should take at most\n1 core-day. In total, after precomputation, the cost of a\nsingle 768-bit discrete log computation is around 2 core-days\nand is easily parallelizable.\nDH-1024: Plausible with state-level resources Ex-\nperimentally extrapolating sieving parameters to the 1024-bit\ncase is difficult due to the tradeoffs between the steps of the\nalgorithm and their relative parallelism. The prior work\nproposing parameters for factoring a 1024-bit RSA key is\nthin: [28] proposes smoothness bounds of 42 bits, but the\nproposed value of the sieving region parameter I is clearly\ntoo small, giving too few smooth results per sieving sub-\ntask. Since no publicly available software can currently deal\nwith values of I larger than those proposed, we could not\nexperimentally update the estimates of this paper with more\nrelevant parameter choices.\nWithout better parameter choices, we resort to extrapolat-\n\ning from asymptotic complexity. For the number field sieve,\nthe complexity is exp\n\n(\n(k + o(1))(log N)1/3(log log N)2/3),\n\nwhere N is the integer to factor or the prime modulus for\ndiscrete log, and k is an algorithm-specific constant. This\nformula is inherently imprecise, since the o(1) in the expo-\n3We would lower the smoothness bounds compared to the\nparameters in [29].\n\n7\n\n\n\nSieving Linear Algebra Descent\nI log2 B core-years rows core-years core-time\n\nRSA-512 14 29 0.5 4.3M 0.33 Timings with default CADO-NFS parameters.\nDH-512 15 27 2.5 2.1M 7.7 10mins For the computations in this paper; may be suboptimal.\n\nRSA-768 16 37 800 250M 100 Est. based on [29] with less sieving.\nDH-768 17 35 8,000 150M 28,500 2 days Est. based on [8, 29] and our own experiments.\n\nRSA-1024 18 42 1,000,000 8.7B 120,000 Est. based on complexity formula.\nDH-1024 19 40 10,000,000 5.2B 35,000,000 30 days Est. based on complexity formula and our experiments.\n\nTable 2: Estimating costs for factoring and discrete log. For sieving, we give two important parameters: the number of\nbits of the smoothness bound B and the sieving region parameter I. For linear algebra, all costs for DH are for safe primes; for\nDSA primes with q of 160 bits, this should be divided by 6.4 for 1024 bits, 4.8 for 768 bits, and 3.2 for 512 bits.\n\nnent can hide polynomial factors. This complexity formula,\nwith k = 1.923, describes the overall time for both discrete\nlog and factorization, which are both dominated by sieving\nand linear algebra in the precomputation. The space com-\nplexity (the size of the matrix in memory) is the square root\nof this function, i.e., the same function, taking k = 0.9615.\nDiscrete log descent has a complexity of the same form as\nwell; [2, Chapter 4] gives k = 1.232, using an early-abort\nstrategy similar to the one in [6] mentioned above.\nEvaluating the formula for 768- and 1024-bit N gives us\n\nestimated multiplicative factors by which time and space will\nincrease from the 768- to the 1024-bit case. For precompu-\ntation, the total time complexity will increase by a factor\nof 1220, while space complexity will increase by a factor of\n35. These are valid for both factorization and discrete log,\nsince they have the same asymptotic behavior. Hence, for\nDH-1024, we get a total cost for the precomputation of about\n45M core-years. The time complexity for each individual\nlog after the precomputation should be multiplied by 95.\nThis last number does not correspond to what we observed\nin practice; we attribute that to the fact that the descent\nstep has been far less studied both in theory and in practice\ncompared to the other steps.\nFor 1024-bit descent, we experimented with our early-\n\nabort implementation to inform our estimates for descent\ninitialization, which should dominate the individual discrete\nlog computation. For a random target in Oakley Group 2,\ninitialization took 22 core-days, yielding a few primes of at\nmost 130 bits to be descended further. In twice this time,\nwe reached primes of about 110 bits. At this point, we were\ncertain to have bootstrapped the descent, and could continue\ndown to the smoothness bound in a few more core-days if\nproper sieving software were available. Thus we estimate\nthat a 1024-bit descent would take about 30 core-days, once\nagain easily parallelizable.\n\nCosts in hardware Although 45M core-years is a huge\ncomputational effort, it is not necessarily out of reach for a\nnation state. Moreover, at this scale, significant cost savings\ncould be realized by developing application-specific hardware.\nSieving is a natural target for hardware implementation.\n\nTo our knowledge, the best prior description of an ASIC\nimplementation of 1024-bit sieving is the 2007 work of Geisel-\nmann and Steinwandt [18]. In the following, we update their\nestimates for modern techniques and adjust parameters for\ndiscrete log. We increase their chip count by a factor of ten to\nsieve more and save on linear algebra as above, giving an esti-\nmate of 3M chips to complete sieving in one year. Shrinking\nthe dies from the 130 nm technology node used in the paper to\n\na more modern size reduces costs, as transistors are cheaper\nat newer technologies. With standard transistor costs and uti-\nlization, this would cost about $2 per chip to manufacture, af-\nter fixed design and tape-out costs of roughly $2M [32]. This\nsuggests that an $8M investment would buy enough ASICs\nto complete the DH-1024 sieving precomputation in one year.\nSince a step of descent uses sieving, the same hardware could\nlikely be reused to speed calculations of individual logs.\nEstimating the financial cost for the linear algebra is more\n\ndifficult, since there has been little work on designing chips\nthat are suitable for the larger fields involved in discrete log.\nTo derive a rough estimate, we can begin with general purpose\nhardware and the core-year estimate from Table 2. The\nTitan supercomputer [39]—at 300,000 CPU cores, currently\nthe most powerful supercomputer in the U.S.—would take\n117 years to complete the 1024-bit linear algebra stage. Titan\nwas constructed in 2012 for $94M, suggesting a cost of $11B\nin supercomputers to finish this step in a year. In the context\nof factorization, moving linear algebra from general purpose\nCPUs to ASICs has been estimated to reduce costs by a\nfactor of 80 [17]. If we optimistically assume that a similar\nreduction can be achieved for discrete log, the hardware cost\nto perform the linear algebra for DH-1024 in one year is\nplausibly on the order of hundreds of millions of dollars.\nTo put this dollar figure in context, the FY2012 bud-\n\nget for the U.S. Consolidated Cryptologic Program (which\nincludes the NSA) was $10.5 billion4 [57]. The agency’s\nclassified 2013 budget request, which prioritized investment\nin “groundbreaking cryptanalytic capabilities to defeat ad-\nversarial cryptography and exploit internet traffic,” included\nnotable $100M increases in two programs [57]: “cryptanalytic\nIT services” (to $247M), and a cryptically named “cryptanal-\nysis and exploitation services program C” (to $360M). NSA’s\nleaked strategic plan for the period called for it to “continue\nto invest in the industrial base and drive the state of the\nart for high performance computing to maintain pre-eminent\ncryptanalytic capability for the nation” [63].\n\n4.2 Is NSA Breaking 1024-bit DH?\nOur calculations suggest that it is plausibly within NSA’s\n\nresources to have performed number field sieve precomputa-\ntions for at least a small number of 1024-bit Diffie-Hellman\ngroups. This would allow them to break any key exchanges\nmade with those groups in close to real time. If true, this\nwould answer one of the major cryptographic questions raised\nby the Edward Snowden leaks: How is NSA defeating the\nencryption for widely used VPN protocols?\n4The National Science Foundation’s budget was $7 billion.\n\n8\n\n\n\nClassified documents published by Der Spiegel [46] indi-\ncate that NSA is passively decrypting IPsec connections at\nsignificant scale. The documents do not describe the crypt-\nanalytic techniques used, but they do provide an overview of\nthe attack system architecture. After reviewing how IPsec\nkey establishment works, we will use the published informa-\ntion to evaluate the hypothesis that the NSA is leveraging\nprecomputation to calculate discrete logs at scale.\nIKE Internet Key Exchange (IKE) is the main key es-\ntablishment protocol used for IPsec VPNs. There are two\nversions, IKEv1 [22] and IKEv2 [25], which differ in mes-\nsage structure but are conceptually similar. For the sake of\nbrevity, we will use IKEv1 terminology.\nEach IKE session begins with a Phase 1 handshake, in\n\nwhich the client and server select a Diffie-Hellman group\nfrom a small set of standardized parameters and perform a\nkey exchange to establish a shared secret. The shared secret\nis combined with other cleartext values transmitted by each\nside, such as nonces and cookies, to derive a value called\nSKEYID. IKE provides several authentication mechanisms,\nincluding symmetric pre-shared keys (PSK); when IKEv1 is\nauthenticated with a PSK, this value is incorporated into\nthe derivation of SKEYID.\nThe resulting SKEYID is used to encrypt and authenticate\n\na Phase 2 handshake. Phase 2 establishes the parameters\nand key material, KEYMAT, for a cryptographic transport\nprotocol used to protect subsequent traffic, such as Encapsu-\nlating Security Payload (ESP) [27] or Authenticated Header\n(AH) [26]. In some circumstances, this phase includes an\nadditional round of Diffie-Hellman. Ultimately, KEYMAT is\nderived from SKEYID, additional nonces, and the result of\nthe optional Phase 2 Diffie-Hellman exchange.\nNSA’s VPN exploitation process The documents pub-\nlished by Der Spiegel describe a system named TURMOIL\nthat is used to collect and decrypt VPN traffic. The evidence\nindicates that this decryption is performed using passive\neavesdropping and does not require message injection or\nman-in-the-middle attacks on IPsec or IKE. Figure 4, an\nexcerpt from one of the documents [67], illustrates the flow\nof information through the TURMOIL system\nThe initial phases of the attack involve collecting IKE and\n\nESP payloads and determining whether the traffic matches\nany tasked selector [65]. If so, TURMOIL transmits the\ncomplete IKE handshake and may transmit a small amount\nof ESP ciphertext to NSA’s Cryptanalysis and Exploitation\nServices (CES) [56,65] via a secure tunnel. Within CES, a\nspecialized VPN Attack Orchestrator (VAO) system manages\na collection of high-performance grid computing resources\nlocated at NSA Headquarters and in a data center at Oak\nRidge National Laboratory, which perform the computation\nrequired to generate the ESP session key [61,62,67]. VAO\nalso maintains a database, CORALREEF, that stores cryp-\ntographic values, including a set of known PSKs and the\nresulting “recovered” ESP session keys [60,61,67].\nThe ESP traffic itself is buffered for up to 15 minutes [64],\n\nuntil CES can respond with the recovered ESP keys if they\nwere generated correctly. Once keys have been returned, the\nESP traffic is decrypted via hardware accelerators [59] or\nin software [68,69]. From this point, decrypted VPN traffic\nis reinjected into TURMOIL processing infrastructure and\npassed to other systems for storage and analysis [69]. The\ndocuments indicate that NSA is recovering ESP keys at large\nscale, with a target of 100,000 per hour [64].\n\nFigure 4: NSA’s VPN decryption infrastructure. This\nclassified illustration published by Der Spiegel [67] shows\ncaptured IKE handshake messages being passed to a high-\nperformance computing system, which returns the symmetric\nkeys for ESP session traffic. The details of this attack are\nconsistent with an efficient break for 1024-bit Diffie-Hellman.\n\nEvidence for a discrete log attack While the ability\nto decrypt VPN traffic does not by itself indicate a defeat\nof Diffie-Hellman, there are several features of IKE and the\nVAO’s operation that support this hypothesis.\nThe IKE protocol has been extensively analyzed [9, 36],\n\nand is not believed to be exploitable in standard configu-\nrations under passive eavesdropping attacks. In order to\nrecover the session keys for the ESP or AH protocols, the\nattacker must at minimum recover the SKEYID generated\nby the Phase 1 exchange. Absent a vulnerability in the key\nderivation function or transport encryption, this requires\nthe attacker to recover a Diffie-Hellman shared secret after\npassively observing an IKE handshake.\nWhile IKE is designed to support a range of Diffie-Hellman\n\ngroups, our Internet-wide scans (§4.3) show that the vast\nmajority of IKE systems select one particular 1024-bit DH\ngroup, Oakley Group 2, even when offered stronger groups.\nGiven an efficient oracle for solving the discrete logarithm\n\nproblem, attacks on IKE are possible provided that the\nattacker can obtain the following: (1) a complete two-sided\nIKE transcript, including the Diffie-Hellman ephemeral keys\nga and gb as well as the nonces and cookies transmitted by\nboth sides of the connection, and (2) in IKEv1 only, the PSK\nused in deriving SKEYID.\nBoth of the above requirements are also present in the\n\nNSA’s VPN attack system. As Figure 4 illustrates, a hard\nrequirement of the VAO is the need to obtain the complete\ntwo-sided IKE transcript [60]. The published documents\nindicate that this requirement substantially increases the\ncomplexity of the attack execution, since IKE transcripts\nmust be reassembled (“paired”) whenever the interaction\ntraverses multiple network paths [55,56,58,66].\nThe attack system also seems to require knowledge of the\n\nPSK. Several documents describe techniques for analysts\nto locate a PSK, including using a database of router con-\nfigurations [70, 71], the CORALREEF database of known\nPSKs [60], previously decrypted SSH traffic [60], or system\nadministrator “chatter” [70]. Additionally, NSA is willing to\n“[r]un attacks to recover PSK” [60].\n\nOf course, this explanation is not dispositive. The possi-\nbility remains that NSA could defeat IPsec using alternative\nmeans. Certain published NSA documents refer to soft-\nware “implants” on VPN devices, indicating that the use of\n\n9\n\n\n\nVulnerable servers, if the attacker can precompute for . . .\nall 512-bit groups all 768-bit groups one 1024-bit group ten 1024-bit groups\n\nHTTPS Top 1M w/ active downgrade 45,100 (8.4%) 45,100 (8.4%) 205,000 (37.1%) 309,000 (56.1%)\nHTTPS Top 1M 118 (0.0%) 407 (0.1%) 98,500 (17.9%) 132,000 (24.0%)\nHTTPS Trusted w/ active downgrade 489,000 (3.4%) 556,000 (3.9%) 1,840,000 (12.8%) 3,410,000 (23.8%)\nHTTPS Trusted 1,000 (0.0%) 46,700 (0.3%) 939,000 (6.56%) 1,430,000 (10.0%)\n\nIKEv1 IPv4 – 64,700 (2.6%) 1,690,000 (66.1%) 1,690,000 (66.1%)\nIKEv2 IPv4 – 66,000 (5.8%) 726,000 (63.9%) 726,000 (63.9%)\n\nSSH IPv4 – – 3,600,000 (25.7%) 3,600,000 (25.7%)\n\nTable 3: Estimated impact of Diffie-Hellman attacks. We use Internet-wide scanning to estimate the number of real-\nworld servers for which typical connections could be compromised by attackers with various levels of computational resources.\nFor HTTPS, we provide figures with and without downgrade attacks on the chosen ciphersuite. All others are passive attacks.\n\ntargeted malware is a piece of the collection strategy [60];\nhowever, the same documents also note that decryption of\nthe resulting traffic does not require IKE handshakes, and\nthus appears to be an alternative mechanism to the VAO\nattack described above. The most compelling argument for\na pure cryptographic attack is the generality of the VAO\napproach, which appears to succeed across a broad swath of\nnon-compromised devices.\n\n4.3 Effects of a 1024-bit Break\nIn this section, we use Internet-wide scanning to assess\n\nthe impact of a hypothetical DH-1024 break on three popu-\nlar protocols: IKE, SSH, and HTTPS. Our measurements\nindicate that these protocols, as they are commonly used,\nwould be subject to widespread compromise by a state-level\nattacker who had the resources to invest in precomputation\nfor a small number of common 1024-bit groups.\nIKE We measured how IPsec VPNs use Diffie-Hellman in\npractice by scanning a 1% random sample of the public IPv4\naddress space for IKEv1 and IKEv2 (the protocols used to\ninitiate an IPsec VPN connection) in May 2015. We used\nthe ZMap UDP probe module to measure support for Oakley\nGroups 1 and 2 (two popular 768- and 1024-bit, built-in\ngroups) and which group servers prefer. To test support\nfor individual groups, we offered only the single group in\nquestion. To detect default behavior, we offered servers a\nvariety of DH groups, with the lowest priority groups being\nOakley Groups 1 and 2. When measuring server preference,\nwe scanned with the 3DES symmetric cipher—the most\ncommonly supported symmetric cipher in our single group\nscans. Because of this, the percentages we present for IKEv1\nand IKEv2 are a lower bound for the number of servers that\nprefer Oakley Groups 1 and 2.\nOf the 80K hosts that responded with a valid IKE packet,\n\n44.2% were willing to accept an offered proposal from at least\none scan. The majority of the remaining hosts responded\nwith a NO-PROPOSAL-CHOSEN message regardless of our pro-\nposal. Many of these may be site-to-site VPNs that reject\nour source address. We consider these hosts “unprofiled” and\nomit them from the results here.\nWe found that 31.8% of IKEv1 and 19.7% of IKEv2 servers\n\nsupport Oakley Group 1 (768-bit) while 86.1% and 91.0%\nrespectively supported Oakley Group 2 (1024-bit). In our\nsample of IKEv1 servers, 2.6% of profiled servers preferred\nthe 768-bit Oakley Group 1—which is within cryptanalytic\nreach today for moderately resourced attackers—and 66.1%\npreferred the 1024-bit Oakley Group 2. For IKEv2, 5.8%\n\nof profiled servers chose Oakley Group 1, and 63.9% chose\nOakley Group 2. This coincides with our anecdotal findings\nthat most VPN clients only offer Oakley Group 2 by default.\nSSH All SSH handshakes complete either a finite field\nDiffie-Hellman or elliptic curve Diffie-Hellman exchange as\npart of the SSH key exchange. The SSH protocol explicitly\ndefines support for Oakley Group 2 (1024-bit) and Oakley\nGroup 14 (2048-bit) but also allows a server-defined group,\nwhich can be negotiated through an auxiliary Diffie-Hellman\nGroup Exchange (DH-GEX) handshake [16].\nIn order to measure how SSH uses DH in practice, we\n\nimplemented the SSH protocol in the ZMap toolchain and\nscanned 1% random samples of the public IPv4 address space\nin April 2015. We find that 98.9% of SSH servers support\nthe 1024-bit Oakley Group 2, 77.6% support the 2048-bit\nOakley Group 14, and 68.7% support DH-GEX.\nDuring the SSH handshake, the client and server select the\n\nclient’s highest priority mutually supported key exchange\nalgorithm. Therefore, we cannot directly measure what algo-\nrithm servers will prefer in practice. In order to estimate this,\nwe performed a scan in which we mimicked the algorithms\noffered by OpenSSH 6.6.1p1, the latest version of OpenSSH.\nIn this scan, 21.8% of servers preferred the 1024-bit Oakley\nGroup 2, and 37.4% preferred a server-defined group. 10% of\nthe server-defined groups were 1024-bit, but, of those, near\nall provided Oakley Group 2 rather than a custom group.\nCombining these equivalent choices, we find that a state-\n\nlevel attacker who performed NFS precomputations for the\n1024-bit Oakley Group 2 (which has been in standards for\nalmost two decades) could passively eavesdrop on connections\nto 3.6M (25.7%) publicly accessible SSH servers.\nHTTPS DHE is commonly deployed on web servers. 68.3%\nof Alexa Top 1M sites support DHE, as do 23.9% of sites\nwith browser-trusted certificates. Of the Top 1M sites that\nsupport DHE, 84% use a 1024-bit or smaller group, with 94%\nof these using one of five groups.\nDespite widespread support for DHE, a passive eavesdrop-\n\nper can only decrypt connections that organically agree to\nuse Diffie-Hellman. We can estimate the number of sites for\nwhich this will occur by offering the same sets of ciphersuites\nas Chrome, Firefox, and Safari. While the offered ciphers\ndiffer slightly between browsers, this turns out to result in\nnegligible differences in whether DHE is chosen.\nApproximately 24.0% of browser connections with HTTPS-\n\nenabled Top 1M sites (and 10% with browser-trusted sites)\nwill negotiate DHE with one of the ten most popular 1024-bit\nprimes; 17.9% of connections with Top 1M sites could be\n\n10\n\n\n\npassively eavesdropped given the precomputation for a single\n1024-bit prime. The most popular site that negotiates a\nDHE ciphersuite using one of the two most common 1024-bit\nprimes is sohu.com (ranked 31st globally).\nMail TLS is also used to secure email transport. SMTP,\nthe protocol used to relay messages between mail servers,\nallows a connection to be upgraded to TLS by issuing the\nSTARTTLS command. POP3S and IMAPS, used by end users\nto fetch received mail, wrap the entire connection in TLS.\nWe studied 1% samples of the public IPv4 address space\n\nfor IMAPS, POP3S, and SMTP+StartTLS. We found that\n50.7% of SMTP servers supported STARTTLS, 41.4% sup-\nported DHE, and 14.8% supported DHE_EXPORT ciphers.\n15.5% of SMTP servers used one of the ten most common\n1024-bit groups.\n\nFor IMAPS, 8.4% of servers supported DHE_EXPORT and\n75% supported DHE. However, the ten most common 1024-bit\nprimes account for only 5.4% of servers. POP3S deployment\nis similar, with 8.9% of servers supporting DHE_EXPORT\nand 74.9% supporting DHE, but with the ten most common\n1024-bit primes accounting for only 4.8% of servers.\n\nIf each of the top ten 1024-bit primes used by each protocol\nwere compromised, this would affect approximately 1.7M\nSMTP, 276K IMAPS, and 245K POP3S servers. Using our\ndowngrade attack of §3.3, an attacker with modest resources\ncan hijack connections to approximately 1.6M SMTP, 429K\nIMAPS, and 454K POP3S servers.\n\n5. RECOMMENDATIONS\nOur findings indicate that one of the key recommenda-\n\ntions from security experts in response to the threat of mass\nsurveillance—promotion of DHE-based TLS ciphersuites\noffering “perfect forward secrecy” over RSA-based cipher-\nsuites—may have actually reduced security for many hosts.\nIn this section, we present concrete recommendations to re-\ncover the expected security of Diffie-Hellman as it is used in\nmainstream Internet protocols.\nTransition to elliptic curves. Transitioning to ellip-\ntic curve Diffie-Hellman (ECDH) key exchange with appro-\npriate parameters avoids all known feasible cryptanalytic\nattacks. Current elliptic curve discrete log algorithms for\nstrong curves do not gain as much of an advantage from\nprecomputation. In addition, ECDH keys are shorter than\nin “mod p” Diffie-Hellman, and shared-secret computations\nare faster. Unfortunately, the most widely supported ECDH\nparameters, those specified by NIST, are now viewed with\nsuspicion due to NSA influence on their design, despite no\nknown or suspected weaknesses. These curves are under-\ngoing scrutiny, and new curves, such as Curve25519, are\nbeing standardized by the IRTF for use in Internet proto-\ncols. We recommend transitioning to elliptic curves where\npossible; this is the most effective long-term solution to the\nvulnerabilities described in this paper.\nIncrease minimum key strengths. Server operators\nshould disable DHE_EXPORT and configure DHE ciphersuites\nto use primes of 2048 bits or larger. Browsers and clients\nshould raise the minimum accepted size for Diffie-Hellman\ngroups to at least 1024 bits in order to avoid downgrade at-\ntacks when communicating with servers that still use smaller\ngroups. Primes of less than 1024 bits should not be con-\nsidered secure, even against an attacker with moderate re-\nsources.\n\nOur analysis suggests that 1024-bit discrete log may be\nwithin reach for state-level actors. As such, 1024-bit DHE\n(and 1024-bit RSA) must be phased out in the near term.\nNIST has recommended such a transition since 2010 [4]. We\nrecommend that clients raise the minimum DHE group size to\n2048 bits as soon as server configurations allow. Server opera-\ntors should move to 2048-bit or larger groups to facilitate this\ntransition. Precomputation for a 2048-bit non-trapdoored\ngroup is around 109 times harder than for a 1024-bit group,\nso 2048-bit Diffie-Hellman will remain secure barring a major\nalgorithmic improvement.\nAvoid fixed-prime 1024-bit groups. For implementa-\ntions that must continue to use or support 1024-bit groups\nfor compatibility reasons, generating fresh groups may help\nmitigate some of the damage caused by NFS-style precom-\nputation for very common fixed groups. However, we note\nthat it is possible to create trapdoored primes [20,44] that\nare computationally difficult to detect. At minimum, clients\nshould check that servers’ parameters use safe primes or a\nverifiable generation process, such as that proposed in FIPS\n186 [38]. Ideally, the process for generating and validating\nparameters in TLS should be standardized so as to thwart\nthe risk of trapdoors.\nDon’t deliberately weaken crypto. Our downgrade\nattack on export-grade 512-bit Diffie-Hellman groups in TLS\nillustrates the fragility of cryptographic “front doors”. Al-\nthough the key sizes originally used in DHE_EXPORT were\nintended to be tractable only to NSA, two decades of algo-\nrithmic and computational improvements have significantly\nlowered the bar to attacks on such key sizes. Despite the\neventual relaxation of crypto export restrictions and subse-\nquent attempts to remove support for DHE_EXPORT, the\ntechnical debt induced by the additional complexity has left\nimplementations vulnerable for decades. Like FREAK [7],\nour attacks warn of the long-term debilitating effects of\ndeliberately weakening cryptography.\n\n6. DISCLOSURE AND RESPONSE\nWe notified major client and server developers about\n\nthe vulnerabilities discussed in this paper before we made\nour findings public. Prior to our work, Internet Explorer,\nChrome, Firefox, and Opera all accepted 512-bit primes,\nwhereas Safari allowed groups as small as 16 bits. As a\nresult of our disclosures, Internet Explorer [37], Firefox, and\nChrome are transitioning the minimum size of the DHE groups\nthey accept to 1024 bits, and OpenSSL and Safari are ex-\npected to follow suit. On the server side, we notified Apache,\nOracle, IBM, Cisco, and various hosting providers. Aka-\nmai has removed all support for export ciphersuites. Many\nTLS developers plan to support a new extension that allows\nclients and servers to negotiate a few well-known groups of\n2048-bits and higher and to gracefully reject weak ones [19].\n\n7. CONCLUSION\nDiffie-Hellman key exchange is a cornerstone of applied\n\ncryptography, but we find that, as used in practice, it is often\nless secure than widely believed. The problems stem from\nthe fact that the number field sieve for discrete log allows an\nattacker to perform a single precomputation that depends\nonly on the group, after which computing individual logs in\nthat group has a far lower cost. Although this fact is well\nknown to cryptographers, it apparently has not been widely\n\n11\n\n\n\nunderstood by system builders. Likewise, many cryptogra-\nphers did not appreciate that the security of a large fraction\nof Internet communication depends on Diffie-Hellman key\nexchanges that use a few small, widely shared groups.\nA key lesson from this state of affairs is that cryptogra-\n\nphers and creators of practical systems need to work together\nmore effectively. System builders should take responsibility\nfor being aware of applicable cryptanalytic attacks. Cryp-\ntographers, for their part, should involve themselves in how\ncrypto is actually being applied, such as through engagement\nwith standards efforts and software review. Bridging the per-\nilous gap that separates these communities will be essential\nfor keeping future systems secure.\n\nAcknowledgments\nThe authors wish to thank Michael Bailey, Daniel Bernstein,\nRon Dreslinski, Tanja Lange, Adam Langley, Kenny Paterson,\nAndrei Popov, Ivan Ristic, Edward Snowden, Brian Smith,\nMartin Thomson, and Eric Rescorla. This material is based\nin part upon work supported by the U.S. National Science\nFoundation under contracts CNS-1345254, CNS-1409505,\nCNS-1518741, and EFRI-1441209, by the Office of Naval\nResearch under contract N00014-11-1-0470, by the ERC\nStarting Grant 259639 (CRYSP), by the French ANR re-\nsearch grant ANR-12-BS02-001-01, by the NSF Graduate\nResearch Fellowship Program under grant DGE-1256260,\nby the Mozilla Foundation, by a gift from Supermicro, by\nthe Google Ph.D. Fellowship in Computer Security, by the\nMorris Wellman Faculty Development Assistant Professor-\nship, and by an Alfred P. Sloan Foundation Research Fellow-\nship. Some experiments were conducted using the Grid’5000\ntestbed, which is supported by INRIA, CNRS, RENATER,\nand several other universities and organizations; additional\nexperiments used UCS hardware donated by Cisco.\n\n8. REFERENCES\n[1] S. Bai, C. Bouvier, A. Filbois, P. Gaudry, L. Imbert,\n\nA. Kruppa, F. Morain, E. Thomé, and P. Zimmermann.\ncado-nfs, an implementation of the number field sieve\nalgorithm, 2014. Release 2.1.1.\n\n[2] R. Barbulescu. Algorithmes de logarithmes discrets dans les\ncorps finis. PhD thesis, Université de Lorraine, France, 2013.\n\n[3] R. Barbulescu, P. Gaudry, A. Joux, and E. Thomé. A\nheuristic quasi-polynomial algorithm for discrete logarithm\nin finite fields of small characteristic. In Eurocrypt, 2014.\n\n[4] E. Barker, W. Barker, W. Burr, W. Polk, and M. Smid.\nNIST Special Publication 800-57: Recommendation for Key\nManagement, 2007.\n\n[5] D. J. Bernstein. How to find smooth parts of integers, 2004.\nhttp://cr.yp.to/factorization/smoothparts-20040510.pdf.\n\n[6] D. J. Bernstein and T. Lange. Batch NFS. In Selected Areas\nin Cryptography, 2014.\n\n[7] B. Beurdouche, K. Bhargavan, A. Delignat-Lavaud,\nC. Fournet, M. Kohlweiss, A. Pironti, P.-Y. Strub, and J. K.\nZinzindohoue. A messy state of the union: Taming the\ncomposite state machines of TLS. In IEEE Symposium on\nSecurity and Privacy, 2015.\n\n[8] C. Bouvier, P. Gaudry, L. Imbert, H. Jeljeli, and E. Thomé.\nNew record for discrete logarithm in a prime finite field of\n180 decimal digits, 2014. http://caramel.loria.fr/p180.txt.\n\n[9] R. Canetti and H. Krawczyk. Security analysis of IKE’s\nsignature-based key-exchange protocol. In Crypto, 2002.\n\n[10] A. Commeine and I. Semaev. An algorithm to solve the\ndiscrete logarithm problem with the number field sieve. In\nPKC, 2006.\n\n[11] D. Coppersmith. Solving linear equations over GF(2) via\nblock Wiedemann algorithm. Math. Comp., 62(205), 1994.\n\n[12] R. Crandall and C. B. Pomerance. Prime Numbers: A\nComputational Perspective. Springer, 2001.\n\n[13] B. den Boer. Diffie-Hellman is as strong as discrete log for\ncertain primes. In Crypto, 1988.\n\n[14] W. Diffie and M. E. Hellman. New directions in\ncryptography. IEEE Trans. Inform. Theory, 22(6):644–654,\n1976.\n\n[15] Z. Durumeric, E. Wustrow, and J. A. Halderman. ZMap:\nFast Internet-wide scanning and its security applications. In\nUsenix Security, 2013.\n\n[16] M. Friedl, N. Provos, and W. Simpson. Diffie-Hellman group\nexchange for the secure shell (SSH) transport layer protocol.\nRFC 4419, Mar. 2006.\n\n[17] W. Geiselmann, H. Kopfer, R. Steinwandt, and E. Tromer.\nImproved routing-based linear algebra for the number field\nsieve. In Information Technology: Coding and Computing,\n2005.\n\n[18] W. Geiselmann and R. Steinwandt. Non-wafer-scale sieving\nhardware for the NFS: Another attempt to cope with\n1024-bit. In Eurocrypt, 2007.\n\n[19] D. Gillmor. Negotiated finite field Diffie-Hellman ephemeral\nparameters for TLS. IETF Internet Draft, May 2015.\n\n[20] D. M. Gordon. Designing and detecting trapdoors for\ndiscrete log cryptosystems. In Crypto, 1992.\n\n[21] D. M. Gordon. Discrete logarithms in GF(p) using the\nnumber field sieve. SIAM J. Discrete Math., 6(1), 1993.\n\n[22] D. Harkins and D. Carrel. The Internet key exchange (IKE).\nRFC 2409, Nov. 1998.\n\n[23] T. Jager, K. G. Paterson, and J. Somorovsky. One bad\napple: Backwards compatibility attacks on state-of-the-art\ncryptography. In NDSS, 2013.\n\n[24] A. Joux and R. Lercier. Improvements to the general\nnumber field sieve for discrete logarithms in prime fields. A\ncomparison with the Gaussian integer method. Math.\nComp., 72(242):953–967, 2003.\n\n[25] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen.\nInternet key exchange protocol version 2 (IKEv2).\nRFC 7296, Oct. 2014.\n\n[26] S. Kent. IP authentication header. RFC 4302, Dec. 2005.\n[27] S. Kent. IP encapsulating security payload (ESP).\n\nRFC 4303, Dec. 2005.\n[28] T. Kleinjung. Cofactorisation strategies for the number field\n\nsieve and an estimate for the sieving step for factoring 1024\nbit integers, 2006. http://www.hyperelliptic.org/tanja/\nSHARCS/talks06/thorsten.pdf.\n\n[29] T. Kleinjung, K. Aoki, J. Franke, A. K. Lenstra, E. Thomé,\nJ. W. Bos, P. Gaudry, A. Kruppa, P. L. Montgomery, D. A.\nOsvik, H. te Riele, A. Timofeev, and P. Zimmermann.\nFactorization of a 768-bit RSA modulus. In Crypto, 2010.\n\n[30] A. Langley, N. Modadugu, and B. Moeller. Transport layer\nsecurity (TLS) false start. IETF Internet Draft, 2010.\n\n[31] A. K. Lenstra and H. W. Lenstra, Jr., editors. The\nDevelopment of the Number Field Sieve. Springer, 1993.\n\n[32] M. Lipacis. Semiconductors: Moore stress = structural\nindustry shift. Technical report, Jefferies, 2012.\n\n[33] U. M. Maurer. Towards the equivalence of breaking the\nDiffie-Hellman protocol and computing discrete logarithms.\nIn Crypto, 1994.\n\n[34] U. M. Maurer and S. Wolf. Diffie-Hellman oracles. In Crypto,\n1996.\n\n[35] N. Mavrogiannopoulos, F. Vercauteren, V. Velichkov, and\nB. Preneel. A cross-protocol attack on the TLS protocol. In\nACM CCS, pages 62–72, 2012.\n\n[36] C. Meadows. Analysis of the Internet key exchange protocol\nusing the NRL protocol analyzer. In IEEE Symposium on\nSecurity and Privacy, 1999.\n\n[37] Microsoft Security Bulletin MS15-055. Vulnerability in\nSchannel could allow information disclosure, May 2015.\n\n12\n\nhttp://cr.yp.to/factorization/smoothparts-20040510.pdf\nhttp://caramel.loria.fr/p180.txt\nhttp://www.hyperelliptic.org/tanja/SHARCS/talks06/thorsten.pdf\nhttp://www.hyperelliptic.org/tanja/SHARCS/talks06/thorsten.pdf\n\n\n[38] NIST. FIPS PUB 186-4: Digital signature standard, 2013.\n[39] Oak Ridge National Laboratory. Introducing Titan, 2012.\n\nhttps://www.olcf.ornl.gov/titan.\n[40] H. Orman. The Oakley key determination protocol.\n\nRFC 2412, Nov. 1998.\n[41] S. C. Pohlig and M. E. Hellman. An improved algorithm for\n\ncomputing logarithms over GF(p) and its cryptographic\nsignificance (corresp.). Trans. Inform. Theory, 24(1), 1978.\n\n[42] J. M. Pollard. A Monte Carlo method for factorization. BIT\nNumerical Mathematics, 15(3):331–334, 1975.\n\n[43] O. Schirokauer. Virtual logarithms. J. Algorithms,\n57(2):140–147, 2005.\n\n[44] I. A. Semaev. Special prime numbers and discrete logs in\nfinite prime fields. Math. Comp., 71(237):363–377, 2002.\n\n[45] D. Shanks. Class number, a theory of factorization, and\ngenera. In Proc. Sympos. Pure Math., volume 20. 1971.\n\n[46] Spiegel Staff. Prying eyes: Inside the NSA’s war on Internet\nsecurity. Der Spiegel, Dec 2014.\nhttp://www.spiegel.de/international/germany/\ninside-the-nsa-s-war-on-internet-security-a-1010361.html.\n\n[47] W. Stein et al. Sage Mathematics Software (Version 6.5).\nThe Sage Development Team, 2015.\nhttp://www.sagemath.org.\n\n[48] stud: The scalable TLS unwrapping daemon, 2012.\nhttps://github.com/bumptech/stud/blob/\n19a7f19686bcdbd689c6fbea31f68a276e62d886/stud.c#L593.\n\n[49] E. Thomé. Subquadratic computation of vector generating\npolynomials and improvement of the block Wiedemann\nalgorithm. J. Symbolic Comput., 33(5):757–775, 2002.\n\n[50] P. C. Van Oorschot and M. J. Wiener. Parallel collision\nsearch with application to hash functions and discrete\nlogarithms. In ACM CCS, 1994.\n\n[51] P. C. Van Oorschot and M. J. Wiener. On Diffie-Hellman\nkey agreement with short exponents. In Eurocrypt, 1996.\n\n[52] D. Wagner and B. Schneier. Analysis of the SSL 3.0 protocol.\nIn 2nd Usenix Workshop on Electronic Commerce, 1996.\n\n[53] J. Wagnon. SSL profiles part 5: SSL options, 2013. https://\ndevcentral.f5.com/articles/ssl-profiles-part-5-ssl-options.\n\n[54] P. Zimmermann et al. GMP-ECM, 2012.\nhttps://gforge.inria.fr/projects/ecm.\n\n[55] APEX active/passive exfiltration. Media leak, Aug. 2009.\nhttp://www.spiegel.de/media/media-35671.pdf.\n\n[56] Fielded capability: End-to-end VPN SPIN 9 design review.\nMedia leak. http://www.spiegel.de/media/media-35529.pdf.\n\n[57] FY 2013 congressional budget justification. Media leak.\nhttp://cryptome.org/2013/08/spy-budget-fy13.pdf.\n\n[58] GALLANTWAVE@scale. Media leak.\nhttp://www.spiegel.de/media/media-35514.pdf.\n\n[59] Innov8 experiment profile. Media leak.\nhttp://www.spiegel.de/media/media-35509.pdf.\n\n[60] Intro to the VPN exploitation process. Media leak, Sept.\n2010. http://www.spiegel.de/media/media-35515.pdf.\n\n[61] LONGHAUL – WikiInfo. Media leak.\nhttp://www.spiegel.de/media/media-35533.pdf.\n\n[62] POISONNUT – WikiInfo. Media leak.\nhttp://www.spiegel.de/media/media-35519.pdf.\n\n[63] SIGINT strategy. Media leak.\nhttp://www.nytimes.com/interactive/2013/11/23/us/\npolitics/23nsa-sigint-strategy-document.html.\n\n[64] SPIN 15 VPN story. Media leak.\nhttp://www.spiegel.de/media/media-35522.pdf.\n\n[65] TURMOIL/APEX/APEX high level description document.\nMedia leak. http://www.spiegel.de/media/media-35513.pdf.\n\n[66] TURMOIL IPsec VPN sessionization. Media leak, Aug. 2009.\nhttp://www.spiegel.de/media/media-35528.pdf.\n\n[67] TURMOIL VPN processing. Media leak, Oct. 2009.\nhttp://www.spiegel.de/media/media-35526.pdf.\n\n[68] VALIANTSURF (VS): Capability levels. Media leak.\nhttp://www.spiegel.de/media/media-35517.pdf.\n\n[69] VALIANTSURF – WikiInfo. Media leak.\nhttp://www.spiegel.de/media/media-35527.pdf.\n\n[70] VPN SigDev basics. Media leak.\nhttp://www.spiegel.de/media/media-35520.pdf.\n\n[71] What your mother never told you about SIGDEV analysis.\nMedia leak. http://www.spiegel.de/media/media-35551.pdf.\n\n13\n\nhttps://www.olcf.ornl.gov/titan\nhttp://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html\nhttp://www.spiegel.de/international/germany/inside-the-nsa-s-war-on-internet-security-a-1010361.html\nhttp://www.sagemath.org\nhttps://github.com/bumptech/stud/blob/19a7f19686bcdbd689c6fbea31f68a276e62d886/stud.c#L593\nhttps://github.com/bumptech/stud/blob/19a7f19686bcdbd689c6fbea31f68a276e62d886/stud.c#L593\nhttps://devcentral.f5.com/articles/ssl-profiles-part-5-ssl-options\nhttps://devcentral.f5.com/articles/ssl-profiles-part-5-ssl-options\nhttps://gforge.inria.fr/projects/ecm\nhttp://www.spiegel.de/media/media-35671.pdf\nhttp://www.spiegel.de/media/media-35529.pdf\nhttp://cryptome.org/2013/08/spy-budget-fy13.pdf\nhttp://www.spiegel.de/media/media-35514.pdf\nhttp://www.spiegel.de/media/media-35509.pdf\nhttp://www.spiegel.de/media/media-35515.pdf\nhttp://www.spiegel.de/media/media-35533.pdf\nhttp://www.spiegel.de/media/media-35519.pdf\nhttp://www.nytimes.com/interactive/2013/11/23/us/politics/23nsa-sigint-strategy-document.html\nhttp://www.nytimes.com/interactive/2013/11/23/us/politics/23nsa-sigint-strategy-document.html\nhttp://www.spiegel.de/media/media-35522.pdf\nhttp://www.spiegel.de/media/media-35513.pdf\nhttp://www.spiegel.de/media/media-35528.pdf\nhttp://www.spiegel.de/media/media-35526.pdf\nhttp://www.spiegel.de/media/media-35517.pdf\nhttp://www.spiegel.de/media/media-35527.pdf\nhttp://www.spiegel.de/media/media-35520.pdf\nhttp://www.spiegel.de/media/media-35551.pdf\n\n\tIntroduction\n\tDiffie-Hellman Cryptanalysis\n\tAttacking TLS\n\tTLS and Diffie-Hellman\n\tActive Downgrade to Export-Grade DHE\n\t512-bit Discrete Log Computations\n\tActive Attack Implementation\n\tOther Weak and Misconfigured Groups\n\n\tState-Level Threats to DH\n\tScaling NFS to 768- and 1024-bit DH\n\tIs NSA Breaking 1024-bit DH?\n\tEffects of a 1024-bit Break\n\n\tRecommendations\n\tDisclosure and Response\n\tConclusion\n\tReferences\n\n","pdf:annotationTypes":"null","pdf:docinfo:producer":"pdfTeX-1.40.14","pdf:annotationSubtypes":"Link","pdf:containsDamagedFont":"false","pdf:unmappedUnicodeCharsPerPage":["2","0","3","0","0","3","2","0","0","0","0","0","0"],"access_permission:modify_annotations":"true","pdf:incrementalUpdateCount":"0","dcterms:created":"2015-08-21T15:06:23Z","dcterms:modified":"2015-08-21T15:08:05Z","xmpMM:DocumentID":"uuid:98988d37-b43d-4c1a-965b-988dfb2944b6","pdf:overallPercentageUnmappedUnicodeChars":"1.467911497456953E-4","pdf:docinfo:modified":"2015-08-21T15:08:05Z","pdf:docinfo:custom:PTEX.Fullbanner":"This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian) kpathsea version 6.1.1","X-TIKA:versionCount":"0","Content-Length":"1386629","Content-Type":"application/pdf","xmp:MetadataDate":"2015-08-21T15:08:05Z","pdf:producer":"pdfTeX-1.40.14","pdf:totalUnmappedUnicodeChars":"10","access_permission:assemble_document":"true","xmpTPg:NPages":"13","pdf:hasXMP":"true","pdf:charsPerPage":["4940","4730","5597","5243","5412","5883","5839","5384","5273","5167","5557","5777","3322"],"access_permission:extract_content":"true","access_permission:can_print":"true","pdf:docinfo:trapped":"False","X-TIKA:parse_time_millis":"2443","access_permission:can_modify":"true","pdf:docinfo:created":"2015-08-21T15:06:23Z"},{"Transparency Alpha":"nonpremultipled","X-TIKA:embedded_id_path":"/1","X-TIKA:content_handler":"ToTextContentHandler","tiff:ImageLength":"1038","Compression CompressionTypeName":"deflate","Data BitsPerSample":"8 8 8 8","Data PlanarConfiguration":"PixelInterleaved","Dimension VerticalPixelSize":"0.35273367","IHDR":"width=1710, height=1038, bitDepth=8, colorType=RGBAlpha, compressionMethod=deflate, filterMethod=adaptive, interlaceMethod=none","embeddedResourceType":"INLINE","Chroma ColorSpaceType":"RGB","tiff:BitsPerSample":"8 8 8 8","X-TIKA:embedded_id":"1","Content-Type":"image/png","height":"1038","imagereader:NumImages":"1","X-TIKA:final_embedded_resource_path":"/image0.png","pHYs":"pixelsPerUnitXAxis=2835, pixelsPerUnitYAxis=2835, unitSpecifier=meter","Dimension PixelAspectRatio":"1.0","resourceName":"image0.png","pdf:hasXMP":"false","tika_pg:page_number":"4","Compression NumProgressiveScans":"1","Content-Type-Parser-Override":"image/ocr-png","X-TIKA:Parsed-By":["org.apache.tika.parser.DefaultParser","org.apache.tika.parser.image.ImageParser","org.apache.tika.parser.ocr.TesseractOCRParser"],"Dimension HorizontalPixelSize":"0.35273367","Chroma BlackIsZero":"true","Compression Lossless":"true","X-TIKA:embedded_depth":"1","width":"1710","X-TIKA:parse_time_millis":"437","Dimension ImageOrientation":"Normal","X-TIKA:content":"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n, [DHE -EXPORT]\n\nsr, DHE_EXPORT\ncert, Sign (sks, [e | sr | psi12 | g | g’|\n\nb => dlog(g? mod D512)\n(ms, ki, ko) = kdf(g®, er | sr)\n\n\n\n","X-TIKA:embedded_resource_path":"/image0.png","tiff:ImageWidth":"1710","Chroma NumChannels":"4","Data SampleFormat":"UnsignedIntegral"},{"Transparency Alpha":"nonpremultipled","X-TIKA:embedded_id_path":"/2","X-TIKA:content_handler":"ToTextContentHandler","tiff:ImageLength":"700","Compression CompressionTypeName":"deflate","Data BitsPerSample":"8 8 8 8","Data PlanarConfiguration":"PixelInterleaved","Dimension VerticalPixelSize":"0.35273367","IHDR":"width=1340, height=700, bitDepth=8, colorType=RGBAlpha, compressionMethod=deflate, filterMethod=adaptive, interlaceMethod=none","embeddedResourceType":"INLINE","Chroma ColorSpaceType":"RGB","tiff:BitsPerSample":"8 8 8 8","X-TIKA:embedded_id":"2","Content-Type":"image/png","height":"700","imagereader:NumImages":"1","X-TIKA:final_embedded_resource_path":"/image1.png","pHYs":"pixelsPerUnitXAxis=2835, pixelsPerUnitYAxis=2835, unitSpecifier=meter","Dimension PixelAspectRatio":"1.0","resourceName":"image1.png","pdf:hasXMP":"false","tika_pg:page_number":"9","Compression NumProgressiveScans":"1","Content-Type-Parser-Override":"image/ocr-png","X-TIKA:Parsed-By":["org.apache.tika.parser.DefaultParser","org.apache.tika.parser.image.ImageParser","org.apache.tika.parser.ocr.TesseractOCRParser"],"Dimension HorizontalPixelSize":"0.35273367","Chroma BlackIsZero":"true","Compression Lossless":"true","X-TIKA:embedded_depth":"1","width":"1340","X-TIKA:parse_time_millis":"796","Dimension ImageOrientation":"Normal","X-TIKA:content":"\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\nTOP SECRET//COMINT//REL TO USA, FVEY\n\nInternet Key Exchi ')\n\nVPN1\nT: Socket Connection\n\nC: Selector Hit Query/Response\nInterface Key\n\nEUat pti Hecrey OcEr OCH Ee CeteT Cer r ctr cred ransport\nC = Content\n\nT: Secure Socket (SSL) F=Fomat\n\nC: PIQ Blade Management\n\nRie citereneres te 2 DOC /CES Ae\n\nResources\n\nVPN7\nT: Socket Connection\nC: Encrypted and Decrypted\n\nApplication Sessions. aa\nF: SOTF ae Fi\n= Resource\nTim = Allocation\nx al=\nC: IKE Messages | Teeny\nAo ot —|E. ~~» 5 6 ( )\nSle ou BH\nT:ITx bo a 5 & 8 fe)\nG ESP Key Req/Res no = <x\nWEINSOAP) - B= 5 ~ le\n(3) ryptovariables\na\n\n\n\n","X-TIKA:embedded_resource_path":"/image1.png","tiff:ImageWidth":"1340","Chroma NumChannels":"4","Data SampleFormat":"UnsignedIntegral"}]