Rather than attempting to cover the entire history of

Public Key Algorithms, this paper focuses on

· Newly declassified information documenting Public Key system developments before 1976.

· The Diffie Hellman key exchange. This topic was barely covered in the textbook and class notes. It is explored in greater depth since it's a core technology that bridges Public Key systems to symmetric (secret) key. Many protocols depend on key exchange in some way or another.

I. A Firm Foundation

Public key cryptographic systems are the foundation upon which other systems are built offering

· Authentication

· Nonrepudiation.

Symmetric (secret) key systems offer security but cannot prove who originated the message, or the sender can deny sending the message. Public key systems allow privacy by hiding the contents of a message, or the message may be sent unencrypted but benefit from an electronic "signature" proving the sender's identity.

II. Recently revealed Public Key system history

Major advances in the art of cryptography and cryptanalysis (code breaking) occurred during WW II. The people and accomplishments were far reaching

· Alan Turing and others at Bletchley Park (the secret British cryptography unit) invented many specialized machines to break what were considered unbreakable codes. Much of that work founded what we now call Computer Science.

· The military's faith in cryptography was shaken.

The state of the art needed to advance in new ways to meet new demands, particularly the new threat of computing machinery applied to code breaking and new requirements such as proving the sender's identity, or restricting reception to specified people.

Even non-technical people thrilled to the measures / countermeasures of the code makers vs. code breakers in books such as The Ultra Secret WINTE74 and numerous History Channel recreations.

Steven M. Bellovin BELL is an interesting fellow. His CV lists patents for remote authentication, secure communications, and access restriction. His web site The Prehistory of Public Key Cryptography BELL04 chronicles events that are not found elsewhere.

While most of the documents are still secret, honor to whom honor is due and the Freedom of Information Act are allowing further insight into the secret origins and impudence for Public Key cryptography, both from the USA and England.

In the USA, the NSA explored Public Key encryption systems in the 1960s nearly 10 years before Diffie and Hellman's 1976 paper New directions in cryptography DIFFI. Declassified documents show some important milestones and projects that preceded Diffie, Hellman et al. but since they were secret, the public work was totally uninfluenced by it.

Whit Diffie organized a Festcolloquium in honor of Gus Simmons in Fairfax VA, USA on November 1993, resulting in Festkolloquium for Dr. Gus Simmons, 1st ACM Conference on Computer and Communications Security.

At the seminar, Gus told of how he learned of public key crypto -- the same way many of us did, by reading Martin Gardner's column in Scientific American. Simmons was on his way to Australia to give a talk; he said he was immediately struck by the implications of this technique for nuclear weapons command and control -- his field -- so he tore up his talk and made up a new one on the plane. It seemed clear, at that point, that he had not known of the technique. (An alternative explanation, of course, is that he knew of it but couldn't speak about it until it was rediscovered. I did not get that impression at the time.)

The next speaker was someone who had recently retired from the upper echelons of NSA. He spoke of National Security Action Memorandum 160 (from June 6, 1962), entitled "Permissive Links for Nuclear Weapons in NATO". The claim was that this memo -- signed by President Kennedy and endorsing a memo from his science advisor, Jerome Weisner -- was the basis for the invention of public key cryptography by NSA. Simmons nodded in vigorous agreement.

On June 6, 1962, President Kennedy signed a memo KENNE62 stating the need for a Nuclear Weapon command and control system. Unlike previous secret systems, this new system needed to provide authentication and nonrepudiation. This is the earliest citation for the creation and deployment of a military public key system.

There are vague references to a Bell Labs secure voice telephony system. It is possibly related to the STU-III project -- a certificate-based secure telephone system, with the associated PKI .

The US effort was duplicated by independent work in England. Private Key encryption systems are still considered so secret that even in 1987 disclosures are still slowly trickling out as documents are declassified.

Citing WAYNE97

For the last 20 years, the public gave credit for the discovery to Martin Hellman, a professor at Stanford University, and two graduate students who worked with him at the time, Ralph Merkle and Whitfield Diffie. They started publishing their work in 1976.

Three professors at the Massachusetts Institute of Technology at the time, Ron Rivest, Adi Shamir and Len Adleman soon followed with another similar approach known by their initials, RSA, which went on to become one of the dominant solutions used on the Internet.

The new document details how three employees of the British government discovered the same approach several years earlier, but kept it a secret for reasons of national security. A spokesman for the British government's GCHQ, said that the document's release is part of a "pan-governmental drive for openness" pushed by the Labor party.

These documents are available from UK: Information Assurance & Certification Services (IACS) http://www.cesg.gov.uk/

James H Ellis ELLIS87 ELLIS70 discloses the British efforts in Public Key cryptography, citing some prior art by Bell Labs.

2. Cryptography is a most unusual science. Most professional scientists aim to be the first to publish their work, because it is through dissemination that the work realizes its value. In contrast, the fullest value of cryptography is realized by minimizing the information available to potential adversaries. Thus professional cryptographers normally work in closed communities to provide sufficient professional interaction to ensure quality while maintaining secrecy from outsiders. Revelation of these secrets is normally only sanctioned in the interests of historical accuracy after it has been demonstrated clearly that no further benefit can be obtained from continued secrecy.

3. In keeping with this tradition it is now appropriate to tell the story of the invention and development within CESG of non-secret encryption (NSE) which was our original name for what is now called PKC. The task of writing this paper has devolved on me because NSE was my idea and I can therefore describe these early developments from personal experience. No techniques not already public knowledge, or specific applications of NSE will be mentioned. Neither shall I venture into evaluation. This is a simple, personal account of the salient features, with only the absolute minimum of mathematics.

4. The story begins in the 60's. The management of vast quantities of key material needed for secure communication was a headache for the armed forces. It was obvious to everyone, including me, that no secure communication was possible without secret key, some other secret knowledge, or at least some way in which the recipient was in a different position from an interceptor. After all, if they were in identical situations how could one possibly be able to receive what the other could not? Thus there was no incentive to look for something so clearly impossible.

5. The event which changed this view was the discovery of a wartime, Bell-Telephone report by an unknown author describing an ingenious idea for secure telephone speech (reference 2). It proposed that the recipient should mask the sender's speech by adding noise to the line. He could subtract the noise afterwards since he had added it and therefore knew what it was. The obvious practical disadvantages of this system prevented it being actually used, but it has some interesting characteristics. One of these, irrelevant to the main theme, is the amusing party trick of using the negative of the speech signal as the added noise. This leaves no signal on the line but the received signal unimpaired. This is easy to do and somewhat startling, but a simple analysis of the feedback shows that it is simply an amplifier with a low input impedance which shorts out the line.

6. The relevant point is that the receiver needs no special position or knowledge to get secure speech. No key is provided; the interceptor can know all about the system; he can even be given the choice of two independent identical terminals. If the interceptor pretends to be the recipient, he does not receive; he only destroys the message for the recipient by his added noise ...

Sadly, Alan Turing and others died before they were even acknowledged for their war efforts, let alone free to publicly disclose any details of their accomplishments even for academic research.

Even within the academic community, there's still confusion concerning who deserves the credit. According to http://www.acm.org/announcements/pr/pkaward.html

THE FIRST ACM PARIS KANELLAKIS THEORY AND PRACTICE AWARD GOES TO FOUNDERS OF PUBLIC-KEY CRYPTOGRAPHY

New York, NY February 12, 1997

The Association for Computing's (ACM) Paris Kanellakis Theory and Practice Award, named in memory of Paris Kanellakis whose tragic death in December 1995 cut short a distinguished research career, will be presented for the first time to the six founders of public-key cryptography. The Award will be given to Leonard Adleman, University of Southern California; Whitfield Diffie, Sun Microsystems; Martin Hellman, Stanford University; Ralph Merkle, Xerox PARC; Ronald Rivest, MIT; and Adi Shamir, The Weizmann Institute of Science, on Mar. 2,1997 ...

According to

http://livinginternet.com/i/is_crypt_pkc_inv.htm Public Key Cryptography – History: Diffie, Hellman and Merkle were the first to publish Public Key systems in 1976 and

Rivest, Shamir, Adleman. The Diffie-Hellman-Merkle key exchange algorithm provided an implementation for secure key distribution, but didn't implement digital signatures. After reading the Diffie-Hellman paper, three researchers at MIT named Ronald Rivest, Adi Shamir, and Leonard Adleman (RSA) began searching for a practical mathematical function to implement a complete PKC approach. After working on more than 40 candidates, they finally discovered an elegant algorithm based on the product of two prime numbers that exactly fit the requirement.

RSA's breakthrough was first publicized by Martin Gardner in August, 1977, in his widely read column Mathematical Games in the magazine Scientific American, and included an offer from RSA to mail a complete report on the method to anyone that requested it. Recognizing the power of the idea and fearing its use by non-government elements, the US National Security Agency (NSA) requested that RSA stop distributing the report. However, they were unable to provide a legal basis for their request, so the distribution continued. Then in February 1978, RSA published a more detailed paper on their work in the journal Communications of the ACM, and the cat was out of the bag for good.

Bellovin's web site mentions that many people were first aware of Public Key systems from Martin Gardner's column, but didn't credit RSA as his source. Perhaps it's not as highly regarded now, but Scientific American was the premiere science and math publication of the 1970s, so anything published there achieved high visibility more that any other publication of the time. CitingFRIES

Martin Gardner for many years has written regular columns for Scientific American magazine and then The Skeptical Inquirer on science and mathematics. No less than sixty-five books by him are listed in his new book, which collects recent columns from The Skeptical Inquirer, Scientific American, and other venues. Gardner is thus in the stratosphere of prolific science writers with the likes of the late and beloved Issac Asimov. If anything, Gardner seems better at the hard details of matters, especially in mathematics, than Asimov.

I hope this clarifies the chain of events and each person's contribution in the timeline.

III. Key Exchange

In his excellent presentation and corresponding paper, Michael Matos MATH04 already gave the history of Public Key Cryptography with the timeline of systems proposed, compromised and further refined. The matter of key distribution is a separate topic: PKI (Public Key Infrastructure) This presentation focuses on session key exchange, which for many systems is the only time public keys are used before switching mode to a secret key system for the rest of the session.

Unlike secret writing and secret-key cryptography, which are hundreds to thousands of years old, Public Key cryptography was invented in the 1970s. The difficulty is not the mathematics but the logic to the design: it is not analogous to anything animal, mineral or vegetable. That is what makes it hard to explain.

Symmetric (secret key) systems are mostly concerned with bit manipulations and one-way (trap door) algorithms so even knowing the algorithm, you can't just run it backwards. Public Key systems are also fully disclosed and reviewed because well-designed systems endure in the light of public scrutiny. Their success is due to proper design of a hard to break system.

Most Public Key systems depend on large prime numbers because factoring large numbers into their 2 prime numbers is still hard. Despite teraMip and teraFlop supercomputer clusters; current key lengths takes many years to solve. Number theory explains why this is a difficult problem to solve.

A. A firm foundation

Public key systems are the foundation upon which other secure systems and infrastructure are build offering

· Authentication

· Nonrepudiation

Entire messages may be encrypted for total privacy, or send in the clear yet electronically signed (so the receiver may read the message and optionally verify that the message was receive unaltered and from whom).

B. Secure for how long?

Public key systems depend on the mathematical problem that it's hard to factor large numbers into primes. The key length is chosen to keep ahead of computational power for the near future. This is where the tables of key length vs mip-years for attack from the class notes applies: the longer the key the longer an attacker ought to work. But longer keys also slow down the encryption/decrytion process, so there's a penalty for choosing keys longer than required for the desired protection.

C. Plays well with others

Public Key systems are slow in comparison to symmetric systems, so they're reserved for smaller messages such as signatures and authentication. They create the trust for the conversation to continue using a faster symmetric (secret key) method using a mutually agreeable one time session-key.

Systems that interact in real-time use public keys to prove each side's identity. Messages that are retrieved later (such as email, FTP, CDs, floppy disks) may be totally encrypted to prevent unauthorized access, or signed with a MAC: Message Authentication Code, which is a message digest encrypted with the sender's private key. That way the message is still readable but any alteration is detected because imposters cannot recreate the required matching signature. Software distribution (whether on CD or downloaded online) is often signed this way to prevent tampering and prove that it came directly from the manufacturer.

D. Diffie Hellman key exchange

Whitfield Diffie and Martin Hellman introduced the Diffie-Hellman algorithm in 1976. It was the first public system to utilize "public-key" or "asymmetric" cryptographic keys. It's still the primary way to generate an ephemeral (one time) session key for SSL, VPN, IPSec, etc. Key exchange generates a "shared secret" ideal for symmetric systems such as AES or 3DES for encrypting the payload.

Bob and Alice initiate a secure session with Diffie-Hellman key exchange

Alice and Bob agree a priori a large prime n and g. These numbers are not secret! They may publish them since the attacker knowing these numbers does not diminish the security of the system.

· Alice chooses a random integer x and sends Bob X=g^x mod n

· Bob chooses a random integer y and sends Alice Y=g^y mod n

· Alice computes k=Y^x mod n

· Bob computes k'=X^y mod n

K and K' are both g^xy mod n, the shared secret, which Alice and Bob now use as the key to the symmetric method of their choice. This is ideal for wireless or internet links because the public values may be exchanged on an unsecured link. An eavesdropper cannot arrive at the shared secret despite seeing the numbers passed across.

3 or more parties may arrive at a shared secret as follows:

· Alice chooses a large random integer x and sends Bob X=g^x mod n

· Bob chooses a large random integer y and sends Carol Y=g^y mod n

· Carol chooses a large random integer z and sends Alice Z=g^z mod n

· Alice sends Bob Z'=Z^x mod n

· Bob sends Carol X'=X^y mod n

· Carol sends Alice Y'=Y^z mod n

· Alice computes k=Y'^x mod n

· Bob computes k=Z'^y mod n

· Carol computes k=X'^z mod n

All 3 arrive at the same secret k = g^xyz mod n. Regardless of the number of participants, the handshaking must proceed around the circle twice for all the values to circulate properly.

E. Delayed key exchange

Alice can encrypt a message using key k and leave the message for delayed reception (e-mail it to Bob, place it on an FTP site for Bob to download later, burn it to a CD, etc). Bob requires the key k to decrypt the message, but Alice cannot simply tell him because they're using an insecure channel, so this exchange occurs:

1. Alice chooses a random large integer x and generates k=g^x mod n and encrypts a message with key k

2. Bob chooses a random large integer y and sends Alice Y=g^ymod n

3. Alice sends Bob X=Y^x mod n

4. Bob computes z=y^-1 k=X^z mod n and decrypts the message with key k.

This allows even insecure channels to convey the messages for Bob to decrypt the file and eavesdroppers are left bewildered.

The advantage to this method is that Alice may reply to many queries for the password from people other than Bob. The disadvantage is the need for an active server on Alice's part to reply to Bob's query for the password used for the file. SCHNE96page 51 lists more appropriate ways to accomplish this:

1. Alice chooses a random key k and encrypts the message.

2. Key k is then encrypted with Bob's public key and sent along with the message.

3. Bob then decrypts the key using his private key to recover key k and uses that to decrypt the accompanying message.

A one time symmetric key is used instead of Bob's public key because encrypting the entire message with Bob's public key would take more time and effort for both Alice and Bob without giving any greater security. The disadvantage is that Alice needs to encrypt the key k separately using each person’s public key if more than one recipient is intended.

F. Key Exchange weaknesses

In its simple form, Diffie Hellman key exchange offers no authentication, leading to

· Impersonations

· Man-in-the-middle / bucket-brigade attack

For example: what if Bob's evil twin Skippy impersonates him when Alice calls? Skippy knows the key exchange algorithm (it's not a secret) and even the parameters that Alice and Bob prefer when arriving at a shared secret so he can create a session to Alice because Bob does not do anything that is unique to him.

An active attacker can capitalize on that with a bucket-brigade (man in the middle) attack (assuming that he can put himself in the middle of the connection). The active attacker merely holds 2 conversations, negotiating each session key separately.

Alice <-> Mallory <-> Bob

Malicious Mallory actively intercepts the messages between Alice and Bob. Mallory may eavesdrop and pass the messages across unaltered, alter messages, insert or delete messages too.

Such attacks are thwarted by forcing the other party to do something that ONLY they can do: decrypt something encrypted with their public key! Alice and Bob only need to defend the key negotiation process, for once they agree on a session key and switch to a symmetric encryption, Mallory, Eve and all other intruders are locked out.

G. Authenticated Diffie Hellman

When Alice and Bob exchange their public values during the key exchange, they add a step that only they can do, or force the receiver to do something unique to them to prove their identity.

For advisory authentication, they send the public value "in the clear" (not encrypted) but sign the value with their private key to prove that only they could have transmitted the number. This way the receiver may affirm the other's identity or just continue in blind faith.

Consider these protocols

1) Encrypting the public value with your own private key proves the sender’s identity because that is something only you can do:

from Alice --->

<---- from Bob

This still doesn't thwart the man in the middle for he too has the public keys to decrypt the values, but at least both sides have identified themselves to the attacker!

2) Encrypt with the other party's public key so only the intended receiver can unwrap the key within:

this is for Bob ---->

<-- this is for Alice

An attacker cannot reveal either message because that requires the receiver's private key, so Mallory is out of business.

3) Alice can "double wrap" the message by encrypting it with her private key, then encrypting with Bob's public key, essentially saying

(this is from Alice) for Bob

Only Bob can remove the outer wrapper by decrypting with his private key, and then by decrypting the message again with Alice's public key Bob is assured that only Alice could have generated that message.

In general: attacks are thwarted by forcing the other party to do something that ONLY they can do: decrypt something encrypted with their public key!

H. Stronger authentication

Diagrams are from PALMG01

Alice and Bob first exchange public keys. The numbers used for the key exchange are now perturbed by the public and private keys, thus proving each others' identity and agree on a session key in one step without the need to encrypt and decrypt each message.

Certicom is a leading vendor of Elliptic Curve cryptography products that accomplish the above authenticate key exchange. Citing

http://www.certicom.com/index.php?action=res,cc_1_2&article=4-mqv

The article on Key Establishment Schemes (found in this issue of Code and Cipher) outlines a number of different options for key establishment and the desirable security attributes. This article focuses on two schemes for key agreement: the Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Menezes-Qu-Vanstone (MQV).

ECDH is the elliptic curve analog of the traditional Diffie-Hellman key agreement algorithm. The Diffie-Hellman method requires no prior contact between the two parties…

The MQV elliptic curve key agreement method is used to establish a shared secret between parties who already possess trusted copies of each other's static public keys. Both parties still generate dynamic public and private keys and then exchange public keys. However, upon receipt of the other party's public key, each party calculates a quantity called an implicit signature using its own private key and the other party's public key. The shared secret is then generated from the implicit signature. The term implicit signature is used to indicate that the shared secrets do not agree if the other party's public key is not employed, thus giving implicit verification that the public secret is generated by the public party. An attempt at interception will fail as the shared secrets will not be the same shared secrets because the adversary's private key is not linked to the trusted public key.

I used Certicom's security libraries for an assignment where wireless devices created a secure link to the server. Only the server had a private key, so the wireless clients all had a constant key to the MQV function call. That was enough to prevent impersonating the server or man-in-the-middle attack.

I. Other key exchange methods

· Shamir's Three-Pass Protocol

· COMSET: COMmunications SETup

· EKE: Encrypted Key Exchange

· Fortified Key Negotiation

· Conference Key Distribution

· RSA

· Fortezza

for more information, see http://home.att.net/~lewis.mccarthy/InfosecProjects/KEA

J. Public Key publication

How do Alice and Bob get each other's public key for authentication?

· Trade it directly

· Get it from a trusted friend

· Get it from a trusted friend of a friend

This is the start of a chain of trust. But what if someone lies or helps an imposter? That leads to Key Management and PKI: Public Key Infrastructure

I offer an analogy: I have several people's phone numbers. Rajat trusts me so when I give him the phone list, he trusts them to be valid. Even if some I got some of the numbers indirectly, trust is transitory so Rajat trusts my phone list even for numbers I did not get directly.

Similarly, Alice does not need to get Bob's public key directly from him, but from a source she trusts. PGP talks of "Key Rings": lists of identities and public keys that are shared among people without the need for a central server or authority.

To thwart intermediaries from altering others' keys with which they're entrusted, the public key is wrapped in a wrapper called a Certificate.

A quick aside: network administrators deal with similar problems with DNS: Domain Name Service: the infrastructure that maps names such as njit.edu into the corresponding IP address. There are too many computers on the internet for everyone to keep a complete list so there's a heirarchy of caching controllers to answer the queries and relieve the burdeon on the top level domain servers (which are replicated for safety and load sharing). But information goes stale, and false information may be injected to steal/redirect traffic. This could even be part of a Denial-of-Service attack to thwart Certificate validation by misdirecting connections intended for verisign.com to a pirate site.

Back to the certificate analogy: the database problem is common to both: the need to handle stale or invalidated records, and preventing false data from entering the system or being returned to queries.

K. Certificates

Certificates are analogous to a driver's license (or photo ID or passport). If everyone were allowed to generate their own driver's license they'd all give themselves permission to drive anything, anywhere, and perhaps give themselves many different names and identities even resorting to using other people's identities. That's why driver's licenses are issued by a trusted issuer: the state DMV (Department of Motor Vehicles): they are entrusted to prevent such abuses. The license is laminated and uses other devices to thwart alteration. Even with such safeguards, police always validate the information and license status with the DMV.

Similarly, certificates are an electronic ID card, linking a public key to a user. They're electronically signed by the issuer to prevent alteration, so the certificate is a stand alone document. The subject of the certificate may hand it to you without diminishing trust. But you have the ability to validate the certificate on your own to prove it is valid.

X.509 certificates are an industry standard, supported by many well-known companies and all public key systems.

A certificate contains:

· subject name

· subject public key and algorithm

· Version

· serial number

· algorithm identifier

· Issuer

· period of validity

· issuer unique ID

· subject unique ID

· Extensions

· signature by the issuer, using their private key

The first 2 fields concern associating a public key to a user. The rest of the certificate fields concern authenticating the certificate itself; assuring that it was not altered and how to ascend the chain-of-trust to authenticate the signature and verify the certificate is still valid.

L. More building blocks

Certicom, RSA and others supply these building blocks as software libraries, already tested and ported to many platforms and operating systems.

When I worked at a wireless pager company, someone who barely understood cryptography had implemented encryption on their communications. It was slow because public key encryption was used for everything, including the payload! The session keys were random but entropy was low, and the key exchange was a homebrew method.

I concentrated on the protocol and used public key signed Diffie Hellman Key exchange to authenticate the server side (the individual devices had no private/public key) and generate the session key for 3DES for the rest of the session. CFB mode was chosen because it's the only one that recovers from synchronization errors [SCHNE96 Pg 209] The resulting system was much faster, did not introduce any new keys (which would require management) while preventing impersonations or imposters.

Certicom CERTI libraries were used because they are ported and supported for all the portable devices (Windows CE, PalmOS, PocketPC, RimOS) as well as the servers (Windows 2k/XT/ME/NT, Solaris, Linux). They provide updates and maintenance on the software to assure compliance to standards (when applicable) and interoperability. It was also an advertising plus to show the Certicom logo since "branding" is more recognizable than trying to explain the algorithms implemented. Certicom is a major advocate of elliptic curve systems so they have many white papers on their web site http://www.certicom.com

M. A followup question

A question was asked after my presentation concerning SSL session key negotiation when the server has a certificate for its public key. A web search for the terms "ssl ephemeral" found related documentation such as SSL key exchange modes, additional key exchange methods http://www.hk8.org/old_web/linux/apache/appd_01.htm

SSL has several ways to arrive at the session key THOMA. If either or both sides have certificates, then the public key is used with the session key negotiation to provide authentication and thwart man-in-the-middle attacks. Only if no private keys are available is anonymous key exchange used to provide a secure channel. Victor A. Mancheno's "SSL/TLS" presentation MANCH mentions the exchange of a pre_master_secret which participates in the computation of the MAC keys. That indicates a key exchange mechanism, which is further explained in http://www.hk8.org/old_web/linux/apache/appd_01.htm

D.1.1. Authentication and Key Exchange

SSL supports three authentication modes: authentication of both parties, server authentication with an unauthenticated client, and total anonymity. Whenever the server is authenticated, the channel should be secure against man-in-the-middle attacks, but completely anonymous sessions are inherently vulnerable to such attacks. Anonymous servers cannot authenticate clients, since the client signature in the certificate verify message may require a server certificate to bind the signature to a particular server. If the server is authenticated, its certificate message must provide a valid certificate chain leading to an acceptable certificate authority. Similarly, authenticated clients must supply an acceptable certificate to the server. Each party is responsible for verifying that the other's certificate is valid and has not expired or been revoked.

The general goal of the key exchange process is to create a pre_master_secret known to the communicating parties and not to attackers. The pre_master_secret will be used to generate the master_secret. The master_secret is required to generate the finished messages, encryption keys, and MAC secrets. By sending a correct finished message, parties prove that they know the correct pre_master_secret.

D.1.1.1. Anonymous key exchange

Completely anonymous sessions can be established using RSA, Diffie-Hellman, or Fortezza for key exchange. With anonymous RSA, the client encrypts a pre_master_secret with the server's uncertified public key extracted from the server key exchange message. The result is sent in a client key exchange message. Since eavesdroppers do not know the server's private key, it will be infeasible for them to decode the pre_master_secret.

With Diffie-Hellman or Fortezza, the server's public parameters are contained in the server key exchange message and the client's are sent in the client key exchange message. Eavesdroppers who do not know the private values should not be able to find the Diffie-Hellman result (i.e., the pre_master_secret) or the Fortezza token encryption key (TEK).

N. Why Johnny Can't Encrypt

In WHITT99 the analysis found a number of user interface design flaws that contributed to security failures. The user test demonstrated that when test participants were given 90 minutes in which to sign and encrypt a message using PGP 5.0, the majority of them were unable to do so successfully.

How can the process be made easier without letting users compromise their security?

· use dedicated hardware such as SmartCards to hold the private key and prevent accidental disclosure.

· easier to use software per Jerry Chen’s proposed Non-Repudiation Secure File Transfer CHEN04 (but the private keys are still in files vulnerable to attack)

Consider the current state of "social engineering" for malware such as virus or worms: people are slowly learning to not trust email from strangers and how opening innocent looking email enclosures tends to allow the malware to spread to their computers. So the next step was disguising the malware as software from "trusted sources" such as Microsoft updates or email updates from their internet provider, complete with their name and partial information about their provider extracted from the email address. If existing computer interfaces cannot clearly block malware automatically or properly convey the consequences of the user action, then what hope is of having naive users comprehend a chain of trust and Certificate Authorities?

Many electronic intrusions are now accomplished without any user interactions: just receiving email with particular enclosures or URLs may cause auto-execution of malware on the remote computer. Computer users are already overwhelmed with all the individual responsibility for monitoring and maintaining their hardware, software and operating environment.

IV. In conclusion

Despite the development of wonderful machines and mechanisms intended to protect one's data, humans are still the weakest part of the system.

V. for further information:

http://csrc.nist.gov/pki/ NIST PKI Program

The National Institute of Standards and Technology (NIST) is taking a leadership role in the development of a Federal Public Key Infrastructure that supports digital signatures and other public key-enabled security services. NIST is coordinating with industry and technical groups developing PKI technology to foster interoperability of PKI products and projects. In support of digital signatures, NIST has worked with the Federal

PKI Steering Committee to produce digital signature guidance.

http://www.pki-page.org The PKI page

This page contains links to various sites and documents which are related to Public Key Infrastructure (PKI) stuff, especially links to all Certification Authorities (CAs) I'm aware of.

http://www.infosyssec.net/infosyssec/secpki1.htm

INFOSYSSEC: The Security Portal for Information System Security Professionals. The most comprehensive computer and network security resource on the Internet for Information System Security Professionals - Says Yahoo Editors

http://id-discussions.com/ Interesting Devices Ltd

Discussions of security devices such as RFID tags and SmartCards.

http://infosecuritymag.techtarget.com/ss/0,295796,sid6_ss288_art536,00.html Painless PGP