home *** CD-ROM | disk | FTP | other *** search
/ Danny Amor's Online Library / Danny Amor's Online Library - Volume 1.iso / html / faqs / faq / cryptography-faq / rsa.part3 < prev   
Encoding:
Text File  |  1995-07-25  |  53.2 KB  |  1,136 lines

  1. Subject: RSA Cryptography Today FAQ (3/3)
  2. Newsgroups: sci.crypt,talk.politics.crypto,alt.security.ripem,sci.answers,talk.answers,alt.answers,news.answers
  3. From: faq-editor@rsa.com
  4. Date: 13 Nov 1994 03:48:46 GMT
  5.  
  6. Archive-name: cryptography-faq/rsa/part3
  7. Last-modified: 93/09/20
  8. Version: 2.0
  9. Distribution-agent: tmp@netcom.com
  10.  
  11.  
  12. (This document has been brought to you in part by CRAM.  See the
  13. bottom for more information, including instructions on how to
  14. obtain updates.)
  15.  
  16. ===
  17.  
  18.  
  19.  
  20.                           Answers To
  21.                  FREQUENTLY ASKED QUESTIONS
  22.                  About Today's Cryptography
  23.  
  24.  
  25.  
  26.                           Paul Fahn
  27.                       RSA Laboratories
  28.                      100 Marine Parkway
  29.                    Redwood City, CA  94065
  30.  
  31.  
  32.  
  33.    Copyright (c) 1993 RSA Laboratories, a division of RSA Data Security,
  34.       Inc. All rights reserved.
  35.  
  36.    Version 2.0, draft 2f
  37.    Last update: September 20, 1993
  38.  
  39.  
  40.  
  41. ------------------------------------------------------------------------
  42.                          Table of Contents
  43.  
  44. [part 3]
  45.  
  46. 6 Capstone, Clipper, and DSS 
  47.        6.1  What is Capstone? 
  48.        6.2  What is Clipper? 
  49.        6.3  How does the Clipper chip work? 
  50.        6.4  Who are the escrow agencies? 
  51.        6.5  What is Skipjack? 
  52.        6.6  Why is Clipper controversial? 
  53.        6.7  What is the current status of Clipper? 
  54.        6.8  What is DSS? 
  55.        6.9  Is DSS secure? 
  56.        6.10  Is use of DSS covered by any patents? 
  57.        6.11  What is the current status of DSS? 
  58.  
  59. 7 NIST and NSA 
  60.        7.1  What is NIST? 
  61.        7.2  What role does NIST play in cryptography? 
  62.        7.3  What is the NSA? 
  63.        7.4  What role does the NSA play in commercial cryptography? 
  64.  
  65. 8 Miscellaneous 
  66.        8.1  What is the legal status of documents signed with digital 
  67.             signatures? 
  68.        8.2  What is a hash function? What is a message digest? 
  69.        8.3  What are MD2, MD4 and MD5? 
  70.        8.4  What is SHS? 
  71.        8.5  What is Kerberos? 
  72.        8.6  What are RC2 and RC4? 
  73.        8.7  What is PEM? 
  74.        8.8  What is RIPEM? 
  75.        8.9  What is PKCS? 
  76.        8.10  What is RSAREF? 
  77.  
  78. --------------------------------------------------------------------
  79.  
  80.  
  81. 6 Capstone, Clipper, and DSS
  82.  
  83. 6.1 What is Capstone?
  84.  
  85. Capstone is the U.S. government's long-term project to develop a set
  86. of standards for publicly-available cryptography, as authorized by 
  87. the Computer Security Act of 1987. The primary agencies responsible 
  88. for Capstone are NIST and the NSA (see Section 7). The plan calls for 
  89. the elements of Capstone to become official U.S. government standards, 
  90. in which case both the government itself and all private companies doing 
  91. business with the government would be required to use Capstone.
  92.  
  93. There are four major components of Capstone: a bulk data encryption
  94. algorithm, a digital signature algorithm, a key exchange protocol, and
  95. a hash function. The data encryption algorithm is called Skipjack (see 
  96. Question 6.5), but is often referred to as Clipper, which is the 
  97. encryption chip that includes Skipjack (see Question 6.2). The digital 
  98. signature algorithm is DSS (see Question 6.8) and the hash function is 
  99. SHS (see Question 8.4 about SHS and Question 8.2 about hash functions). 
  100. The key exchange protocol has not yet been announced. 
  101.  
  102. All the parts of Capstone have 80-bit security: all the keys involved
  103. are 80 bits long and other aspects are also designed to withstand 
  104. anything less than an ``80-bit'' attack, that is, an effort of 2^{80} 
  105. operations. Eventually the government plans to place the entire Capstone 
  106. cryptographic system on a single chip.
  107.  
  108.  
  109. 6.2 What is Clipper?
  110.  
  111. Clipper is an encryption chip developed and sponsored by the U.S. 
  112. government as part of the Capstone project (see Question 6.1).
  113. Announced by the White House in April, 1993 [65], Clipper was designed 
  114. to balance the competing concerns of federal law-enforcement agencies 
  115. with those of private citizens and industry. The law-enforcement 
  116. agencies wish to have access to the communications of suspected 
  117. criminals, for example by wire-tapping; these needs are threatened by 
  118. secure cryptography. Industry and individual citizens, however, want 
  119. secure communications, and look to cryptography to provide it.
  120.  
  121. Clipper technology attempts to balance these needs by using escrowed
  122. keys. The idea is that communications would be encrypted with a 
  123. secure algorithm, but the keys would be kept by one or more third 
  124. parties (the ``escrow agencies''), and made available to law-enforcement 
  125. agencies when authorized by a court-issued warrant. Thus, for 
  126. example, personal communications would be impervious to recreational 
  127. eavesdroppers, and commercial communications would be impervious to 
  128. industrial espionage, and yet the FBI could listen in on suspected 
  129. terrorists or gangsters. 
  130.  
  131. Clipper has been proposed as a U.S. government standard [62]; it would 
  132. then be used by anyone doing business with the federal government as well 
  133. as for communications within the government. For anyone else, use of 
  134. Clipper is strictly voluntary. AT&T has announced a secure telephone 
  135. that uses the Clipper chip.
  136.  
  137.  
  138. 6.3 How does the Clipper chip work?
  139.  
  140. The Clipper chip contains an encryption algorithm called Skipjack (see
  141. Question 6.5}), whose details have not been made public. Each chip 
  142. also contains a unique 80-bit unit key U, which is escrowed in two parts 
  143. at two escrow agencies; both parts must be known in order to recover the 
  144. key. Also present is a serial number and an 80-bit ``family key'' F; the 
  145. latter is common to all Clipper chips. The chip is manufactured so that it 
  146. cannot be reverse engineered; this means that the Skipjack algorithm and 
  147. the keys cannot be read off the chip.
  148.  
  149. When two devices wish to communicate, they first agree on an 80-bit
  150. ``session key'' K. The method by which they choose this key is left
  151. up to the implementer's discretion; a public-key method such as RSA or
  152. Diffie-Hellman seems a likely choice. The message is encrypted with
  153. the key K and sent; note that the key K is not escrowed. In addition 
  154. to the encrypted message, another piece of data, called the law-enforcement 
  155. access field (LEAF), is created and sent. It includes the session key K 
  156. encrypted with the unit key U, then concatenated with the serial number 
  157. of the sender and an authentication string, and then, finally, all encrypted 
  158. with the family key. The exact details of the law-enforcement field are 
  159. classified.
  160.  
  161. The receiver decrypts the law-enforcement field, checks the authentication
  162. string, and decrypts the message with the key K. 
  163.  
  164. Now suppose a law-enforcement agency wishes to tap the line. It uses the
  165. family key to decrypt the law-enforcement field; the agency now knows the
  166. serial number and has an encrypted version of the session key. It presents
  167. an authorization warrant to the two escrow agencies along with the serial
  168. number. The escrow agencies give the two parts of the unit key to the
  169. law-enforcement agency, which then decrypts to obtain the session key K.
  170. Now the agency can use K to decrypt the actual message.
  171.  
  172. Further details on the Clipper chip operation, such as the generation
  173. of the unit key, are sketched by Denning [26].
  174.  
  175.  
  176. 6.4 Who are the escrow agencies?
  177.  
  178. It has not yet been decided which organizations will serve as the escrow
  179. agencies, that is, keep the Clipper chip keys. No law-enforcement agency
  180. will be an escrow agency, and it is possible that at least one of the
  181. escrow agencies will be an organization outside the government.
  182.  
  183. It is essential that the escrow agencies keep the key databases
  184. extremely secure, since unauthorized access to both escrow 
  185. databases could allow unauthorized eavesdropping on private
  186. communications. In fact, the escrow agencies are likely to be one
  187. of the major targets for anyone trying to compromise the Clipper
  188. system; the Clipper chip factory is another likely target.
  189.  
  190.  
  191. 6.5 What is Skipjack?
  192.  
  193. Skipjack is the encryption algorithm contained in the Clipper chip; it was 
  194. designed by the NSA. It uses an 80-bit key to encrypt 64-bit blocks of data; 
  195. the same key is used for the decryption. Skipjack can be used in the same 
  196. modes as DES (see Question 5.3), and may be more secure than DES, since
  197. it uses 80-bit keys and scrambles the data for 32 steps, or ``rounds''; by
  198. contrast, DES uses 56-bit keys and scrambles the data for only 16 rounds.
  199.  
  200. The details of Skipjack are classified. The decision not to make the details 
  201. of the algorithm publicly available has been widely criticized. Many people 
  202. are suspicious that Skipjack is not secure, either due to oversight by its 
  203. designers, or by the deliberate introduction of a secret trapdoor. By contrast,
  204. there have been many attempts to find weaknesses in DES over the years, since 
  205. its details are public. These numerous attempts (and the fact that they have 
  206. failed) have made people confident in the security of DES. Since Skipjack is
  207. not public, the same scrutiny cannot be applied towards it, and thus a 
  208. corresponding level of confidence may not arise. 
  209.  
  210. Aware of such criticism, the government invited a small group of independent 
  211. cryptographers to examine the Skipjack algorithm. They issued a report 
  212. [12] which stated that, although their study was too limited to reach a 
  213. definitive conclusion, they nevertheless believe that Skipjack is secure.
  214.  
  215. Another consequence of Skipjack's classified status is that it cannot
  216. be implemented in software, but only in hardware by government-authorized
  217. chip manufacturers.
  218.  
  219.  
  220. 6.6 Why is Clipper controversial?
  221.  
  222. The Clipper chip proposal has aroused much controversy and has been the
  223. subject of much criticism. Unfortunately two distinct issues have become 
  224. confused in the large volume of public comment and discussion. 
  225.  
  226. First there is controversy about the whole idea of escrowed keys.
  227. Those in favor of escrowed keys see it as a way to provide secure 
  228. communications for the public at large while allowing law-enforcement 
  229. agencies to monitor the communications of suspected criminals. Those
  230. opposed to escrowed keys see it as an unnecessary and ineffective
  231. intrusion of the government into the private lives of citizens. They
  232. argue that escrowed keys infringe their rights of privacy and free
  233. speech. It will take a lot of time and much public discussion for society
  234. to reach a consensus on what role, if any, escrowed keys should have.
  235.  
  236. The second area of controversy concerns various objections to the
  237. specific Clipper proposal, that is, objections to this particular
  238. implementation of escrowed keys, as opposed to the idea of escrowed
  239. keys in general. Common objections include: the Skipjack algorithm
  240. is not public (see Questions 6.5) and may not be secure; the key 
  241. escrow agencies will be vulnerable to attack; there are not enough
  242. key escrow agencies; the keys on the Clipper chips are not generated
  243. in a sufficiently secure fashion; there will not be sufficient 
  244. competition among implementers, resulting in expensive and slow chips;
  245. software implementations are not possible; and the key size is fixed
  246. and cannot be increased if necessary.
  247.  
  248. Micali [55] has recently proposed an alternative system that also 
  249. attempts to balance the privacy concerns of law-abiding citizens with 
  250. the investigative concerns of law-enforcement agencies. Called fair 
  251. public-key cryptography, it is similar in function and purpose to the 
  252. Clipper chip proposal but users can choose their own keys, which they 
  253. register with the escrow agencies. Also, the system does not require 
  254. secure hardware, and can be implemented completely in software.
  255.  
  256.  
  257. 6.7 What is the current status of Clipper?
  258.  
  259. Clipper is under review. Both the executive branch and Congress are
  260. considering it, and an advisory panel recently recommended a full
  261. year-long public discussion of cryptography policy. NIST has invited 
  262. the public to send comments, as part of its own review.
  263.  
  264.  
  265. 6.8 What is DSS?
  266.  
  267. DSS is the proposed Digital Signature Standard, which specifies a 
  268. Digital Signature Algorithm (DSA), and is a part of the U.S. government's
  269. Capstone project (see Question 6.1). It was selected by NIST, 
  270. in cooperation with the NSA (see Section 7), to be the digital 
  271. authentication standard of the U.S. government; whether the government 
  272. should in fact adopt it as the official standard is still 
  273. under debate. 
  274.  
  275. DSS is based on the discrete log problem (see Question 4.9) and derives 
  276. from cryptosystems proposed by Schnorr [75] and ElGamal [30]. It is for 
  277. authentication only. For a detailed description of DSS, see [63] or [57].
  278.  
  279. DSS has, for the most part, been looked upon unfavorably by the computer 
  280. industry, much of which had hoped the government would choose the RSA 
  281. algorithm as the official standard; RSA is the most widely used 
  282. authentication algorithm. Several articles in the press, such as [54], 
  283. discuss the industry dissatisfaction with DSS. Criticism of DSS has 
  284. focused on a few main issues: it lacks key exchange capability; the 
  285. underlying cryptosystem is too recent and has been subject to too little 
  286. scrutiny for users to be confident of its strength; verification of 
  287. signatures with DSS is too slow; the existence of a second authentication 
  288. standard will cause hardship to computer hardware and software vendors, who 
  289. have already standardized on RSA; and that the process by which NIST chose 
  290. DSS was too secretive and arbitrary, with too much influence wielded by NSA. 
  291. Other criticisms were addressed by NIST by modifying the original proposal. 
  292. A more detailed discussion of the various criticisms can be found in 
  293. [57], and a detailed response by NIST can be found in [78].
  294.  
  295. In the DSS system, signature generation is faster than signature 
  296. verification, whereas in the RSA system, signature verification is 
  297. faster than signature generation (if the public and private exponents 
  298. are chosen for this property, which is the usual case). NIST claims 
  299. that it is an advantage of DSS that signing is faster, but many people 
  300. in cryptography think that it is better for verification to be the 
  301. faster operation. 
  302.  
  303.  
  304. 6.9 Is DSS secure?
  305.  
  306. The most serious criticisms of DSS involve its security. DSS was originally 
  307. proposed with a fixed 512-bit key size. After much criticism that this is 
  308. not secure enough, NIST revised DSS to allow key sizes up to 1024 bits. More 
  309. critical, however, is the fact that DSS has not been around long enough to 
  310. withstand repeated attempts to break it; although the discrete log problem 
  311. is old, the particular form of the problem used in DSS was first proposed 
  312. for cryptographic use in 1989 by Schnorr [75] and has not received much 
  313. public study. In general, any new cryptosystem could have serious flaws 
  314. that are only discovered after years of scrutiny by cryptographers. Indeed 
  315. this has happened many times in the past; see [13] for some detailed 
  316. examples. RSA has withstood over 15 years of vigorous examination for 
  317. weaknesses. In the absence of mathematical proofs of security, nothing 
  318. builds confidence in a cryptosystem like sustained attempts to crack it. 
  319. Although DSS may well turn out to be a strong cryptosystem, its relatively 
  320. short history will leave doubts for years to come.
  321.  
  322. Some researchers warned about the existence of ``trapdoor'' primes in
  323. DSS, which could enable a key to be easily broken. These trapdoor primes
  324. are relatively rare however, and are easily avoided if proper key
  325. generation procedures are followed [78].
  326.  
  327.  
  328. 6.10 Is use of DSS covered by any patents?
  329.  
  330. NIST has filed a patent application for DSS and there have been claims that 
  331. DSS is covered by other public-key patents. NIST recently announced its 
  332. intention to grant exclusive sublicensing rights for the DSS patent to Public 
  333. Key Partners (PKP), which also holds the sublicensing rights to other patents 
  334. that may cover DSS (see Question 1.5). In the agreement between NIST and 
  335. PKP, PKP publicly stated uniform guidelines by which it will grant licenses 
  336. to practice DSS. PKP stated that DSS can be used on a royalty-free basis 
  337. in the case of personal, noncommercial, or U.S. government use. See [61] 
  338. for details on the agreement and the licensing policy.
  339.  
  340.  
  341. 6.11 What is the current status of DSS?
  342.  
  343. After NIST issued the DSS proposal in August 1991, there was a period 
  344. in which comments from the public were solicited; NIST then revised its
  345. proposal in light of the comments. DSS may be issued as a FIPS and become 
  346. the official U.S. government standard, but it is not clear when this 
  347. might happen. DSS is currently in the process of becoming a standard, 
  348. along with RSA, for the financial services industry; a recent draft 
  349. standard [1] contains the revised version of DSS.
  350.  
  351.  
  352. 7 NIST and NSA
  353.  
  354. 7.1 What is NIST?
  355. NIST is an acronym for the National Institute of Standards and Technology,
  356. a division of the U.S. Department of Commerce; it was formerly known as
  357. the National Bureau of Standards (NBS). Through its Computer Systems
  358. Laboratory it aims to promote open systems and interoperability that
  359. will spur development of computer-based economic activity. NIST issues
  360. standards and guidelines that it hopes will be adopted by all computer
  361. systems in the U.S., and also sponsors workshops and seminars. Official 
  362. standards are published as FIPS (Federal Information Processing Standards) 
  363. publications.
  364.  
  365. In 1987 Congress passed the Computer Security Act, which authorized NIST 
  366. to develop standards for ensuring the security of sensitive but unclassified 
  367. information in government computer systems. It encouraged NIST to work with 
  368. other government agencies and private industry in evaluating proposed 
  369. computer security standards.
  370.  
  371.  
  372. 7.2 What role does NIST play in cryptography?
  373.  
  374. NIST issues standards for cryptographic routines; U.S. government agencies
  375. are required to use them, and the private sector often adopts them as well.
  376. In January 1977, NIST declared DES (see Question 5.1) the official U.S. 
  377. encryption standard and published it as FIPS Publication 46; DES soon 
  378. became a de facto standard throughout the U.S.
  379.  
  380. A few years ago, NIST was asked to choose a set of cryptographic standards
  381. for the U.S.; this has become known as the Capstone project (see Section 
  382. 6). After a few years of rather secretive deliberations, and in cooperation 
  383. with the NSA, NIST issued proposals for various standards in cryptography, 
  384. including digital signatures (DSS) and data encryption (the Clipper chip); 
  385. these are pieces of the overall Capstone project.
  386.  
  387. NIST has been criticized for allowing the NSA too much power in setting 
  388. cryptographic standards, since the interests of the NSA conflict with that 
  389. of the Commerce Department and NIST. Yet, the NSA has much more experience
  390. with cryptography, and many more qualified cryptographers and cryptanalysts,
  391. than does NIST; it would be unrealistic to expect NIST to forego such 
  392. available assistance.
  393.  
  394.  
  395. 7.3 What is the NSA?
  396.  
  397. The NSA is the National Security Agency, a highly secretive agency of the 
  398. U.S. government that was created by Harry Truman in 1952; its very existence 
  399. was kept secret for many years. For a history of the NSA, see Bamford [2].
  400. The NSA has a mandate to listen to and decode all foreign communications of 
  401. interest to the security of the United States. It has also used its power 
  402. in various ways (see Question 7.4) to slow the spread of publicly available 
  403. cryptography, in order to prevent national enemies from employing encryption 
  404. methods too strong for the NSA to break.
  405.  
  406. As the premier cryptographic government agency, the NSA has huge financial 
  407. and computer resources and employs a host of cryptographers. Developments in 
  408. cryptography achieved at the NSA are not made public; this secrecy has led to 
  409. many rumors about the NSA's ability to break popular cryptosystems like DES 
  410. and also to rumors that the NSA has secretly placed weaknesses, called trap 
  411. doors, in government-endorsed cryptosystems, such as DES. These rumors have 
  412. never been proved or disproved, and the criteria used by the NSA in selecting 
  413. cryptography standards have never been made public. 
  414.  
  415. Recent advances in the computer and telecommunications industries have 
  416. placed NSA actions under unprecedented scrutiny, and the agency has become 
  417. the target of heavy criticism for hindering U.S. industries that wish to use 
  418. or sell strong cryptographic tools. The two main reasons for this increased 
  419. criticism are the collapse of the Soviet Union and the development and 
  420. spread of commercially available public-key cryptographic tools. Under 
  421. pressure, the NSA may be forced to change its policies.
  422.  
  423.  
  424. 7.4 What role does the NSA play in commercial cryptography?
  425.  
  426. The NSA's charter limits its activities to foreign intelligence. However,
  427. the NSA is concerned with the development of commercial cryptography
  428. because the availability of strong encryption tools through commercial 
  429. channels could impede the NSA's mission of decoding international 
  430. communications; in other words, the NSA is worried lest strong commercial 
  431. cryptography fall into the wrong hands. 
  432.  
  433. The NSA has stated that it has no objection to the use of secure cryptography
  434. by U.S. industry. It also has no objection to cryptographic tools used for
  435. authentication, as opposed to privacy. However, the NSA is widely viewed as
  436. following policies that have the practical effect of limiting and/or weakening
  437. the cryptographic tools used by law-abiding U.S. citizens and corporations;
  438. see Barlow [3] for a discussion of NSA's effect on commercial 
  439. cryptography.
  440.  
  441. The NSA exerts influence over commercial cryptography in several ways. 
  442. First, it controls the export of cryptography from the U.S. (see Question 
  443. 1.6); the NSA generally does not approve export of products used for 
  444. encryption unless the key size is strictly limited. It does, however,
  445. approve for export any products used for authentication only, no matter 
  446. how large the key size, so long as the product cannot be converted to be
  447. used for encryption. The NSA has also blocked encryption methods from being 
  448. published or patented, citing a national security threat; see Landau [46] 
  449. for a discussion of this practice. Additionally, the NSA serves an 
  450. ``advisory'' role to NIST in the evaluation and selection of official U.S. 
  451. government computer security standards; in this capacity, it has played a 
  452. prominent, and controversial, role in the selection of DES and in the 
  453. development of the group of standards known as the Capstone project (see 
  454. Section 6), which includes DSS and the Clipper chip. The NSA can also 
  455. exert market pressure on U.S. companies to produce (or refrain from 
  456. producing) cryptographic goods, since the NSA itself is often a large 
  457. customer of these companies.
  458.  
  459. Cryptography is in the public eye as never before and has become the subject
  460. of national public debate. The status of cryptography, and the NSA's role
  461. in it, will probably change over the next few years.
  462.  
  463.  
  464. 8 Miscellaneous
  465.  
  466. 8.1 What is the legal status of documents signed with digital signatures?
  467.  
  468. If digital signatures are to replace handwritten signatures they must have 
  469. the same legal status as handwritten signatures, i.e., documents signed 
  470. with digital signatures must be legally binding. NIST has stated that its 
  471. proposed Digital Signature Standard (see Question 6.8) should be capable 
  472. of ``proving to a third party that data was actually signed by the 
  473. generator of the signature.'' Furthermore, U.S. federal government
  474. purchase orders will be signed by any such standard; this implies that
  475. the government will support the legal authority of digital signatures
  476. in the courts. Some preliminary legal research has also resulted in the
  477. opinion that digital signatures would meet the requirements of legally
  478. binding signatures for most purposes, including commercial use as defined 
  479. in the Uniform Commercial Code (UCC). A GAO (Government Accounting
  480. Office) decision requested by NIST also opines that digital signatures
  481. will meet the legal standards of handwritten signatures [20].
  482.  
  483. However, since the validity of documents with digital signatures has never 
  484. been challenged in court, their legal status is not yet well-defined.
  485. Through such challenges, the courts will issue rulings that collectively 
  486. define which digital signature methods, key sizes, and security precautions 
  487. are acceptable for a digital signature to be legally binding.
  488.  
  489. Digital signatures have the potential to possess greater legal authority
  490. than handwritten signatures. If a ten-page contract is signed by hand on
  491. the tenth page, one cannot be sure that the first nine pages have not
  492. been altered. If the contract was signed by digital signatures, however, 
  493. a third party can verify that not one byte of the contract has been altered.
  494.  
  495. Currently, if two people wish to digitally sign a series of contracts, 
  496. they may wish to first sign a paper contract in which they agree to be bound 
  497. in the future by any contracts digitally signed by them with a given 
  498. signature method and minimum key size.
  499.  
  500.  
  501. 8.2 What is a hash function? What is a message digest?
  502.  
  503. A hash function is a computation that takes a variable-size input and returns
  504. a fixed-size string, which is called the hash value. If the hash function
  505. is one-way, i.e., hard to invert, it is also called a message-digest function,
  506. and the result is called a message digest. The idea is that a digest 
  507. represents concisely the longer message or document from which it was 
  508. computed; one can think of a message digest as a ``digital fingerprint'' of 
  509. the larger document. Examples of well-known hash functions are MD4, MD5, 
  510. and SHS (see Questions 8.3 and 8.4).
  511.  
  512. Although hash functions in general have many uses in computer programs, in 
  513. cryptography they are used to generate a small string (the message digest) 
  514. that can represent securely a much larger string, such as a file or message. 
  515. Since the hash functions are faster than the signing functions, it is much 
  516. more efficient to compute a digital signature using a document's message 
  517. digest, which is small, than using the arbitrarily large document itself. 
  518. Additionally, a digest can be made public without revealing the contents of 
  519. the document from which it derives. This is important in digital 
  520. time-stamping, where, using hash functions, one can get a document 
  521. time-stamped without revealing its contents to the time-stamping service 
  522. (see Question 3.18). 
  523.  
  524. A hash function used for digital authentication must have certain 
  525. properties that make it secure enough for cryptographic use. Specifically,  
  526. it must be infeasible to find a message that hashes to a given value
  527. and it must be infeasible to find two distinct messages that hash to 
  528. the same value. The ability to find a message hashing to a given value
  529. would enable an attacker to substitute a fake message for a real message
  530. that was signed. It would also enable someone to falsely disown a 
  531. message by claiming that he or she actually signed a different message 
  532. hashing to the same value, thus violating the non-repudiation property
  533. of digital signatures. The ability to find two distinct messages hashing 
  534. to the same value could enable an attack whereby someone is tricked into 
  535. signing a message which hashes to the same value as another message with 
  536. a quite different meaning. The digest must therefore be long enough to 
  537. prevent an attacker from doing an exhaustive search for a collision. For 
  538. example, if a hash function produces 100-bit strings, exhaustive search 
  539. would take 2^{100} attempts on average to match a given value, and 
  540. approximately 2^{50} attempts on average to find two inputs producing 
  541. the same digest. 
  542.  
  543. A digital signature system can be broken by attacking either the difficult
  544. mathematical problem on which the signature method is based or the hash 
  545. function used to create the message digests. When choosing an authentication 
  546. system, it is generally a good idea to choose a signature method and a hash 
  547. function that require comparable efforts to break; any extra security in one 
  548. of the two components is wasted, since attacks will be directed at the weaker 
  549. component. Actually, attacking the hash function is harder in practice, since 
  550. it requires a large amount of memory and the ability to trick the victim into 
  551. signing a special message. With 2^{64} operations, an attacker can find two 
  552. messages that hash to the same digest under any of the MD hash functions; 
  553. this effort is comparable to that necessary to break 512-bit RSA; thus MD5 is 
  554. a good choice when using RSA with a 512-bit modulus. However, those with 
  555. greater security needs, such as certifying authorities, should use a longer 
  556. modulus and a hash function that produces a longer message digest; either SHS 
  557. (160-bit digest) or a modified version of MD4 that produces a 256-bit digest 
  558. [71] would suffice.
  559.  
  560.  
  561. 8.3 What are MD2, MD4 and MD5?
  562.  
  563. MD2, MD4 and MD5 (MD stands for Message Digest) are widely used hash 
  564. functions designed by Ron Rivest specifically for cryptographic use.
  565. They produce 128-bit digests and there is no known attack faster than 
  566. exhaustive search.
  567.  
  568. MD2 is the slowest of the three; MD4 [71] is the fastest. MD5 [73]
  569. has been dubbed ``MD4 with safety belts'' by Rivest, since it has a 
  570. more conservative design than MD4; the design gives it increased 
  571. security against attack, but at a cost of being approximately 33% 
  572. slower than MD4. MD5 is the most commonly used of the three algorithms. 
  573. MD4 and MD5 are publicly available for unrestricted use; MD2 is available
  574. for use with PEM (see Question 8.7). Details of MD2, MD4, and MD5 with 
  575. sample C code are available in Internet RFCs (Requests For Comments) 
  576. 1319, 1320, and 1321, respectively. 
  577.  
  578. No feasible attacks on any of the MD algorithms have been discovered, 
  579. although some recent theoretical work has found some interesting
  580. structural properties [24,25].
  581.  
  582.  
  583. 8.4 What is SHS?
  584.  
  585. The Secure Hash Standard (SHS) [58] is a hash function proposed by NIST 
  586. (see Question 7.1) and adopted as a U.S. government standard. It is 
  587. designed for use with the proposed Digital Signature Standard (see 
  588. Question 6.8) and is part of the government's Capstone project (see 
  589. Question 6.1}). SHS produces a 160-bit hash value from a variable-size 
  590. input. SHS is structurally similar to MD4 and MD5. It is roughly 25% 
  591. slower than MD5 but may be more secure, because it produces message 
  592. digests that are 25% longer than those produced by the MD functions. 
  593. SHS is currently the only part of Capstone that has been officially 
  594. adopted as a government standard.
  595.  
  596.  
  597. 8.5 What is Kerberos?
  598.  
  599. Kerberos is a secret-key network authentication system developed at MIT
  600. [79]; it uses DES for encryption and authentication. Unlike a public-key 
  601. authentication system, it does not produce digital signatures: Kerberos 
  602. was designed to authenticate requests for network resources rather than 
  603. to authenticate authorship of documents. Kerberos provides real-time 
  604. authentication in a distributed environment, but does not provide for 
  605. future third-party verification of documents.
  606.  
  607. In a Kerberos system, there is a designated site on the network, called 
  608. the Kerberos server, which performs centralized key management and 
  609. administrative functions. The server maintains a database containing the 
  610. secret keys of all users, generates session keys whenever two users wish to 
  611. communicate securely, and authenticates the identity of a user who requests 
  612. certain network services. 
  613.  
  614. Kerberos, like other secret-key systems, requires trust in a third party, 
  615. in this case the Kerberos server. If the server were compromised, the 
  616. integrity of the whole system would fall. Public-key cryptography was 
  617. designed precisely to avoid the necessity to trust third parties or 
  618. communication lines (see Question 1.4). Kerberos may be adequate 
  619. for those who do not need the more robust functions and properties of 
  620. public-key systems. 
  621.  
  622.  
  623. 8.6 What are RC2 and RC4?
  624.  
  625. RC2 and RC4 are variable-key-size cipher functions designed by Ron Rivest 
  626. for fast bulk encryption. They are alternatives to DES (see Question
  627. 5.1) and are as fast or faster than DES. They can be more secure than 
  628. DES because of their ability to use long key sizes; they can also be less 
  629. secure than DES if short key sizes are used.
  630.  
  631. RC2 is a variable-key-size symmetric block cipher and can serve as a drop-in
  632. replacement for DES, for example in export versions of products otherwise
  633. using DES. RC2 can be used in the same modes as DES (see Question 5.3), 
  634. including triple encryption. RC2 is approximately twice as fast as DES, 
  635. at least in software. RC4 is a variable-key-size symmetric stream cipher 
  636. and is 10 or more times as fast as DES in software. Both RC2 and RC4 are 
  637. very compact in terms of code size. 
  638.  
  639. An agreement between the Software Publishers Association (SPA) and the U.S. 
  640. government gives RC2 and RC4 special status by means of which the export 
  641. approval process is simpler and quicker than the usual cryptographic export 
  642. process. However, to qualify for quick export approval a product must limit 
  643. the RC2 and RC4 key sizes to 40 bits; 56 bits is allowed for foreign 
  644. subsidiaries and overseas offices of U.S. companies. An additional 40-bit 
  645. string, called a salt, can be used to thwart attackers who try to 
  646. precompute a large look-up table of possible encryptions. The salt is 
  647. appended to the encryption key, and this lengthened key is used to encrypt 
  648. the message; the salt is then sent, unencrypted, with the message. RC2 and 
  649. RC4 have been widely used by developers who want to export their products; 
  650. DES is almost never approved for export. RC2 and RC4 are proprietary 
  651. algorithms of RSA Data Security, Inc.; details have not been published.
  652.  
  653.  
  654. 8.7 What is PEM?
  655.  
  656. PEM is the Internet Privacy-Enhanced Mail standard, designed, proposed, but 
  657. not yet officially adopted, by the Internet Activities Board in order to 
  658. provide secure electronic mail over the Internet. Designed to work with 
  659. current Internet e-mail formats, PEM includes encryption, authentication, 
  660. and key management, and allows use of both public-key and secret-key 
  661. cryptosystems. Multiple cryptographic tools are supported: for each mail 
  662. message, the specific encryption algorithm, digital signature algorithm, 
  663. hash function, and so on are specified in the header. PEM explicitly 
  664. supports only a few cryptographic algorithms; others may be added later. 
  665. DES in CBC mode is currently the only message encryption algorithm supported, 
  666. and both RSA and DES are supported for the key management. PEM also supports 
  667. the use of certificates, endorsing the CCITT X.509 standard for certificate 
  668. structure. 
  669.  
  670. The details of PEM can be found in Internet RFCs (Requests For Comments) 
  671. 1421 through 1424. PEM is likely to be officially adopted by the Internet 
  672. Activities Board within one year. Trusted Information Systems has developed
  673. a free non-commercial implementation of PEM, and other implementations should 
  674. soon be available as well.
  675.  
  676.  
  677. 8.8 What is RIPEM?
  678.  
  679. RIPEM is a program developed by Mark Riordan that enables secure Internet 
  680. e-mail; it provides both encryption and digital signatures, using RSA and 
  681. DES routines from RSAREF (see Question 8.10). RIPEM is not fully 
  682. PEM-compatible; for example, it does not currently support certificates. 
  683. However, future versions will include certificates and will be fully 
  684. compliant with the PEM standard. RIPEM is available free for non-commercial 
  685. use in the U.S. and Canada. To get RIPEM, obtain an ftp account at 
  686. ripem.msu.edu.
  687.  
  688.  
  689. 8.9 What is PKCS?
  690.  
  691. PKCS (Public-Key Cryptography Standards) is a set of standards for 
  692. implementation of public-key cryptography. It has been issued by RSA 
  693. Data Security, Inc. in cooperation with a computer industry consortium, 
  694. including Apple, Microsoft, DEC, Lotus, Sun and MIT. PKCS has been cited 
  695. by the OIW (OSI Implementors' Workshop) as a method for implementation of 
  696. OSI standards. PKCS is compatible with PEM (see Question 8.7) but extends 
  697. beyond PEM. For example, where PEM can only handle ASCII data, PKCS is 
  698. designed for binary data as well. PKCS is also compatible with the CCITT 
  699. X.509 standard.
  700.  
  701. PKCS includes both algorithm-specific and algorithm-independent 
  702. implementation standards. Specific algorithms supported include RSA, DES, 
  703. and Diffie-Hellman key exchange. It also defines algorithm-independent syntax 
  704. for digital signatures, digital envelopes (for encryption), and certificates; 
  705. this enables someone implementing any cryptographic algorithm whatsoever to 
  706. conform to a standard syntax and thus preserve interoperability. Documents 
  707. detailing the PKCS standards can be obtained by sending e-mail to 
  708. pkcs@rsa.com or by anonymous ftp to rsa.com.
  709.  
  710.  
  711. 8.10 What is RSAREF?
  712.  
  713. RSAREF is a collection of cryptographic routines in portable C source code,
  714. available at no charge from RSA Laboratories, a division of RSA Data Security,
  715. Inc. It includes RSA, MD2, MD5, and DES; Diffie-Hellman key exchange will 
  716. be included in a forthcoming version. It includes both low-level 
  717. subroutines, such as modular exponentiation, and high-level cryptographic 
  718. functions, such as verification of digital signatures. The arithmetic routines 
  719. can handle multiple-precision integers, and the RSA algorithm routines can 
  720. handle variable key sizes. RSAREF is fully compatible with the PEM and PKCS
  721. standards.
  722.  
  723. RSAREF is available to citizens of the U.S. or Canada and to permanent 
  724. residents of the U.S. It can be used in personal, non-commercial applications 
  725. but cannot be used commercially or sent outside the U.S. and Canada. The 
  726. RSAREF license contains more details on the usage allowed and disallowed. 
  727. RSAREF is available on the Internet by sending e-mail to 
  728. rsaref@rsa.com or by ftp to rsa.com.
  729.  
  730.  
  731. 9 Acknowledgements
  732.  
  733. I would like to thank the following people, who have provided information 
  734. and helpful suggestions: Burt Kaliski, Jim Bidzos, Matt Robshaw, Steve Dusse, 
  735. Kurt Stammberger, George Parsons, John Gilmore, Stuart Haber, Dorothy 
  736. Denning, and Dennis Branstad. 
  737.  
  738.  
  739. BIBLIOGRAPHY
  740.  
  741. 1. American National Standards Institute. Working Draft: American National 
  742.    Standard X9.30-199X: Public Key Cryptography Using Irreversible 
  743.    Algorithms for the Financial Services Industry: Part 1: The Digital 
  744.    Signature Algorithm (DSA). American Bankers Association, Washington, 
  745.    D.C., March 4, 1993.
  746.  
  747. 2. J. Bamford. The Puzzle Palace. Houghton Mifflin, Boston, 1982.
  748.  
  749. 3. J.P. Barlow. Decrypting the puzzle palace. Communications of the ACM, 
  750.    35(7):25--31, July 1992.
  751.  
  752. 4. D. Bayer, S. Haber, and W.S. Stornetta. Improving the efficiency and 
  753.    reliablility of digital time-stamping. In R.M. Capocelli, editor, 
  754.    Sequences '91: Methods in Communication, Security, and Computer Science, 
  755.    Springer-Verlag, Berlin, 1992.
  756.  
  757. 5. P. Beauchemin, G. Brassard, C. Crepeau, C. Goutier, and C. Pomerance. The 
  758.    generation of random numbers that are probably prime. J. of Cryptology, 
  759.    1:53--64, 1988.
  760.  
  761. 6. E. Biham and A. Shamir. Differential Cryptanalysis of the Data Encryption 
  762.    Standard. Springer-Verlag, New York, 1993.
  763.  
  764. 7. E. Biham and A. Shamir. Differential cryptanalysis of the full 16-round 
  765.    DES. In Advances in Cryptology --- Crypto '92, Springer-Verlag, New York, 
  766.    1993.
  767.  
  768. 8. M. Blum and S. Goldwasser. An efficient probabilistic public-key 
  769.    encryption scheme which hides all partial information. In Advances in 
  770.    Cryptology --- Crypto '84, pages 289--299, Springer-Verlag, New York, 
  771.    1985.
  772.  
  773. 9. J. Brandt and I. Damgard. On generation of probable primes by incremental 
  774.    search. In Advances in Cryptology --- Crypto '92, Springer-Verlag, New 
  775.    York, 1993.
  776.  
  777. 10. G. Brassard. Modern Cryptology. Volume 325 of Lecture Notes in Computer 
  778.     Science, Springer-Verlag, Berlin, 1988.
  779.  
  780. 11. D.M. Bressoud. Factorization and Primality Testing. Undergraduate Texts 
  781.     in Mathematics, Springer-Verlag, New York, 1989.
  782.  
  783. 12. E.F. Brickell, D.E. Denning, S.T. Kent, D.P. Maher, and W. Tuchman. 
  784.     Skipjack Review, Interim Report: The Skipjack Algorithm. July 28, 1993.
  785.  
  786. 13. E.F. Brickell and A.M. Odlyzko. Cryptanalysis: A survey of recent 
  787.     results. Proceedings of the IEEE, 76:578--593, 1988.
  788.  
  789. 14. J. Brillhart, D.H. Lehmer, J.L. Selfridge, B. Tuckerman, and S.S. 
  790.     Wagstaff Jr. Factorizations of b^n +/- 1, b=2,3,5,6,7,10,11,12 up to 
  791.     High Powers. Volume 22 of Contemporary Mathematics, American 
  792.     Mathematical Society, Providence, Rhode Island, 2nd edition, 1988.
  793.  
  794. 15. J. Buchmann, J. Loho, and J. Zayer. An implementation of the general 
  795.     number field sieve. In Advances, in Cryptology --- Crypto '93, 
  796.     Springer-Verlag, New York, 1994. To appear.
  797.  
  798. 16. J.P. Buhler, H.W. Lenstra, and C. Pomerance. Factoring integers with 
  799.     the number field sieve. 1992. To appear.
  800.  
  801. 17. M.V.D. Burmester, Y.G. Desmedt, and T. Beth. Efficient zero-knowledge 
  802.     identification schemes for smart cards. Computer Journal, 35:21--29, 1992.
  803.  
  804. 18. K.W. Campbell and M.J. Wiener. Proof that DES is not a group. In 
  805.     Advances in Cryptology --- Crypto '92, Springer-Verlag, New York, 1993.
  806.  
  807. 19. CCITT (Consultative Committee on International Telegraphy and 
  808.     Telephony). Recommendation X.509: The Directory---Authentication 
  809.     Framework. 1988.
  810.  
  811. 20. Comptroller General of the United States. Matter of National Institute 
  812.     of Standards and Technology --- Use of Electronic Data Interchange 
  813.     Technology to Create Valid Obligations. December 13, 1991. File B-245714. 
  814.  
  815. 21. D. Coppersmith, A.M. Odlyzko, and R. Schroeppel. Discrete logarithms in 
  816.     GF(p). Algorithmica, 1:1--15, 1986.
  817.  
  818. 22. T.H. Cormen, C.E. Leiserson, and R.L. Rivest. Introduction to Algorithms.
  819.     MIT Press, Cambridge, Massachusetts, 1990.
  820.  
  821. 23. G. Davida. Chosen signature cryptanalysis of the RSA public key
  822.     cryptosystem. Technical Report TR-CS-82-2, Dept of EECS, University of 
  823.     Wisconsin, Milwaukee, 1982.
  824.  
  825. 24. B. den Boer and A. Bosselaers. An attack on the last two rounds of MD4.
  826.     In Advances in Cryptology --- Crypto '91, pages 194--203, Springer-Verlag,
  827.     New York, 1992.
  828.  
  829. 25. B. den Boer and A. Bosselaers. Collisions for the compression function 
  830.     of MD5. In Advances in Cryptology --- Eurocrypt '93, 1993. Preprint.
  831.  
  832. 26. Dorothy E. Denning. The Clipper encryption system. American Scientist, 
  833.     81(4):319--323, July--August 1993.
  834.  
  835. 27. W. Diffie. The first ten years of public-key cryptography. Proceedings 
  836.     of the IEEE, 76:560--577, 1988.
  837.  
  838. 28. W. Diffie and M.E. Hellman. Exhaustive cryptanalysis of the NBS Data 
  839.     Encryption Standard. Computer, 10:74--84, 1977.
  840.  
  841. 29. W. Diffie and M.E. Hellman. New directions in cryptography. IEEE 
  842.     Transactions on Information Theory, IT-22:644--654, 1976.
  843.  
  844. 30. T. ElGamal. A public-key cryptosystem and a signature scheme based on 
  845.     discrete logarithms. IEEE Transactions on Information Theory, 
  846.     IT-31:469--472, 1985.
  847.  
  848. 31. A. Fiat and A. Shamir. How to prove yourself: Practical solutions to 
  849.     identification and signature problems. In Advances in Cryptology --- 
  850.     Crypto '86, pages 186--194, Springer-Verlag, New York, 1987.
  851.  
  852. 32. S. Goldwasser and S. Micali. Probabilistic encryption. J. of Computer 
  853.     and System Sciences, 28:270--299, 1984.
  854.  
  855. 33. D.M. Gordon. Discrete logarithms using the number field sieve. March 28,
  856.     1991. To appear. 
  857.  
  858. 34. D.M. Gordon and K.S. McCurley. Massively parallel computation of discrete
  859.     logarithms. In Advances in Cryptology --- Crypto '92, Springer-Verlag, 
  860.     New York, 1993.
  861.  
  862. 35. J. Hastad. Solving simultaneous modular equations of low degree. SIAM J.
  863.     Computing, 17:336--241, 1988.
  864.  
  865. 36. M.E. Hellman. A cryptanalytic time-memory trade off. IEEE Transactions 
  866.     on Information Theory, IT-26:401--406, 1980.
  867.  
  868. 37. D. Kahn. The Codebreakers. Macmillan Co., New York, 1967.
  869.  
  870. 38. B.S. Kaliski. A survey of encryption standards. RSA Data Security, Inc.,
  871.     September 2, 1993.
  872.  
  873. 39. B.S. Kaliski Jr., R.L. Rivest, and A.T. Sherman. Is the data encryption 
  874.     standard a group? J. of Cryptology, 1:3--36, 1988.
  875.  
  876. 40. S. Kent. RFC 1422: Privacy Enhancement for Internet Electronic Mail, 
  877.     Part II: Certificate-Based Key Management. Internet Activities Board, 
  878.     February 1993.
  879.  
  880. 41. D.E. Knuth. The Art of Computer Programming. Volume 2, Addison-Wesley, 
  881.     Reading, Mass., 2nd edition, 1981. 
  882.  
  883. 42. N. Koblitz. A Course in Number Theory and Cryptography. Springer-Verlag, 
  884.     New York, 1987.
  885.  
  886. 43. N. Koblitz. Elliptic curve cryptosystems. Mathematics of Computation, 
  887.     48:203--209, 1987.
  888.  
  889. 44. X. Lai and J.L. Massey. A proposal for a new block encryption standard. 
  890.     In Advances in Cryptology --- Eurocrypt '90, pages 389--404, 
  891.     Springer-Verlag, Berlin, 1991. 
  892.  
  893. 45. B.A. LaMacchia and A.M. Odlyzko. Computation of discrete logarithms 
  894.     in prime fields. Designs, Codes and Cryptography, 1:47--62, 1991. 
  895.  
  896. 46. S. Landau. Zero knowledge and the Department of Defense. Notices of 
  897.     the American Mathematical Society, 35:5--12, 1988.
  898.  
  899. 47. A.K. Lenstra and H.W. Lenstra Jr. Algorithms in number theory. In J. 
  900.     van Leeuwen, editor, Handbook of Theoretical Computer Science, MIT 
  901.     Press/Elsevier, Amsterdam, 1990.
  902.  
  903. 48. A.K. Lenstra, H.W. Lenstra Jr., M.S. Manasse, and J.M. Pollard. The 
  904.     factorization of the ninth Fermat number. 1991. To appear. 
  905.  
  906. 49. A.K. Lenstra and M.S. Manasse. Factoring with two large primes. In 
  907.     Advances in Cryptology --- Eurocrypt '90, pages 72--82, Springer-Verlag, 
  908.     Berlin, 1991. 
  909.  
  910. 50. H.W. Lenstra Jr. Factoring integers with elliptic curves. Ann. of Math., 
  911.     126:649--673, 1987.
  912.  
  913. 51. M. Matsui. Linear cryptanalysis method for DES cipher. In Advances in 
  914.     Cryptology --- Eurocrypt '93, Springer-Verlag, Berlin, 1993. To appear.
  915.  
  916. 52. R.C. Merkle and M.E. Hellman. Hiding information and signatures in 
  917.     trapdoor knapsacks. IEEE Transactions on Information Theory, 
  918.     IT-24:525--530, 1978.
  919.  
  920. 53. R.C. Merkle and M.E. Hellman. On the security of multiple encryption. 
  921.     Communications of the ACM, 24:465--467, July 1981. 
  922.  
  923. 54. E. Messmer. NIST stumbles on proposal for public-key encryption. Network 
  924.     World, 9(30), July 27, 1992.
  925.  
  926. 55. S. Micali. Fair public-key cryptosystems. In Advances in Cryptology --- 
  927.     Crypto '92, Springer-Verlag, New York, 1993.
  928.  
  929. 56. V.S. Miller. Use of elliptic curves in cryptography. In Advances in 
  930.     Cryptology --- Crypto '85, pages 417--426, Springer-Verlag, New York, 
  931.     1986.
  932.  
  933. 57. National Institute of Standards and Technology (NIST). The Digital 
  934.     Signature Standard, proposal and discussion. Communications of the ACM, 
  935.     35(7):36--54, July 1992.
  936.  
  937. 58. National Institute of Standards and Technology (NIST). FIPS Publication 
  938.     180: Secure Hash Standard (SHS). May 11, 1993.
  939.  
  940. 59. National Institute of Standards and Technology (NIST). FIPS Publication 
  941.     46-1: Data Encryption Standard. January 22, 1988. Originally issued by 
  942.     National Bureau of Standards.
  943.  
  944. 60. National Institute of Standards and Technology (NIST). FIPS Publication 
  945.     81: DES Modes of Operation. December 2, 1980. Originally issued by 
  946.     National Bureau of Standards.
  947.  
  948. 61. National Institute of Standards and Technology (NIST). Notice of 
  949.     proposal for grant of exclusive patent license. Federal Register, 
  950.     58(108), June 8, 1993.
  951.  
  952. 62. National Institute of Standards and Technology (NIST). A proposed 
  953.     Federal Information Processing Standard for an Escrowed Encryption 
  954.     Standard (EES). Federal Register, 58(145), July 30, 1993.
  955.  
  956. 63. National Institute of Standards and Technology (NIST). Publication XX: 
  957.     Announcement and Specifications for a Digital Signature Standard (DSS).
  958.     August 19, 1992.
  959.  
  960. 64. A.M. Odlyzko. Discrete logarithms in finite fields and their cryptographic
  961.     significance. In Advances in Cryptology --- Eurocrypt '84, pages 224--314,
  962.     Springer-Verlag, Berlin, 1984.
  963.  
  964. 65. Office of the Press Secretary. Statement. The White House, April 16, 1993.
  965.  
  966. 66. J. Pollard. Monte Carlo method for factorization. BIT, 15:331--334, 1975.
  967.  
  968. 67. J. Pollard. Theorems of factorization and primality testing. Proc. 
  969.     Cambridge Philos. Soc., 76:521--528, 1974.
  970.  
  971. 68. M.O. Rabin. Digitalized signatures as intractable as factorization. 
  972.     Technical Report MIT/LCS/TR-212, MIT, 1979.
  973.  
  974. 69. R.L. Rivest. Cryptography. In J. van Leeuwen, editor, Handbook of 
  975.     Theoretical Computer Science, MIT Press/Elsevier, Amsterdam, 1990.
  976.  
  977. 70. R.L. Rivest. Finding four million random primes. In Advances in 
  978.     Cryptology --- Crypto '90, pages 625--626, Springer-Verlag, New York, 
  979.     1991. 
  980.  
  981. 71. R.L Rivest. The MD4 message digest algorithm. In Advances in Cryptology 
  982.     --- Crypto '90, pages 303--311, Springer-Verlag, New York, 1991. 
  983.  
  984. 72. R.L. Rivest. Response to NIST's proposal. Communications of the ACM,
  985.     35:41--47, July 1992.
  986.  
  987. 73. R.L. Rivest. RFC 1321: The MD5 Message-Digest Algorithm. Internet
  988.     Activities Board, April 1992.
  989.  
  990. 74. R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital
  991.     signatures and public-key cryptosystems. Communications of the ACM, 
  992.     21(2):120--126, February 1978.
  993.  
  994. 75. C.P. Schnorr. Efficient identification and signatures for smart cards.
  995.     In Advances in Cryptology --- Crypto '89, pages 239--251, 
  996.     Springer-Verlag, New York, 1990.
  997.  
  998. 76. M. Shand and J. Vuillemin. Fast implementations of RSA cryptography. In
  999.     Proceedings of the 11th IEEE Symposium on Computer Arithmetic, pages 
  1000.     252--259, IEEE Computer Society Press, Los Alamitos, CA, 1993.
  1001.  
  1002. 77. R.D. Silverman. The multiple polynomial quadratic sieve. Math. Comp., 
  1003.     48:329--339, 1987.
  1004.  
  1005. 78. M.E. Smid and D.K. Branstad. Response to comments on the NIST proposed
  1006.     Digital Signature Standard. In Advances in Cryptology --- Crypto '92,
  1007.     Springer-Verlag, New York, 1993.
  1008.  
  1009. 79. J.G. Steiner, B.C. Neuman, and J.I. Schiller. Kerberos: an authentication
  1010.     service for open network systems. In Usenix Conference Proceedings, pages
  1011.     191--202, Dallas, Texas, February 1988.
  1012.  
  1013. 80. M.J. Wiener. Efficient DES key search. August 20, 1993. Presented at 
  1014.     Crypto '93 rump session.
  1015.  
  1016.  
  1017.        --------------------------------------------
  1018.  
  1019. RSA Laboratories is the research and consultation division of RSA Data
  1020. Security, Inc., the company founded by the inventors of the RSA
  1021. public-key cryptosystem. RSA Laboratories reviews, designs and
  1022. implements secure and efficient cryptosystems of all kinds. Its
  1023. clients include government agencies, telecommunications companies,
  1024. computer manufacturers, software developers, cable TV broadcasters,
  1025. interactive video manufacturers, and satellite broadcast companies,
  1026. among others.
  1027.  
  1028. For more information about RSA Laboratories, call or write to 
  1029.                         RSA Laboratories
  1030.                         100 Marine Parkway
  1031.                         Redwood City, CA 94065
  1032.                         (415) 595-7703
  1033.                         (415) 595-4126 (fax)
  1034.  
  1035.  
  1036.  
  1037. PKCS, RSAREF and RSA Laboratories are trademarks of RSA Data
  1038. Security, Inc. All other trademarks belong to their respective 
  1039. companies.
  1040.  
  1041. This document is available in ASCII, Postscript, and Latex formats
  1042. via anonymous FTP to rsa.com:/pub/faq.
  1043.  
  1044. Please send comments and corrections to faq-editor@rsa.com.
  1045.  
  1046.  
  1047.  
  1048. ===
  1049. DISTRIBUTION: How to obtain this document
  1050.  
  1051. This document has been brought to you in part by CRAM, involved in the
  1052. redistribution of valuable information to a wider USENET audience (see
  1053. below). The most recent version of this document can be obtained via
  1054. the author's instructions above. The following directions apply to 
  1055. retrieve the possibly less-current USENET FAQ version.
  1056.  
  1057.   FTP
  1058.   ---
  1059.     This FAQ is available from the standard FAQ server rtfm.mit.edu via
  1060.     FTP in the directory /pub/usenet/news.answers/cryptography-faq/rsa/
  1061.  
  1062.   Email
  1063.   -----
  1064.     Email requests for FAQs go to mail-server@rtfm.mit.edu with commands
  1065.     on lines in the message body, e.g. `help' and `index'.
  1066.  
  1067.   Usenet
  1068.   ------
  1069.     This FAQ is posted every 21 days to the groups
  1070.  
  1071.       sci.crypt
  1072.       talk.politics.crypto
  1073.       alt.security.ripem
  1074.       sci.answers
  1075.       talk.answers
  1076.       alt.answers
  1077.       news.answers
  1078.  
  1079. _ _, _ ___ _, __,  _, _  _, ___ _  _, _, _ _  _, __,  _, _  _ ___ __,
  1080. | |\ | |_ / \ |_)  |\/| / \  |  | / \ |\ | | (_  |_) / \ |  | |_  | )
  1081. | | \| |  \ / | \  |  | |~|  |  | \ / | \| | , ) |   \ / |/\| |   |~\
  1082. ~ ~  ~ ~   ~  ~  ~ ~  ~ ~ ~  ~  ~  ~  ~  ~ ~  ~  ~    ~  ~  ~ ~~~ ~  ~
  1083.  
  1084. ===
  1085. CRAM: The Cyberspatial Reality Advancement Movement
  1086.  
  1087. In an effort to bring valuable information to the masses, and as a
  1088. service to motivated information compilers, a member of CRAM can help
  1089. others unfamiliar with Usenet `publish' their documents for
  1090. widespread dissemination via the FAQ structure, and act as a
  1091. `sponsor' knowledgable in the submissions process. This document is
  1092. being distributed under this arrangement.
  1093.  
  1094. We have found these compilations tend to appear on various mailing
  1095. lists and are valuable enough to deserve wider distribution. If you
  1096. know of an existing compilation of Internet information that is not
  1097. currently a FAQ, please contact us and we may `sponsor' it. The
  1098. benefits to the author include:
  1099.  
  1100. - use of the existing FAQ infrastructure for distribution:
  1101.   - automated mail server service
  1102.   - FTP archival
  1103.   - automated posting
  1104.  
  1105. - a far wider audience that can improve the quality, accuracy, and 
  1106.   coverage of the document enormously through email feedback
  1107.  
  1108. - potential professional inquiries for the use of your document in 
  1109.   other settings, such as newsletters, books, etc.
  1110.  
  1111. - with us as your sponsor, we will also take care of the 
  1112.   technicalities in the proper format of the posted version and 
  1113.   updating procedures, leaving you free of the `overhead' to focus on 
  1114.   the basic updates alone
  1115.  
  1116. The choice of who we `sponsor' is entirely arbitrary. You always have
  1117. the option of handling the submission process yourself.  See the FAQ
  1118. submission guidelines FAQ in news.answers. 
  1119.  
  1120. For information, send mail to <tmp@netcom.com>.
  1121.  
  1122.  \   \   \   \   \   \   \   \   \   |   /   /   /   /   /   /   /   /   /   /
  1123.           _______       ________          _____        _____  _____
  1124.          ///   \\\      |||   \\\        /// \\\       |||\\\///|||
  1125.         |||     ~~      |||   ///       |||   |||      ||| \\// |||
  1126.         |||     __      |||~~~\\\       |||~~~|||      |||  ~~  |||
  1127.          \\\   ///      |||    \\\      |||   |||      |||      |||
  1128.           ~~~~~~~       ~~~     ~~~     ~~~   ~~~      ~~~      ~~~
  1129.  /   /   /   /   /   /   /   /   /   |   \   \   \   \   \   \   \   \   \   \
  1130.  
  1131. C y b e r s p a t i a l  R e a l i t y  A d v a n c e m e n t  M o v e m e n t
  1132.  
  1133. * CIVILIZING CYBERSPACE: send `info cypherwonks' to majordomo@lists.eunet.fi *
  1134.  
  1135.  
  1136.