Semester2,SidangAkademik2011/2012 CST233 Assignment3 DiffieHellmanKeyExchangeMethodon CryptographicKeys

Preparedby Name: MuhammadNoorshazmilBinMohdZahri MatricNo.: 107608 Preparedfor Pensyarah: Dr. Aman Jantan

Date of Submission 21st May 2012

Diffie-Hellman Key Exchange Method on Cryptographic Keys MuhammadNoorshazmilBinMohdZahri,107608 UNIVERSITISAINSMALAYSIA ComputerScience mnoorshazmil.ucom10@student.usm.my

Abstract What is DiffieHellman (DH), and why should you care? The ability to distribute cryptographic keys securely has been a challenge for centuries. The DiffieHellman key exchange protocol was the first practical solution to the key exchange dilemma. The DiffieHellman protocol allows two parties to exchange a secret key over unsecured communication channels without meeting in advance. The secret key can then be used in a symmetricencryptionapplication,andthetwo parties can communicate securely. DH is a mathematical algorithm that allows two computers to generate an identical shared secret on both systems, even though those systems may never have communicated with eachotherbefore.Thatsharedsecretcanthen be used to securely exchange a cryptographic encryption key. That key then encrypts traffic betweenthetwosystems.

systemsbecauseasymmetrickeymanagementis much easier. In a symmetric key system, both sidesofthecommunicationmusthaveidentical keys.Securelyexchangingthosekeyshasalways been an enormous issue. At one time, the National Security Agency maintained an entire fleet of trucks and planes manned by armed couriers to shuttle around 15 tons of paper based symmetric key used by the U.S. government every year. Businesses simply do not want to mess with that sort of burden.

1.0 INTRODUCTION
TheDHalgorithm,introducedbyWhitfieldDiffie

Asymmetric key systems alleviate that issue because they use two keys: one called the privatekeythattheuserkeepssecret,andone

and Martin Hellman in 1976, was the first called the public key that can be shared with system to utilize publickey or asymmetric the world and, therefore, easily distributed. cryptographickeys.Thesesystemsovercomethe Unfortunately, the advantages of asymmetric difficulties of privatekey or symmetric key

key systems are overshadowed by speedthey are extremely slow for any sort of bulk encryption. Today, it is typical practice to use a symmetric system to encrypt the data and an asymmetric system to encrypt the symmetric keys for distribution. That is precisely what

Today our concern is not who discovered the process,buthowtosharesymmetrickeysinan insecure network. Most networking vendors look at the Public Key Cryptography Standard (PKCS)#3standardtoimplementDH.

Simply put, DH is typically not used to encrypt DiffieHellman is capable of doingand does user data, but is, in most cases, used by VPN dowhen used for key exchange as described implementations to share keying information here. securely,suchasDES,3DES,AES,SHA,MD5and However, there is evidence to prove that these Whitfield Diffie, Martin Hellman, and Ralph Merkle actually didn't discover the othersymmetrickeys,acrossaninsecurepublic network, like the Internet. DH uses public key cryptography(asymmetrickeying)toaccomplish this. Therefore, it is commonly referred to as a publickeyexchangemethod.

public/private key cryptography process; rather it was one of two government agencies of the British or the U.S. (National Security Agency)

Many VPN implementations, such as IPsec, use government10yearsbeforeDiffie,Hellman,and DH to share symmetric encryption keys in a Merkle developed a similar process secure fashion. For instance, IPsec's RFCs 2401, independently.Theseprocesses,however,were 2408,and2412relyontheuseofDHforsharing kept secret from the public; and whereas this of keying information for HMAC functions, such information was classified and never published, asMD5andSHA,andencryptionalgorithms,like these three people created the same solution DES,3DES,andAES. forpublicuse.

2.0 HOW DH WORKS?

Figure 24explains how DH works. DH uses the following six steps to share symmetric keys acrossaninsecurenetwork:

throughtheDHalgorithm.

4. The mathematical beauty of the DH algorithm is that even though different inputs are fed into the algorithm, thesameoutputresultsonbothsides:Diffie,

1. Each of the two peers shares information that will help them create their own public/private key combinations; this is necessary because DH supports varying key

Hellman,andMerklefiguredoutthatifyou haveonepairofvaluesthathavearelation, and another pair of values that have a relation, when you exchange one value for

sizes, called keygroups. I'll discuss DH key groups after these numbered steps. Once

another in the different pair, there is still a relationship between the values. I have a

thekeysizeisknown,thetwopeerscreate degreeinmathematics,butcomingupwith their personal public/private key pair combination. Actually, each creates its private key first, and uses a derivative process to derive the public key from the privatekey. 5. Because PeerA created the symmetric encryption key for the financial data, PeerA 2. Each peer shares its public key with the encrypts thedatawiththeoutputkeyfrom remotepeer. the DH algorithm, Secret_key_X, and sends 3. Eachpeertakesitspersonalprivatekeyand theremotepeer's public key and runs them the encrypted symmetric encryption key to PeerBacrossthenetwork. thisproofiswaybeyondmyabilitiesI'mjust gladthesethreeguysmadeiteasierforme tosetupsecurenetworks!

6. When PeerB receives the encrypted key, PeerB uses the same derived DH key,

3.0 DH KEY GROUPS

Table 21hasa quick breakdown of the DH key

Secret_key_X,todecryptthesymmetrickey, groups. In this table, the first column indicates resulting in "If you can guess this key, you the name of the key group, denoted by a win a lollipop!"; therefore, when PeerA number.Followingthisisthelengthofthekeys, sends financial data to PeerB, PeerB will be and, in the last column, the type of algorithm able to decrypt it successfully with the used to create the shared secret key. DH key symmetricencryptionkey. groups are commonly referred to with their Figure24.TheDiffieHellmanProcess number,asinDHgroup1.

Table21.DHKeyGroups Key Length Equation Group 1 2 3 DH uses key groups to define how the shared secretkeyisactuallygenerated.Thekeygroups define the key length for the public and private keys and the DH algorithm to use in generating thesharedsecretkey. 15 7 14 4 5 768 bits 1,024 bits 155 bits 185 bits 1,536 bits 163 bits 2,048 bits 3,072 Straightalgorithm Straightalgorithm Ellipticalcurvealgorithm Ellipticalcurvealgorithm Straight algorithm (most secure key group supported byCisco) Ellipticalcurvealgorithm Straightalgorithm Straight algorithm (most

intensive, the key sizes are kept small so that Table21.DHKeyGroups Key Length Equation Group bits Straight algorithms use a normal computation process, like an equation, to produce a secure key. The longer the bit length is for a straight algorithm,thestrongertheresultingsecretkey. But straight algorithms and keys with long bit lengths are very computationalintensive. For example, a Cisco 7200 router with a VAM card would have no problemprocessing a straight algorithm using DH group 15; however, a personal digital assistant (PDA) device doesn't havethatcapacity. secure key group, but Cisco doesn'tsupportit) limitedprocessingdevicescanstillusethem.

4.0 KEY REFRESHING & LIMITATIONS OF KEY EXCHANGE METHODS

Anotherthingtoconsideristhemanagementof keys. Periodically, you'll probably want to changeyoursymmetrickeysusedbyencryption algorithms and HMAC functions for a more securesolution.Forexample,ifyouhad100sets ofkeys,andyoursecuritypolicystatedthatyou should change the keys once every hour, you definitely would not want to do this manually this would require multiple fulltime people to perform this task 24 hours a day, seven days a week! Therefore,oneoftheimportantfeatures

To accommodate devices that have limited processingpower,ellipticalcurvealgorithmsare used; they can use a smaller key size, but can create a more secure result than a

a VPN implementation should support is managementofkeys:theabilitytorefreshthem periodically in a dynamic, secure, inband fashion, reducing the amount of physical managementtoaverysmallamountoftime.For example, DH doesn't specify how to deal with

correspondingstraightalgorithmusingthesame key size. But because they are also process

key management functions; however, VPN implementations, such as IPsec, have other componentsthathandlethisprocess. Onestrengthofasymmetrickeyingalgorithmsis that the private key, used to decrypt information, is never sent across the network. And with DH, the derived secret key also never traversesthenetwork.Thusanattacker,evenif heiseavesdroppingonthepublickeyexchange process and sees the exchanged public key or keys,wouldn'tbeabletousethistodecryptany transmittedinformation.Inasimpleasymmetric algorithm implementation, the eavesdropping attackerwouldhavetoknowtheprivatekeyto decrypt information; and in the case of DH, the attackerwouldhavetoknowofoneofthetwo private keys to decrypt information. However, DH does have one main weakness: it is susceptible to a maninthemiddle attack. I'll usethePeerAtoPeerBexample.PeerAneedsto encryptfinancialdatatoPeerB.Inthisexample, assumeDHisbeingusedforsharingkeys.PeerA initiates a connection to PeerB; assume that

instead of the real PeerB responding back, a maninthemiddle attack occurs and the attacker's device responds back. DH, however, assumes that the two devices trust each other. In the PeerAtoPeerB example, especially if they'reseparatedbyapublicnetwork,theyhave noideaifthey'reinteractingwitheachother,or with some device pretending to be one of the two parties.In other words, key exchange protocolssuchasDHdealstrictlywithonething: key exchanges. They don't deal with other

authentication

mechanisms.

Some

componentisrequiredtoverifytheidentitiesof the two devices to ensure that PeerA doesn't mistakenly send sensitive financial data to a maninthemiddledevice(attacker).

5.0 DIFFIEHELLMANS FEATURES

TheDiffieHellmanalgorithmhastwoattractive features: Secretkeysarecreatedonlywhenneeded. Thereisnoeedtostoresecretkeysforalong

periodoftime,exposingthemtoincreased vulnerability. Theexchangerequiresnopreexisting infrastructureotherthananagreementonthe globalparameters. However,thereareanumberofweaknessesto DiffieHellmanalgorithm: Itdoesnotprovideanyinformationaboutthe identitiesofbothparties.Soitisvulnerableto impersonationattack. Itiscomputationallyintensive.Asaresult,itis vulnerabletoacloggingattack,inwhichan opponentrequestsahighnumberofkeys.The victimspendsconsiderablecomputingresources doinguselessmodularexponentiationrather thanrealwork. Itcannotpreventreplayattack. Itissubjecttoamaninthemiddleattack,in whichathirdpartyCimpersonateswhile communicatingwithAandimpersonatesAwhile communicatingwithB.BothAandBendup

negotiatingakeywithC,whichcanthenlisten toandpassontraffic. Themaninthemiddleattackproceedsas follows: step1:AC(B):XAmodq step2:C(A)B:XCmodq step3:BC(A):XBmodq step4:C(B)A:XCmodq UserAgeneratesaonetimeprivatekey XA,calculatesYA,andsendshispublickeyYAina messageaddressedtouserB.TheenemyC interceptsAsmessage.CsavesAspublickey (YA)andgeneratesaonetimeprivatekeyXC, calculatesYC,andsendshispublickeyYCina messagetouserB.ThismessagetoBhasAs UserIDbutCspublickeyYC.Thismessageis sendinsuchawaythatitappearsasthoughit wassendfromAshostsystem.BreceiveCs messageandstoresCspublickeywithAsUser ID.

achieveauthenticationisarelativelysimple, economicalandpracticalprogramswithout additionalpublickeyinfrastructureasasupport. BecauseofincludingAuthenticationmechanism, theimprovedDiffieHellmankeyexchange Similarly,CsendsamessagetoAwithCspublic key(YC),purportingtocomefromB.Acalculates asecretkeyK1((YC)XAmodq)basedonXAand YC.CcalculatesK1((YA)XCmodq)usingXCand YA.SoK1issharedbyAandC.Bcalculatesa secretkeyK2((YC)XBmodq)basedonXBandYC. Ccalculates((YB)XCmodq)usingXCandYB.SoK2 issharedbyBandC.FromnowonuserAthinks K1issharedwithB,userBthinksK2isshared withA,butnokeyissharedbyAandBactually. SoCisabletorelaymessagesfromAtoBand fromBtoA. protocolcanresistreplayattack,impersonation attackandmaninthemiddleattack.The simulationresultsintheLANprovethat authenticationusinghashfunctionhastheless computingquantityandthefastercomputing speedthantheotherpublickeyandsymmetric keyencryptionalgorithm.Ithasahighpractical valueinbuildingasecurecommunication channelofsymmetrickey.

7.0 REFERENCES
1. DiffieHellman Key Exchange,

6.0 CONCLUSION
ByanalyzingthesecurityoftheDiffieHellman protocol,thispaperpresentsanimprovedkey exchangeprotocolbasedonrandomnumber sequence.Thisprotocolusingahashfunctionto

http://www.nyx.net/~awestrop/crypt/dh.htm 2. IPSec Overview Part Three: Cryptographic Technologies, http://www.ciscopress.com/articles/article.asp?p=25 473

3.

DiffieHellmaan

key

exchange,

http://searchsecurity.techtarget.com/definition/Diffi eHellmankeyexchange 4. DiffieHellman key exchange,

http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm an_key_exchange 5. DiffieHellman key exchange by Matt Ryall, http://en.wikipedia.org/wiki/Diffie%E2%80%93Hellm an_key_exchange 6. DiffieHellman Key Exchange A Non Mathematicians Explanation,

http://www.packetsource.com/article/encryption/40 070/diffiehellmankeyexchangeanon mathematiciansexplanation 7. What is DiffieHellman,

http://www.rsa.com/rsalabs/node.asp?id=2248