Doc.: IEEE 802.11-01/374 Submission June 2001 Jesse Walker, Intel CorporationSlide 1 Reasonably Secure: An Analysis of the Expected Cost of Crypto-analytic

June 2001

Jesse Walker, Intel Corporation

Slide 1

doc.: IEEE 802.11-01/374

Submission

Reasonably Secure:An Analysis of the Expected Cost of

Crypto-analytic Attacks through 2020


June 2001


Slide 2

doc.: IEEE 802.11-01/374

Submission

“Making predictions is foolish”– Bruce Schneier, Applied Cryptography, on

estimating the cost to break cryptographic primitives

June 2001


Slide 3

doc.: IEEE 802.11-01/374

Submission

Goals

• Estimate the cost of crypto-analytic attacks against primitives on which authentication is based

• Use results to suggest requirements or guidelines for “reasonably secure” algorithms and key sizes– Identify possible “reasonably secure” compliance

classes

– Identify a timetable for transitioning key lengths within each compliance class

June 2001


Slide 4

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background

• The Lenstra-Verheul model

• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 5

doc.: IEEE 802.11-01/374

Submission

Background (1)

• 802.11 wants “reasonable security” but has not quantified what this means

• TGi authentication discussion bogged down arguing over what this means

• We need estimates of the actual cost of attacking various authentication algorithms, to help:– Quantify the challenge– Provide a more concrete frame of reference for the

requirements discussion– Lead us to a decision the market will accept

June 2001


Slide 6

doc.: IEEE 802.11-01/374

Submission

Background (2)

• TGi split into 3 camps on authentication– Legacy RADIUS-based methods camp– Kerberos over EAP camp– TLS over EAP camp

• Recent discussions add SRP to the mix, too

• Question: How secure is each of these? Which are “reasonably secure”?

June 2001


Slide 7

doc.: IEEE 802.11-01/374

Submission

Background (3)• We can dismiss legacy authentication as insecure:

– RADIUS PAP, CHAP, WEP authentication

• If a legacy authentication exchange is visible, it can be broken by a single machine:– Cost to break an observed PAP exchange: 0 cycles– Cost to break an observed WEP authentication exchange: 48 cycles– Cost to break an observed CHAP exchange: O(232) cycles (3.33

seconds on a 1.2 GHz Pentium IV)

• Legacy authentication doesn’t meet functional requirements anyway:– No mutual authentication– No key agreement/distribution

June 2001


Slide 8

doc.: IEEE 802.11-01/374

Submission

Background (4)• We can dismiss legacy Kerberos as insecure, too:

– Existing Kerberos implementations based on passwords

• If a legacy Kerberos exchange is visible, it can be broken by a single machine:– Cost to break observed legacy password-based Kerberos AS_REP

packet: O(234) cycles (14.5 seconds on a 1.2 GHz Pentium IV)

• Legacy Kerberos is not “reasonably secure” even if future Kerberos will be– Kerberos needs PKInit to advance to Proposed Standard and be

deployed before it becomes secure– or it needs some other unstandardizable, out-of-band channel to

distribute real keys, not passwords

June 2001


Slide 9

doc.: IEEE 802.11-01/374

Submission

Background (5)

• Techniques that can be broken in seconds or minutes by brute force search on a single stock CPUs are not “reasonably secure”

• Stock CPUs will only be even faster when the first TGi hardware finally ships

• Random observation: a single 1.2 GHz Pentium IV makes available about 3 MIP Years instructions every day– These things can be networked together– It is easy to harvest spare MIPs from un-firewalled networked

machines– And practical: successful attack on 512-bit RSA demonstrated in

1999 using this technique with much less powerful Pentium IIs and IIIs

June 2001


Slide 10

doc.: IEEE 802.11-01/374

Submission

Background (6)• PKInit, TLS, SRP rely on public key schemes• Crypto-analytic attack cost estimates for public

key schemes notoriously difficult • But we can’t reach consensus without more

tangible security estimates– Can’t over-provision too much, or the market will rebel– Can’t under-provision too much, or 802.11 security will

be crucified in the press

• How much is safe?

June 2001


Slide 11

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background


• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 12

doc.: IEEE 802.11-01/374

Submission

Approach• This submission uses the Lenstra-Verheul

model to estimate crypto-analytic costs of public key algorithms

• The Lenstra-Verheul model can be found at:– Crypto 2000 proceedings– http://www.cryptosavvy.com/– It is sketched in the Backup section of these slides

June 2001


Slide 13

doc.: IEEE 802.11-01/374

Submission

Lenstra-Verheul Model (1)• Developed by financial industry to estimate their e-

business risk and plan their investments• Provides model to estimate key sizes needed in year

y in the future• Thorough model:

– Takes into account Moore’s law, rate of crypto-analytic progress, economic growth, etc.

• Estimates cost of breaking DES and extrapolates this result to RSA, Discrete Log algorithms, ECC, based on instruction counts of fastest published attacks

June 2001


Slide 14

doc.: IEEE 802.11-01/374

Submission

Lenstra-Verheul Model (2)

• Model’s most interesting parameter is security margin s: in what year do you no longer trust 56-bit DES?– This is different than assuming DES is broken in year s;

rather it is merely when you aren’t willing to assume the risk of using it any longer

• Budget required to build a one-day DES cracker for that year can be calculated.

• Model extrapolates this budget value to any year in future using normal compound interest

June 2001


Slide 15

doc.: IEEE 802.11-01/374

Submission

Lenstra-Verheul Model (2)

• Model uses Moore’s law and assumption about rate of crypto-analytic progress to predict number of symmetric key bits same adversary can break in one-day attack at any year in the future

• Model then translates this into approximate RSA and DH key sizes same adversary could break with comparable hardware– Based on instruction count of fastest known published

attack

June 2001


Slide 16

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background


• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 17

doc.: IEEE 802.11-01/374

Submission

Some Milestone Dates• 1997: Kocher-Gilmer DES-cracker. Public realizes 56-bit

DES is not secure– Call attackers capable of these attacks only Consumer Grade

Adversaries

• 1992: Last year 56-bit DES is certified as safe. Industry at large admits it needs a stronger cipher to protect burgeoning e-commerce– Call attackers capable of these attacks Commercial Grade

Adversaries

• 1985: 3DES ratified as an ANSI standard. Financial community confirms it cannot meet it legal obligations using 56-bit DES– Call attackers capable of these attacks Enterprise Grade Adversaries

June 2001


Slide 18

doc.: IEEE 802.11-01/374

Submission

Sample Results (1)

For a consumer grade adversary

For a commercial grade adversary

For an enterprise grade adversary

2005 $68,550.00 $977,160.00 $40,317,470.002010 $96,950.00 $1,381,910.00 $49,636,630.002015 $137,100.00 $1,954,320.00 $80,634,950.002020 $193,900.00 $2,763,260.00 $114,035,040.00

Model predicts future budgets of various adversaries, based on when they could first mount a 1-day attack on 56-bit DES:

June 2001


Slide 19

doc.: IEEE 802.11-01/374

Submission

Sample Results (2)Model predicts maximum Elliptic Curve field size an adversary can break in a 1-day attack based on this budget:

By a consumer grade adversary:

By a commercial grade adversary:

By an enterprise grade adversary:

2005 117 124 1342010 124 131 1392015 131 139 1492020 139 146 156

June 2001


Slide 20

doc.: IEEE 802.11-01/374

Submission

Sample Results (3)Model predicts maximum RSA key size or Diffie-Hellman group size an adversary can break in a 1-day attack based on this budget:

By a consumer grade adversary:

By a commercial grade adversary:

By an enterprise grade adversary:

2005 595 673 7922010 746 835 8962015 917 1018 11692020 1110 1223 1391

June 2001


Slide 21

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background


• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 22

doc.: IEEE 802.11-01/374

Submission

Applications to Authentication Algorithms

• Each of the discussed public key-based authentication algorithms rely on RSA or Discrete Log techniques– PKInit uses RSA or Diffie-Hellman; could use ECC– TLS uses RSA or Diffie-Hellman or ECC methods– SRP uses Diffie-Hellman

• Therefore the model can be used to quantify security needs of each

• And we can use this information to arrive at a definition of “reasonably secure”

June 2001


Slide 23

doc.: IEEE 802.11-01/374

Submission

Lessons• Not plausible to avoid public key operations

entirely and still provide “reasonable security”– Radically unpleasant implications for the cost of stand-alone APs

and hand-helds unless the number of public key operations can be minimized

• Feasible to make plausible estimates of public key sizes needed to provide “reasonable security”

• One key size will not work for the entire market– The minimum security requirements for one market segment are

drastic overkill for other market segments

• One key size model will not work through all time– The required key size gets worse every year

June 2001


Slide 24

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background


• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 25

doc.: IEEE 802.11-01/374

Submission

How do we proceed? (1)• Act now: we have to support public key

methods somewhere; let’s admit this and move on.– Symmetric key schemes by themselves cannot

provide any notion of “reasonable security”– The right issue is where and how to use these

algorithms, not if

June 2001


Slide 26

doc.: IEEE 802.11-01/374

Submission

Some Problems• Customers can’t deal with different algorithms and

key sizes– Non-cryptographers don’t know which to use and when

• Unlikely a single protection level can be accepted– Each vendor addresses a different market niche

• Minimally acceptable security for the enterprise is overkill for other markets, e.g., public access.– Consumers, public access won’t pay this price.

• Maximally acceptable security level (because of cost) for, e.g., consumers, is unacceptable to enterprises.– Enterprises don’t deploy schemes that don’t protect their IP

June 2001


Slide 27

doc.: IEEE 802.11-01/374

Submission

How do we proceed? (2)• Adopt a model to estimate public key costs based on

agreed upon assumptions• Define a range of conformance classes and key sizes

needed for each for conformance class• Define review cycle, where key size estimates and the

standard are updated– Implies a new definition of conformance: a product can

claim to provide a level of security only through year N.– There are no valid unqualified claims of security in this

model

• Precedent: Bank vaults are rated in hours required for penetration

June 2001


Slide 28

doc.: IEEE 802.11-01/374

Submission

Example (1)

• Define, e.g., 3 conformances classes– “Public” or “Consumer”: protect against attacks

by individuals, such as script kiddies and grandmothers. Take s = 1997

– “Commercial”: defend against attacks by small organizations, such private investigators and small time organized crime. Take s = 1992

– “Enterprise”: attempt to deter professional grade industrial espionage. Take s = 1985

June 2001


Slide 29

doc.: IEEE 802.11-01/374

Submission

Example (2)

• Products certified through year N for the Public Conformance Class must support– N = 2010: 768-bit asymmetric key, or 768-bit group

and 128-bit discrete log key, or 131-bit Elliptic Curve– N = 2015: 1024-bit asymmetric key, or 1024-bit group

and 144-bit discrete log key, or 163-bit Elliptic Curve– N = 2020: 1236-bit asymmetric key, or 1236-bit group

and 160-bit discrete log key, or 163-bit Elliptic Curve

• Define similar scales for other conformance classes

June 2001


Slide 30

doc.: IEEE 802.11-01/374

Submission

Example (3)

• Review required algorithms, key lengths, and conformance classes every 5 years– Cryptographic breakthrough may render estimates

wildly optimistic– Moore’s law may fail in 2010-2012, rendering further

improvements less necessary

• Review would not “revoke” certification of already shipped equipment– Only addresses what kind security claims can be made

for new equipment.

June 2001


Slide 31

doc.: IEEE 802.11-01/374

Submission

Agenda

• Background


• Results

• Discussion

• Call to Action

• Summary

June 2001


Slide 32

doc.: IEEE 802.11-01/374

Submission

Summary• We cannot provide secure authentication and key

distribution w/o public key operations somewhere• We can estimate the cost required for the

operations– But cost changes over time

– And different costs are acceptable to different markets

• We should specify the minimum key sizes conformant implementations have to support for particular markets.

June 2001


Slide 33

doc.: IEEE 802.11-01/374

Submission

Feedback?

June 2001


Slide 34

doc.: IEEE 802.11-01/374

Submission

Backup

June 2001


Slide 35

doc.: IEEE 802.11-01/374

Submission

CHAP Assumptions• The O(232) cycle estimate on Slide 7 for breaking

CHAP is based on following assumptions:– An MD5 of at most 64 bytes takes 1250 cycles (cost of

OpenSSL 0.9.6 MD5)– Password used for authentication (the legacy

configuration)– A dictionary of 3,000,000 entries can recover most

passwords (dictionary available at http://ftechsoft.hypermart.net/dictionary.html)

– Reproducing a recorded CHAP exchange using brute force dictionary search costs at most 12503000000 = 3750000000 232 cycles

June 2001


Slide 36

doc.: IEEE 802.11-01/374

Submission

Legacy Kerberos Assumptions• A 3DES operation requires 145 cycles/byte (cost of

OpenSSL 0.9.6 3DES)• Password used to 3DES encrypt AS_REP data (the

legacy configuration)• Typical encrypted AS_REP data is 40 bytes• A dictionary of 3,000,000 entries can recover most

passwords (dictionary available at http://ftechsoft.hypermart.net/dictionary.html)

• Reproducing a recorded AS_REP reply using brute force dictionary search costs at most 14540 3000000 = 17,400,000,000 234 cycles

June 2001


Slide 37

doc.: IEEE 802.11-01/374

Submission

Lenstra-Verheul Sketch (1)

• Major Parameters:– Security margin s: last year user was willing to trust 56-

bit DES. Default: s = 1982 (arbitrary)– Number of months m to double processor speed,

memory side. Default: m = 18 (empirical observation)– Number of years b for attacker’s budget to double.

Default, b = 10 (approximate empirical observation, based on general economic growth)

– Number of months r for cryptanalytic techniques to become twice as effective. Default: r = 18 (empirical observation)

June 2001


Slide 38

doc.: IEEE 802.11-01/374

Submission


• Major Parameters (Continued):– Wholesale price p of a stripped down 450 MHz

Pentium II with 64 MB and NIC. Default: p = $100 (empirical observation: approximate cost of an SBC)

– Number of CPU cycles v to perform one encryption. Default: v = 1 (valid for DES chips, ludicrously low for software, but this is inconsequential)

• If you don’t agree with a parameter value, change it!

June 2001


Slide 39

doc.: IEEE 802.11-01/374

Submission


• Major Formulas:– Infeasible number of MIP years y (i.e., number of MIP

years required for attack on n-bit DES in year y):IMY(y) = 5105212(ys)/m2t(ys)/b

– Symmetric key size d needed until year y:

d = 56+(12/m+t/b) log2(v)– Formulas to translate d into appropriate size for the

following:• RSA key size and Discrete Log group size• Discrete Log key size• ECC key size

June 2001


Slide 40

doc.: IEEE 802.11-01/374

Submission


• Note: other parameters also affect the computed key sizes and lead to different (but same order of magnitude) results– They are ignored here

• This presentation– Uses defaults (but varies security margin parameter s)

to suggest order of magnitude costs, to help focus the decision process

– Focuses only on expected lower bound cost of attacks, not on safety margin needed as a hedge, or any of the other useful values Lenstra-Verheul computes

June 2001


Slide 41

doc.: IEEE 802.11-01/374

Submission

Minimal Safety in 2005

last year user is willing to trust DES

Dollar cost of 1 day attack on n-bit DES in 2005

Minimun symmetric key size in 2005 (the n in n-bit DES)

Minimum elliptic curve size in 2005

Cost equivalent asymmetric key size or group size in 2005

Cost equivalent discret log key size in 2005

1982 198546530 74 139 847 1341983 116700480 73 137 828 1321984 68593500 72 136 810 1311985 40317470 71 134 792 1291986 23697560 71 133 775 1281987 13928800 70 131 757 1261988 8186990 69 130 740 1251989 4812000 68 128 723 1241990 2828430 68 127 706 1271991 1662480 67 125 690 1211992 977160 66 124 673 1191993 574350 65 122 657 1181994 337590 64 121 641 1171995 198420 64 120 626 1151996 116630 63 118 610 1141997 68550 62 117 595 1131998 40300 61 115 580 111

June 2001


Slide 42

doc.: IEEE 802.11-01/374

Submission




Minimum Symmetric key size in 2010




1982 280797190 77 146 1031 1401983 165039400 77 144 1010 1391984 97005860 76 143 990 1371985 57017520 75 142 970 1361986 33513410 74 140 950 1341987 19698130 74 139 930 1331988 11578150 73 137 910 1321989 6805340 72 136 891 1301990 4000000 71 134 872 1291991 2351100 71 133 853 1271992 1381910 70 131 835 1261993 812250 69 130 817 1251994 477420 68 128 798 1231995 280620 68 127 781 1221996 164940 67 125 763 1201997 96950 66 124 746 1191998 56980 65 122 729 118

June 2001


Slide 43

doc.: IEEE 802.11-01/374

Submission








1982 397093060 81 153 1238 1471983 233401000 81 152 1215 1451984 137187000 80 150 1192 1441985 80634950 79 149 1169 1421986 47395120 78 147 1147 1411987 27857620 77 146 1125 1401988 16374000 77 144 1103 1381989 9624200 76 143 1081 1371990 5656840 75 142 1060 1351991 3325000 74 140 1039 1341992 1954320 74 139 1018 1321993 1148700 73 127 997 1311994 675200 72 136 977 1301995 396850 71 134 957 1281996 233260 71 133 937 1271997 137100 70 131 917 1251998 80590 69 130 898 124

June 2001


Slide 44

doc.: IEEE 802.11-01/374

Submission








1982 571564390 85 161 1468 1531983 330078800 84 159 1442 1521984 194011720 84 158 1416 1501985 114035040 83 156 1391 1491986 67026820 82 155 1366 1481987 39396620 81 153 1342 1461988 23156310 81 152 1317 1451989 13610670 80 150 1293 1431990 8000000 79 149 1269 1421991 4702200 78 147 1246 1401992 2763260 77 146 1223 1391993 1624500 77 144 1200 1381994 955000 76 143 1177 1361995 561230 75 142 1154 1351996 329880 74 140 1132 1331997 193900 74 139 1110 1321998 113860 73 137 1088 131

Documents

Doc.: IEEE 802.11-01/374 Submission June 2001 Jesse Walker, Intel CorporationSlide 1 Reasonably Secure: An Analysis of the Expected Cost of Crypto-analytic