home *** CD-ROM | disk | FTP | other *** search
/ OS/2 Shareware BBS: Security / Security.zip / criptfaq.zip / CRIPTO.FAQ
Internet Message Format  |  1994-08-28  |  130KB

  1. From ankh.iia.org!uunet!MathWorks.Com!news2.near.net!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:14 1994
  2. Path: ankh.iia.org!uunet!MathWorks.Com!news2.near.net!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  3. From: crypt-comments@math.ncsu.edu
  4. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  5. Subject: Cryptography FAQ (01/10: Overview)
  6. Supersedes: <cryptography-faq/part01_775545033@rtfm.mit.edu>
  7. Followup-To: poster
  8. Date: 20 Aug 1994 16:36:19 GMT
  9. Organization: The Crypt Cabal
  10. Lines: 152
  11. Approved: news-answers-request@MIT.Edu
  12. Expires: 24 Sep 1994 16:36:22 GMT
  13. Message-ID: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  14. Reply-To: crypt-comments@math.ncsu.edu
  15. NNTP-Posting-Host: bloom-picayune.mit.edu
  16. Summary: Part 1 of 10 of the sci.crypt FAQ, Overview. Table of 
  17.  contents, contributors, feedback, archives, administrivia, changes.
  18. X-Last-Updated: 1994/07/05
  19. Originator: faqserv@bloom-picayune.MIT.EDU
  20. Xref: ankh.iia.org sci.crypt:7645 talk.politics.crypto:4461 sci.answers:630 news.answers:9725 talk.answers:154
  21.  
  22. Archive-name: cryptography-faq/part01
  23. Version: 1.0
  24. Last-modified: 94/01/11
  25.  
  26.  
  27. This is the first of ten parts of the sci.crypt FAQ. The parts are
  28. mostly independent, but you should read this part before the rest. We
  29. don't have the time to send out missing parts by mail, so don't ask.
  30. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  31.  
  32. Disclaimer: This document is the product of the Crypt Cabal, a secret
  33. society which serves the National Secu---uh, no. Seriously, we're the
  34. good guys, and we've done what we can to ensure the completeness and
  35. accuracy of this document, but in a field of military and commercial
  36. importance like cryptography you have to expect that some people and
  37. organizations consider their interests more important than open
  38. scientific discussion. Trust only what you can verify firsthand.
  39. And don't sue us.
  40.  
  41. Many people have contributed to this FAQ. In alphabetical order:
  42. Eric Bach, Steve Bellovin, Dan Bernstein, Nelson Bolyard, Carl Ellison,
  43. Jim Gillogly, Mike Gleason, Doug Gwyn, Luke O'Connor, Tony Patti,
  44. William Setzer. We apologize for any omissions.
  45.  
  46. If you have suggestions, comments, or criticism, please let the current
  47. editors know by sending e-mail to crypt-comments@math.ncsu.edu. Bear in
  48. mind that this is a work in progress; there are some questions which we
  49. should add but haven't gotten around to yet. In making comments on
  50. additions it is most helpful if you are as specific as possible and 
  51. ideally even provide the actual exact text.
  52.  
  53. Archives: sci.crypt has been archived since October 1991 on
  54. ripem.msu.edu, though these archives are available only to U.S. and
  55. Canadian users. Another site is rpub.cl.msu.edu in /pub/crypt/sci.crypt/ 
  56. from Jan 1992. Please contact crypt-comments@math.ncsu.edu if you know of
  57. other archives.
  58.  
  59. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  60. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  61. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  62. sci.answers, and news.answers every 21 days.
  63.  
  64. The fields `Last-modified' and `Version' at the top of each part track
  65. revisions.
  66.  
  67.  
  68. Table of Contents
  69. -----------------
  70.  
  71. 1. Overview
  72.  
  73. 2. Net Etiquette
  74. 2.1. What groups are around? What's a FAQ? Who am I? Why am I here?
  75. 2.2. Do political discussions belong in sci.crypt?
  76. 2.3. How do I present a new encryption scheme in sci.crypt?
  77.  
  78. 3. Basic Cryptology
  79. 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key?
  80. 3.2. What references can I start with to learn cryptology?
  81. 3.3. How does one go about cryptanalysis?
  82. 3.4. What is a brute-force search and what is its cryptographic relevance?
  83. 3.5. What are some properties satisfied by every strong cryptosystem?
  84. 3.6. If a cryptosystem is theoretically unbreakable, then is it
  85.   guaranteed analysis-proof in practice?
  86. 3.7. Why are many people still using cryptosystems that are
  87.   relatively easy to break?
  88. 3.8. What are the basic types of cryptanalytic `attacks'?
  89.  
  90. 4. Mathematical Cryptology
  91. 4.1. In mathematical terms, what is a private-key cryptosystem?
  92. 4.2. What is an attack?
  93. 4.3. What's the advantage of formulating all this mathematically?
  94. 4.4. Why is the one-time pad secure?
  95. 4.5. What's a ciphertext-only attack?
  96. 4.6. What's a known-plaintext attack?
  97. 4.7. What's a chosen-plaintext attack?
  98. 4.8. In mathematical terms, what can you say about brute-force attacks?
  99. 4.9. What's a key-guessing attack? What's entropy?
  100.  
  101. 5. Product Ciphers
  102. 5.1. What is a product cipher?
  103. 5.2. What makes a product cipher secure?
  104. 5.3. What are some group-theoretic properties of product ciphers?
  105. 5.4. What can be proven about the security of a product cipher?
  106. 5.5. How are block ciphers used to encrypt data longer than the block size?
  107. 5.6. Can symmetric block ciphers be used for message authentication?
  108. 5.7. What exactly is DES?
  109. 5.8. What is triple DES?
  110. 5.9. What is differential cryptanalysis?
  111. 5.10. How was NSA involved in the design of DES?
  112. 5.11. Is DES available in software?
  113. 5.12. Is DES available in hardware?
  114. 5.13. Can DES be used to protect classified information?
  115. 5.14. What are ECB, CBC, CFB, and OFB encryption?
  116.  
  117. 6. Public-Key Cryptography
  118. 6.1. What is public-key cryptography?
  119. 6.2. How does public-key cryptography solve cryptography's Catch-22?
  120. 6.3. What is the role of the `trapdoor function' in public key schemes?
  121. 6.4. What is the role of the `session key' in public key schemes?
  122. 6.5. What's RSA?
  123. 6.6. Is RSA secure?
  124. 6.7. What's the difference between the RSA and Diffie-Hellman schemes?
  125. 6.8. What is `authentication' and the `key distribution problem'?
  126. 6.9. How fast can people factor numbers?
  127. 6.10. What about other public-key cryptosystems?
  128. 6.11. What is the `RSA Factoring Challenge?'
  129.  
  130. 7. Digital Signatures
  131. 7.1. What is a one-way hash function?
  132. 7.2. What is the difference between public, private, secret, shared, etc.?
  133. 7.3. What are MD4 and MD5?
  134. 7.4. What is Snefru?
  135.  
  136. 8. Technical Miscellany
  137. 8.1. How do I recover from lost passwords in WordPerfect?
  138. 8.2. How do I break a Vigenere (repeated-key) cipher?
  139. 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]
  140. 8.4. Is the UNIX crypt command secure?
  141. 8.5. How do I use compression with encryption?
  142. 8.6. Is there an unbreakable cipher?
  143. 8.7. What does ``random'' mean in cryptography?
  144. 8.8. What is the unicity point (a.k.a. unicity distance)?
  145. 8.9. What is key management and why is it important?
  146. 8.10. Can I use pseudo-random or chaotic numbers as a key stream?
  147. 8.11. What is the correct frequency list for English letters?
  148. 8.12. What is the Enigma?
  149. 8.13. How do I shuffle cards?
  150. 8.14. Can I foil S/W pirates by encrypting my CD-ROM?
  151. 8.15. Can you do automatic cryptanalysis of simple ciphers?
  152. 8.16. What is the coding system used by VCR+?
  153.  
  154. 9. Other Miscellany
  155. 9.1. What is the National Security Agency (NSA)?
  156. 9.2. What are the US export regulations?
  157. 9.3. What is TEMPEST?
  158. 9.4. What are the Beale Ciphers, and are they a hoax?
  159. 9.5. What is the American Cryptogram Association, and how do I get in touch?
  160. 9.6. Is RSA patented?
  161. 9.7. What about the Voynich manuscript?
  162.  
  163. 10. References
  164. 10.1. Books on history and classical methods
  165. 10.2. Books on modern methods
  166. 10.3. Survey articles
  167. 10.4. Reference articles
  168. 10.5. Journals, conference proceedings
  169. 10.6. Other
  170. 10.7. How may one obtain copies of FIPS and ANSI standards cited herein?
  171. 10.8. Electronic sources
  172. 10.9. RFCs (available from [FTPRF])
  173. 10.10. Related newsgroups
  174.  
  175. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  176. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  177. From: crypt-comments@math.ncsu.edu
  178. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  179. Subject: Cryptography FAQ (02/10: Net Etiquette)
  180. Supersedes: <cryptography-faq/part02_775545033@rtfm.mit.edu>
  181. Followup-To: poster
  182. Date: 20 Aug 1994 16:36:22 GMT
  183. Organization: The Crypt Cabal
  184. Lines: 91
  185. Approved: news-answers-request@MIT.Edu
  186. Expires: 24 Sep 1994 16:36:22 GMT
  187. Message-ID: <cryptography-faq/part02_777400582@rtfm.mit.edu>
  188. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  189. Reply-To: crypt-comments@math.ncsu.edu
  190. NNTP-Posting-Host: bloom-picayune.mit.edu
  191. X-Last-Updated: 1994/07/05
  192. Originator: faqserv@bloom-picayune.MIT.EDU
  193. Xref: ankh.iia.org sci.crypt:7646 talk.politics.crypto:4462 sci.answers:631 news.answers:9726 talk.answers:155
  194.  
  195. Archive-name: cryptography-faq/part02
  196. Last-modified: 94/06/13
  197.  
  198.  
  199. This is the second of ten parts of the sci.crypt FAQ. The parts are
  200. mostly independent, but you should read the first part before the rest.
  201. We don't have the time to send out missing parts by mail, so don't ask.
  202. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  203.  
  204. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  205. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  206. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  207. sci.answers, and news.answers every 21 days.
  208.  
  209.  
  210.  
  211. Contents:
  212.  
  213. 2.1. What groups are around? What's a FAQ? Who am I? Why am I here?
  214. 2.2. Do political discussions belong in sci.crypt?
  215. 2.3. How do I present a new encryption scheme in sci.crypt?
  216.  
  217.  
  218. 2.1. What groups are around? What's a FAQ? Who am I? Why am I here?
  219.  
  220.   Read news.announce.newusers and news.answers for a few weeks. Always
  221.   make sure to read a newsgroup for some time before you post to it.
  222.   You'll be amazed how often the same question can be asked in the same
  223.   newsgroup. After a month you'll have a much better sense of what the
  224.   readers want to see.
  225.  
  226. 2.2. Do political discussions belong in sci.crypt?
  227.  
  228.   No. In fact some newsgroups (notably misc.legal.computing) were
  229.   created exactly so that political questions like ``Should RSA be
  230.   patented?'' don't get in the way of technical discussions. Many
  231.   sci.crypt readers also read misc.legal.computing, comp.org.eff.talk,
  232.   comp.patents, sci.math, comp.compression, talk.politics.crypto,
  233.   et al.; for the benefit of people who don't care about those other
  234.   topics, try to put your postings in the right group.
  235.  
  236.   Questions about microfilm and smuggling and other non-cryptographic
  237.   ``spy stuff'' don't belong in sci.crypt either.
  238.  
  239. 2.3. How do I present a new encryption scheme in sci.crypt?
  240.  
  241.   ``I just came up with this neat method of encryption. Here's some
  242.   ciphertext: FHDSIJOYW^&%$*#@OGBUJHKFSYUIRE. Is it strong?'' Without a
  243.   doubt questions like this are the most annoying traffic on sci.crypt.
  244.  
  245.   If you have come up with an encryption scheme, providing some
  246.   ciphertext from it is not adequate. Nobody has ever been impressed by
  247.   random gibberish. Any new algorithm should be secure even if the
  248.   opponent knows the full algorithm (including how any message key is
  249.   distributed) and only the private key is kept secret. There are some
  250.   systematic and unsystematic ways to take reasonably long ciphertexts
  251.   and decrypt them even without prior knowledge of the algorithm, but
  252.   this is a time-consuming and possibly fruitless exercise which most
  253.   sci.crypt readers won't bother with.
  254.  
  255.   So what do you do if you have a new encryption scheme? First of all,
  256.   find out if it's really new. Look through this FAQ for references and
  257.   related methods. Familiarize yourself with the literature and the
  258.   introductory textbooks.
  259.  
  260.   When you can appreciate how your cryptosystem fits into the world at
  261.   large, try to break it yourself! You shouldn't waste the time of tens
  262.   of thousands of readers asking a question which you could have easily
  263.   answered on your own.
  264.  
  265.   If you really think your system is secure, and you want to get some
  266.   reassurance from experts, you might try posting full details of your
  267.   system, including working code and a solid theoretical explanation, to
  268.   sci.crypt. (Keep in mind that the export of cryptography is regulated
  269.   in some areas.)
  270.  
  271.   If you're lucky an expert might take some interest in what you posted.
  272.   You can encourage this by offering cash rewards---for instance, noted
  273.   cryptographer Ralph Merkle is offering $1000 to anyone who can break
  274.   Snefru-4---but there are no guarantees. If you don't have enough
  275.   experience, then most likely any experts who look at your system will
  276.   be able to find a flaw. If this happens, it's your responsibility to
  277.   consider the flaw and learn from it, rather than just add one more
  278.   layer of complication and come back for another round.
  279.  
  280.   A different way to get your cryptosystem reviewed is to have the NSA
  281.   look at it. A full discussion of this procedure is outside the scope
  282.   of this FAQ.
  283.  
  284.   Among professionals, a common rule of thumb is that if you want to
  285.   design a cryptosystem, you have to have experience as a cryptanalyst.
  286.  
  287. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  288. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  289. From: crypt-comments@math.ncsu.edu
  290. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  291. Subject: Cryptography FAQ (03/10: Basic Cryptology)
  292. Supersedes: <cryptography-faq/part03_775545033@rtfm.mit.edu>
  293. Followup-To: poster
  294. Date: 20 Aug 1994 16:36:25 GMT
  295. Organization: The Crypt Cabal
  296. Lines: 251
  297. Approved: news-answers-request@MIT.Edu
  298. Expires: 24 Sep 1994 16:36:22 GMT
  299. Message-ID: <cryptography-faq/part03_777400582@rtfm.mit.edu>
  300. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  301. Reply-To: crypt-comments@math.ncsu.edu
  302. NNTP-Posting-Host: bloom-picayune.mit.edu
  303. X-Last-Updated: 1994/07/05
  304. Originator: faqserv@bloom-picayune.MIT.EDU
  305. Xref: ankh.iia.org sci.crypt:7647 talk.politics.crypto:4463 sci.answers:632 news.answers:9727 talk.answers:156
  306.  
  307. Archive-name: cryptography-faq/part03
  308. Last-modified: 93/10/10
  309.  
  310.  
  311. This is the third of ten parts of the sci.crypt FAQ. The parts are
  312. mostly independent, but you should read the first part before the rest.
  313. We don't have the time to send out missing parts by mail, so don't ask.
  314. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  315.  
  316. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  317. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  318. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  319. sci.answers, and news.answers every 21 days.
  320.  
  321.  
  322. Contents:
  323.  
  324. 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key?
  325. 3.2. What references can I start with to learn cryptology?
  326. 3.3. How does one go about cryptanalysis?
  327. 3.4. What is a brute-force search and what is its cryptographic relevance?
  328. 3.5. What are some properties satisfied by every strong cryptosystem?
  329. 3.6. If a cryptosystem is theoretically unbreakable, then is it
  330.   guaranteed analysis-proof in practice?
  331. 3.7. Why are many people still using cryptosystems that are
  332.   relatively easy to break?
  333. 3.8. What are the basic types of cryptanalytic `attacks'?
  334.  
  335.  
  336. 3.1. What is cryptology? Cryptography? Plaintext? Ciphertext? Encryption? Key?
  337.  
  338.   The story begins: When Julius Caesar sent messages to his trusted
  339.   acquaintances, he didn't trust the messengers. So he replaced every A
  340.   by a D, every B by a E, and so on through the alphabet. Only someone
  341.   who knew the ``shift by 3'' rule could decipher his messages.
  342.  
  343.   A cryptosystem or cipher system is a method of disguising messages so
  344.   that only certain people can see through the disguise. Cryptography is
  345.   the art of creating and using cryptosystems. Cryptanalysis is the art
  346.   of breaking cryptosystems---seeing through the disguise even when
  347.   you're not supposed to be able to. Cryptology is the study of both
  348.   cryptography and cryptanalysis.
  349.  
  350.   The original message is called a plaintext. The disguised message is
  351.   called a ciphertext. Encryption means any procedure to convert
  352.   plaintext into ciphertext. Decryption means any procedure to convert
  353.   ciphertext into plaintext.
  354.  
  355.   A cryptosystem is usually a whole collection of algorithms. The
  356.   algorithms are labelled; the labels are called keys. For instance,
  357.   Caesar probably used ``shift by n'' encryption for several different
  358.   values of n. It's natural to say that n is the key here.
  359.  
  360.   The people who are supposed to be able to see through the disguise are
  361.   called recipients. Other people are enemies, opponents, interlopers,
  362.   eavesdroppers, or third parties.
  363.  
  364. 3.2. What references can I start with to learn cryptology?
  365.  
  366.   For an introduction to technical matter, the survey articles given
  367.   in part 10 are the best place to begin as they are, in general,
  368.   concise, authored by competent people, and well written. However,
  369.   these articles are mostly concerned with cryptology as it has
  370.   developed in the last 50 years or so, and are more abstract and
  371.   mathematical than historical. The Codebreakers by Kahn [KAH67] is
  372.   encyclopedic in its history and technical detail of cryptology up
  373.   to the mid-60's.
  374.  
  375.   Introductory cryptanalysis can be learned from Gaines [GAI44] or
  376.   Sinkov [SIN66]. This is recommended especially for people who want
  377.   to devise their own encryption algorithms since it is a common
  378.   mistake to try to make a system before knowing how to break one.
  379.  
  380.   The selection of an algorithm for the DES drew the attention of
  381.   many public researchers to problems in cryptology. Consequently
  382.   several textbooks and books to serve as texts have appeared. The
  383.   book of Denning [DEN82] gives a good introduction to a broad range
  384.   of security including encryption algorithms, database security,
  385.   access control, and formal models of security. Similar comments
  386.   apply to the books of Price & Davies [PRI84] and Pfleeger [PFL89].
  387.  
  388.   The books of Konheim [KON81] and Meyer & Matyas [MEY82] are quite
  389.   technical books. Both Konheim and Meyer were directly involved in
  390.   the development of DES, and both books give a thorough analysis of
  391.   DES. Konheim's book is quite mathematical, with detailed analyses
  392.   of many classical cryptosystems. Meyer and Matyas concentrate on
  393.   modern cryptographic methods, especially pertaining to key management
  394.   and the integration of security facilities into computer systems and
  395.   networks. For more recent documentation on related areas, try
  396.   G. Simmons in [SIM91].
  397.  
  398.   The books of Rueppel [RUE86] and Koblitz [KOB89] concentrate on
  399.   the application of number theory and algebra to cryptography.
  400.  
  401. 3.3. How does one go about cryptanalysis?
  402.  
  403.   Classical cryptanalysis involves an interesting combination of
  404.   analytical reasoning, application of mathematical tools, pattern
  405.   finding, patience, determination, and luck. The best available
  406.   textbooks on the subject are the Military Cryptanalytics series
  407.   [FRIE1]. It is clear that proficiency in cryptanalysis is, for
  408.   the most part, gained through the attempted solution of given
  409.   systems. Such experience is considered so valuable that some of the
  410.   cryptanalyses performed during WWII by the Allies are still
  411.   classified.
  412.  
  413.   Modern public-key cryptanalysis may consist of factoring an integer,
  414.   or taking a discrete logarithm. These are not the traditional fare
  415.   of the cryptanalyst. Computational number theorists are some of the
  416.   most successful cryptanalysts against public key systems.
  417.  
  418. 3.4. What is a brute-force search and what is its cryptographic relevance?
  419.  
  420.   In a nutshell: If f(x) = y and you know y and can compute f, you can
  421.   find x by trying every possible x. That's brute-force search.
  422.  
  423.   Example: Say a cryptanalyst has found a plaintext and a corresponding
  424.   ciphertext, but doesn't know the key. He can simply try encrypting the
  425.   plaintext using each possible key, until the ciphertext matches---or
  426.   decrypting the ciphertext to match the plaintext, whichever is faster.
  427.   Every well-designed cryptosystem has such a large key space that this
  428.   brute-force search is impractical.
  429.     
  430.   Advances in technology sometimes change what is considered
  431.   practical. For example, DES, which has been in use for over 10 years
  432.   now, has 2^56, or about 10^17, possible keys. A computation with
  433.   this many operations was certainly unlikely for most users in the
  434.   mid-70's. The situation is very different today given the dramatic
  435.   decrease in cost per processor operation. Massively parallel
  436.   machines threaten the security of DES against brute force search.
  437.   Some scenarios are described by Garron and Outerbridge [GAR91].
  438.  
  439.   One phase of a more sophisticated cryptanalysis may involve a
  440.   brute-force search of some manageably small space of possibilities.
  441.  
  442. 3.5. What are some properties satisfied by every strong cryptosystem?
  443.  
  444.   The security of a strong system resides with the secrecy of the key
  445.   rather than with the supposed secrecy of the algorithm.
  446.  
  447.   A strong cryptosystem has a large keyspace, as mentioned above. It
  448.   has a reasonably large unicity distance; see question 8.8.
  449.  
  450.   A strong cryptosystem will certainly produce ciphertext which appears
  451.   random to all standard statistical tests (see, for example, [CAE90]).
  452.     
  453.   A strong cryptosystem will resist all known previous attacks. A
  454.   system which has never been subjected to scrutiny is suspect.
  455.  
  456.   If a system passes all the tests mentioned above, is it necessarily
  457.   strong? Certainly not. Many weak cryptosystems looked good at first.
  458.   However, sometimes it is possible to show that a cryptosystem is
  459.   strong by mathematical proof. ``If Joe can break this system, then
  460.   he can also solve the well-known difficult problem of factoring
  461.   integers.'' See part 6. Failing that, it's a crap shoot.
  462.  
  463. 3.6. If a cryptosystem is theoretically unbreakable, then is it
  464.   guaranteed analysis-proof in practice?
  465.  
  466.   Cryptanalytic methods include what is known as ``practical
  467.   cryptanalysis'': the enemy doesn't have to just stare at your
  468.   ciphertext until he figures out the plaintext. For instance, he might
  469.   assume ``cribs''---stretches of probable plaintext. If the crib is
  470.   correct then he might be able to deduce the key and then decipher the
  471.   rest of the message. Or he might exploit ``isologs''---the same
  472.   plaintext enciphered in several cryptosystems or several keys. Thus
  473.   he might obtain solutions even when cryptanalytic theory says he
  474.   doesn't have a chance.
  475.  
  476.   Sometimes, cryptosystems malfunction or are misused. The one-time pad,
  477.   for example, loses all security if it is used more than once! Even
  478.   chosen-plaintext attacks, where the enemy somehow feeds plaintext into
  479.   the encryptor until he can deduce the key, have been employed. See
  480.   [KAH67].
  481.   
  482. 3.7. Why are many people still using cryptosystems that are
  483.   relatively easy to break?
  484.  
  485.   Some don't know any better. Often amateurs think they can design
  486.   secure systems, and are not aware of what an expert cryptanalyst
  487.   could do. And sometimes there is insufficient motivation for anybody
  488.   to invest the work needed to crack a system.
  489.  
  490. 3.8. What are the basic types of cryptanalytic `attacks'?
  491.  
  492.   A standard cryptanalytic attack is to know some plaintext matching a
  493.   given piece of ciphertext and try to determine the key which maps one 
  494.   to the other.  This plaintext can be known because it is standard (a
  495.   standard greeting, a known header or trailer, ...) or because it is
  496.   guessed.  If text is guessed to be in a message, its position is probably
  497.   not known, but a message is usually short enough that the cryptanalyst
  498.   can assume the known plaintext is in each possible position and do
  499.   attacks for each case in parallel.  In this case, the known plaintext can
  500.   be something so common that it is almost guaranteed to be in a message.
  501.  
  502.   A strong encryption algorithm will be unbreakable not only under known
  503.   plaintext (assuming the enemy knows all the plaintext for a given
  504.   ciphertext) but also under "adaptive chosen plaintext" -- an attack
  505.   making life much easier for the cryptanalyst.  In this attack, the enemy
  506.   gets to choose what plaintext to use and gets to do this over and over,
  507.   choosing the plaintext for round N+1 only after analyzing the result of
  508.   round N.
  509.  
  510.   For example, as far as we know, DES is reasonably strong even under an
  511.   adaptive chosen plaintext attack (the attack Biham and Shamir used).  Of
  512.   course, we do not have access to the secrets of government cryptanalytic
  513.   services.  Still, it is the working assumption that DES is reasonably
  514.   strong under known plaintext and triple-DES is very strong under all
  515.   attacks.
  516.  
  517.   To summarize, the basic types of cryptanalytic attacks in order of
  518.   difficulty for the attacker, hardest first, are:
  519.  
  520.   cyphertext only: the attacker has only the encoded message from which 
  521.     to determine the plaintext, with no knowledge whatsoever of the
  522.     latter.
  523.  
  524.     A cyphertext only attack is usually presumed to be possible, and
  525.     a code's resistance to it is considered the basis of its 
  526.     cryptographic security.
  527.  
  528.   known plaintext: the attacker has the plaintext and corresponding 
  529.     cyphertext of an arbitrary message not of his choosing. The
  530.     particular message of the sender's is said to be `compromised'.
  531.  
  532.     In some systems, one known cyphertext-plaintext pair will 
  533.     compromise the overall system, both prior and subsequent
  534.     transmissions, and resistance to this is characteristic of a 
  535.     secure code.
  536.  
  537.   Under the following attacks, the attacker has the far less likely
  538.   or plausible ability to `trick' the sender into encrypting or 
  539.   decrypting arbitrary plaintexts or cyphertexts. Codes that resist 
  540.   these attacks are considered to have the utmost security.
  541.  
  542.   chosen plaintext: the attacker has the capability to find the 
  543.     cyphertext corresponding to an arbitrary plaintext message of his 
  544.     choosing.
  545.  
  546.   chosen cyphertext: the attacker can choose arbitrary cyphertext and
  547.     find the corresponding decrypted plaintext. This attack can show
  548.     in public key systems, where it may reveal the private key.
  549.  
  550.   adaptive chosen plaintext: the attacker can determine the cyphertext
  551.     of chosen plaintexts in an interactive or iterative process based on
  552.     previous results. This is the general name for a method of attacking 
  553.     product ciphers called `differential cryptanalysis'.
  554.  
  555.   The next part of the FAQ gives the mathematical detail behind the 
  556.   various types of cryptoanalytic attacks.
  557.  
  558.  
  559. From ankh.iia.org!uunet!MathWorks.Com!news2.near.net!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  560. Path: ankh.iia.org!uunet!MathWorks.Com!news2.near.net!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  561. From: crypt-comments@math.ncsu.edu
  562. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  563. Subject: Cryptography FAQ (04/10: Mathematical Cryptology)
  564. Supersedes: <cryptography-faq/part04_775545033@rtfm.mit.edu>
  565. Followup-To: poster
  566. Date: 20 Aug 1994 16:36:29 GMT
  567. Organization: The Crypt Cabal
  568. Lines: 210
  569. Approved: news-answers-request@MIT.Edu
  570. Expires: 24 Sep 1994 16:36:22 GMT
  571. Message-ID: <cryptography-faq/part04_777400582@rtfm.mit.edu>
  572. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  573. Reply-To: crypt-comments@math.ncsu.edu
  574. NNTP-Posting-Host: bloom-picayune.mit.edu
  575. X-Last-Updated: 1994/07/05
  576. Originator: faqserv@bloom-picayune.MIT.EDU
  577. Xref: ankh.iia.org sci.crypt:7648 talk.politics.crypto:4464 sci.answers:633 news.answers:9728 talk.answers:157
  578.  
  579. Archive-name: cryptography-faq/part04
  580. Last-modified: 93/10/10
  581.  
  582. This is the fourth of ten parts of the sci.crypt FAQ. The parts are
  583. mostly independent, but you should read the first part before the rest.
  584. We don't have the time to send out missing parts by mail, so don't ask.
  585. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  586.  
  587. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  588. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  589. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  590. sci.answers, and news.answers every 21 days.
  591.  
  592.  
  593.  
  594. Contents:
  595.  
  596. 4.1. In mathematical terms, what is a private-key cryptosystem?
  597. 4.2. What is an attack?
  598. 4.3. What's the advantage of formulating all this mathematically?
  599. 4.4. Why is the one-time pad secure?
  600. 4.5. What's a ciphertext-only attack?
  601. 4.6. What's a known-plaintext attack?
  602. 4.7. What's a chosen-plaintext attack?
  603. 4.8. In mathematical terms, what can you say about brute-force attacks?
  604. 4.9. What's a key-guessing attack? What's entropy?
  605.  
  606.  
  607. Reader, beware: This section is highly mathematical. Well, maybe not
  608. _highly_ mathematical, but it's got a bunch of symbols and scary-looking
  609. formulas. You have been warned.
  610.  
  611.  
  612. 4.1. In mathematical terms, what is a private-key cryptosystem?
  613.  
  614.   A private-key cryptosystem consists of an encryption system E and a
  615.   decryption system D. The encryption system E is a collection of
  616.   functions E_K, indexed by ``keys'' K, mapping some set of
  617.   ``plaintexts'' P to some set of ``ciphertexts'' C. Similarly the
  618.   decryption system D is a collection of functions D_K such that
  619.   D_K(E_K(P)) = P for every plaintext P. That is, succesful decryption
  620.   of ciphertext into plaintext is accomplished using the same key
  621.   (index) as was used for the corresponding encryption of plaintext
  622.   into ciphertext. Such systems, where the same key value is used to
  623.   encrypt and decrypt, are also known as ``symmetric'' cryptoystems.
  624.  
  625. 4.2. What is an attack?
  626.  
  627.   In intuitive terms a (passive) attack on a cryptosystem is any method
  628.   of starting with some information about plaintexts and their
  629.   corresponding ciphertexts under some (unknown) key, and figuring out
  630.   more information about the plaintexts. It's possible to state
  631.   mathematically what this means. Here we go.
  632.  
  633.   Fix functions F, G, and H of n variables. Fix an encryption system E,
  634.   and fix a distribution of plaintexts and keys.
  635.  
  636.   An attack on E using G assuming F giving H with probability p is an
  637.   algorithm A with a pair f, g of inputs and one output h, such that
  638.   there is probability p of computing h = H(P_1,...,P_n), if we have
  639.   f = F(P_1,...,P_n) and g = G(E_K(P_1),...,E_K(P_n)). Note that this
  640.   probability depends on the distribution of the vector (K,P_1,...,P_n).
  641.  
  642.   The attack is trivial (or ``pointless'') if there is probability at
  643.   least p of computing h = H(P_1,...,P_n) if f = F(P_1,...,P_n) and
  644.   g = G(C_1,...,C_n). Here C_1,...,C_n range uniformly over the possible
  645.   ciphertexts, and have no particular relation to P_1,...,P_n. In other
  646.   words, an attack is trivial if it doesn't actually use the encryptions
  647.   E_K(P_1),...,E_K(P_n).
  648.  
  649.   An attack is called ``one-ciphertext'' if n = 1, ``two-ciphertext'' if
  650.   n = 2, and so on.
  651.  
  652. 4.3. What's the advantage of formulating all this mathematically?
  653.  
  654.   In basic cryptology you can never prove that a cryptosystem is secure.
  655.   Read part 3: we keep saying ``a strong cryptosystem must have this
  656.   property, but having this property is no guarantee that a cryptosystem
  657.   is strong!''
  658.  
  659.   In contrast, the purpose of mathematical cryptology is to precisely
  660.   formulate and, if possible, prove the statement that a cryptosystem is
  661.   strong. We say, for example, that a cryptosystem is secure against
  662.   all (passive) attacks if any nontrivial attack against the system (as
  663.   defined above) is too slow to be practical. If we can prove this
  664.   statement then we have confidence that our cryptosystem will resist
  665.   any (passive) cryptanalytic technique. If we can reduce this statement
  666.   to some well-known unsolved problem then we still have confidence that
  667.   the cryptosystem isn't easy to break.
  668.  
  669.   Other parts of cryptology are also amenable to mathematical
  670.   definition. Again the point is to explicitly identify what assumptions
  671.   we're making and prove that they produce the desired results. We can
  672.   figure out what it means for a particular cryptosystem to be used
  673.   properly: it just means that the assumptions are valid.
  674.  
  675.   The same methodology is useful for cryptanalysis too. The cryptanalyst
  676.   can take advantage of incorrect assumptions. Often he can try to
  677.   construct a proof of security for a system, see where the proof fails,
  678.   and use these failures as the starting points for his analysis.
  679.   
  680. 4.4. Why is the one-time pad secure?
  681.  
  682.   By definition, the one-time pad is a cryptosystem where the
  683.   plaintexts, ciphertexts, and keys are all strings (say byte strings)
  684.   of some length m, and E_K(P) is just the sum (let's say the exclusive
  685.   or) of K and P.
  686.  
  687.   It is easy to prove mathematically that there are _no_ nontrivial
  688.   single-ciphertext attacks on the one-time pad, assuming a uniform
  689.   distribution of keys. Note that we don't have to assume a uniform
  690.   distribution of plaintexts. (Here's the proof: Let A be an attack,
  691.   i.e., an algorithm taking two inputs f, g and producing one output h,
  692.   with some probability p that h = H(P) whenever f = F(P) and
  693.   g = G(E_K(P)) (i.e., g = G(K + P)). Then, because the distribution of
  694.   K is uniform and independent of P, the distribution of K + P must also
  695.   be uniform and independent of P. But also the distribution of C is
  696.   uniform and independent of P. Hence there is probability exactly p
  697.   that h = H(P) whenever f = F(P) and g = G(C), over all P and C. Thus
  698.   a fortiori A is trivial.)
  699.  
  700.   On the other hand the one-time pad is _not_ secure if a key K is used
  701.   for more than one plaintext: i.e., there are nontrivial
  702.   multiple-ciphertext attacks. So to be properly used a key K must be
  703.   thrown away after one encryption. The key is also called a ``pad'';
  704.   this explains the name ``one-time pad.''
  705.  
  706.   Also, a computer-based pseudo-random number generator does _not_ 
  707.   qualify as a true one-time pad because of its deterministic 
  708.   properties. See `pseudo-random number generators as key stream'.
  709.  
  710. 4.5. What's a ciphertext-only attack?
  711.  
  712.   In the notation above, a ciphertext-only attack is one where F is
  713.   constant. Given only some information G(E_K(P_1),...,E_K(P_n)) about
  714.   n ciphertexts, the attack has to have some chance of producing some
  715.   information H(P_1,...,P_n) about the plaintexts. The attack is trivial
  716.   if it has just as good a chance of producing H(P_1,...,P_n) when given
  717.   G(C_1,...,C_n) for random C_1,...,C_n.
  718.  
  719.   For example, say G(C) = C, and say H(P) is the first bit of P. We can
  720.   easily write down an attack---the ``guessing attack,'' which simply
  721.   guesses that H(P) is 1. This attack is trivial because it doesn't use
  722.   the ciphertext: it has a fifty-fifty chance of guessing correctly no
  723.   matter what. On the other hand there is an attack on RSA which
  724.   produces one bit of information about P, with 100% success, using C.
  725.   If it is fed a random C then the success rate drops to 50%. So this is
  726.   a nontrivial attack.
  727.  
  728. 4.6. What's a known-plaintext attack?
  729.  
  730.   The classic known-plaintext attack has F(P_1,P_2) = P_1,
  731.   G(C_1,C_2) = (C_1,C_2), and H(P_1,P_2) depending only on P_2.
  732.   In other words, given two ciphertexts C_1 and C_2 and one decryption
  733.   P_1, the known-plaintext attack should produce information about the
  734.   other decryption P_2.
  735.  
  736.   Note that known-plaintext attacks are often defined in the literature
  737.   as producing information about the key, but this is pointless: the
  738.   cryptanalyst generally cares about the key only insofar as it lets him
  739.   decrypt further messages.
  740.  
  741. 4.7. What's a chosen-plaintext attack?
  742.  
  743.   A chosen-plaintext attack is the first of an increasingly impractical
  744.   series of _active_ attacks on a cryptosystem: attacks where the
  745.   cryptanalyst feeds data to the encryptor. These attacks don't fit into
  746.   our model of passive attacks explained above. Anyway, a
  747.   chosen-plaintext attack lets the cryptanalyst choose a plaintext and
  748.   look at the corresponding ciphertext, then repeat until he has figured
  749.   out how to decrypt any message. More absurd examples of this sort of
  750.   attack are the ``chosen-key attack'' and ``chosen-system attack.''
  751.  
  752.   A much more important form of active attack is a message corruption
  753.   attack, where the attacker tries to change the ciphertext in such a
  754.   way as to make a useful change in the plaintext.
  755.  
  756.   There are many easy ways to throw kinks into all of these attacks:
  757.   for instance, automatically encrypting any plaintext P as
  758.   T,E_K(h(T+R+P),R,P), where T is a time-key (sequence number) chosen anew
  759.   for each message, R is a random number, and h is a one-way hash
  760.   function. Here comma means concatenation and plus means exclusive-or.
  761.  
  762. 4.8. In mathematical terms, what can you say about brute-force attacks?
  763.  
  764.   Consider the following known-plaintext attack. We are given some
  765.   plaintexts P_1,...,P_{n-1} and ciphertexts C_1,...,C_{n-1}. We're
  766.   also given a ciphertext C_n. We run through every key K. When we find
  767.   K such that E_K(P_i) = C_i for every i < n, we print D_K(C_n).
  768.  
  769.   If n is big enough that only one key works, this attack will succeed
  770.   on valid inputs all the time, while it will produce correct results
  771.   only once in a blue moon for random inputs. Thus this is a nontrivial
  772.   attack. Its only problem is that it is very slow if there are many
  773.   possible keys.
  774.  
  775. 4.9. What's a key-guessing attack? What's entropy?
  776.  
  777.   Say somebody is using the one-time pad---but isn't choosing keys
  778.   randomly and uniformly from all m-bit messages, as he was supposed to
  779.   for our security proof. In fact say he's known to prefer keys which
  780.   are English words. Then a cryptanalyst can run through all English
  781.   words as possible keys. This attack will often succeed, and it's much
  782.   faster than a brute-force search of the entire keyspace.
  783.  
  784.   We can measure how bad a key distribution is by calculating its
  785.   entropy. This number E is the number of ``real bits of information''
  786.   of the key: a cryptanalyst will typically happen across the key within
  787.   2^E guesses. E is defined as the sum of -p_K log_2 p_K, where p_K is
  788.   the probability of key K.
  789.  
  790. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  791. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  792. From: crypt-comments@math.ncsu.edu
  793. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  794. Subject: Cryptography FAQ (05/10: Product Ciphers)
  795. Supersedes: <cryptography-faq/part05_775545033@rtfm.mit.edu>
  796. Followup-To: poster
  797. Date: 20 Aug 1994 16:36:36 GMT
  798. Organization: The Crypt Cabal
  799. Lines: 466
  800. Approved: news-answers-request@MIT.Edu
  801. Expires: 24 Sep 1994 16:36:22 GMT
  802. Message-ID: <cryptography-faq/part05_777400582@rtfm.mit.edu>
  803. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  804. Reply-To: crypt-comments@math.ncsu.edu
  805. NNTP-Posting-Host: bloom-picayune.mit.edu
  806. X-Last-Updated: 1994/07/05
  807. Originator: faqserv@bloom-picayune.MIT.EDU
  808. Xref: ankh.iia.org sci.crypt:7649 talk.politics.crypto:4465 sci.answers:634 news.answers:9729 talk.answers:158
  809.  
  810. Archive-name: cryptography-faq/part05
  811. Last-modified: 94/06/07
  812.  
  813.  
  814. This is the fifth of ten parts of the sci.crypt FAQ. The parts are
  815. mostly independent, but you should read the first part before the rest.
  816. We don't have the time to send out missing parts by mail, so don't ask.
  817. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  818.  
  819. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  820. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  821. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  822. sci.answers, and news.answers every 21 days.
  823.  
  824.  
  825.  
  826. Contents:
  827.  
  828. 5.1. What is a product cipher?
  829. 5.2. What makes a product cipher secure?
  830. 5.3. What are some group-theoretic properties of product ciphers?
  831. 5.4. What can be proven about the security of a product cipher?
  832. 5.5. How are block ciphers used to encrypt data longer than the block size?
  833. 5.6. Can symmetric block ciphers be used for message authentication?
  834. 5.7. What exactly is DES?
  835. 5.8. What is triple DES?
  836. 5.9. What is differential cryptanalysis?
  837. 5.10. How was NSA involved in the design of DES?
  838. 5.11. Is DES available in software?
  839. 5.12. Is DES available in hardware?
  840. 5.13. Can DES be used to protect classified information?
  841. 5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
  842.  
  843.  
  844. 5.1. What is a product cipher?
  845.  
  846.   A product cipher is a block cipher that iterates several weak
  847.   operations such as substitution, transposition, modular
  848.   addition/multiplication, and linear transformation. (A ``block
  849.   cipher'' just means a cipher that encrypts a block of data---8 bytes,
  850.   say---all at once, then goes on to the next block.) The notion of
  851.   product ciphers is due to Shannon [SHA49]. Examples of modern
  852.   product ciphers include LUCIFER [SOR84], DES [NBS77], SP-networks
  853.   [KAM78], LOKI [BRO90], FEAL [SHI84], PES [LAI90], Khufu and Khafre
  854.   [ME91a]. The so-called Feistel ciphers are a class of product
  855.   ciphers which operate on one half of the ciphertext at each round,
  856.   and then swap the ciphertext halves after each round. LUCIFER,
  857.   DES, LOKI, and FEAL are examples of Feistel ciphers.
  858.  
  859.   The following table compares the main parameters of several product 
  860.   ciphers:
  861.  
  862.   cipher   |   block length   |   key bits   |   number of rounds
  863.   LUCIFER          128               128                16
  864.   DES               64                56                16
  865.   LOKI              64                64                16
  866.   FEAL              64               128            2^x, x >= 5
  867.   PES               64               128                 8
  868.  
  869. 5.2. What makes a product cipher secure?
  870.  
  871.   Nobody knows how to prove mathematically that a product cipher is
  872.   completely secure. So in practice one begins by demonstrating that the
  873.   cipher ``looks highly random''. For example, the cipher must be
  874.   nonlinear, and it must produce ciphertext which functionally depends
  875.   on every bit of the plaintext and the key. Meyer [MEY78] has shown
  876.   that at least 5 rounds of DES are required to guarantee such a
  877.   dependence. In this sense a product cipher should act as a ``mixing''
  878.   function which combines the plaintext, key, and ciphertext in a
  879.   complex nonlinear fashion.
  880.  
  881.   The fixed per-round substitutions of the product cipher are
  882.   referred to as S-boxes. For example, LUCIFER has 2 S-boxes, and DES
  883.   has 8 S-boxes. The nonlinearity of a product cipher reduces to a
  884.   careful design of these S-boxes. A list of partial design criteria
  885.   for the S-boxes of DES, which apply to S-boxes in general, may be
  886.   found in Brown [BRO89] and Brickell et al. [BRI86].
  887.  
  888. 5.3. What are some group-theoretic properties of product ciphers?
  889.  
  890.   Let E be a product cipher that maps N-bit blocks to N-bit blocks.
  891.   Let E_K(X) be the encryption of X under key K. Then, for any fixed K,
  892.   the map sending X to E_K(X) is a permutation of the set of N-bit
  893.   blocks. Denote this permutation by P_K. The set of all N-bit
  894.   permutations is called the symmetric group and is written S_{2^N}.
  895.   The collection of all these permutations P_K, where K ranges over all
  896.   possible keys, is denoted E(S_{2^N}). If E were a random mapping from
  897.   plaintexts to ciphertexts then we would expect E(S_{2^N}) to generate
  898.   a large subset of S_{2^N}.
  899.  
  900.   Coppersmith and Grossman [COP74] have shown that a very simple
  901.   product cipher can generate the alternating group A_{2^N} given a
  902.   sufficient number of rounds. (The alternating group is half of the
  903.   symmetric group: it consists of all ``even'' permutations, i.e., all
  904.   permutations which can be written as an even number of swaps.)
  905.   Even and Goldreich [EVE83] were able to extend these results to show
  906.   that Feistel ciphers can generate A_{2^N}, given a sufficient number
  907.   of rounds.
  908.  
  909.   The security of multiple encipherment also depends on the
  910.   group-theoretic properties of a cipher. Multiple encipherment is an
  911.   extension over single encipherment if for keys K1, K2 there does
  912.   not exist a third key K3 such that
  913.  
  914.   E_K2(E_K1(X)) == E_(K3)(X)                (**)
  915.  
  916.   which indicates that encrypting twice with two independent keys
  917.   K1, K2 is equal to a single encryption under the third key K3. If
  918.   for every K1, K2 there exists a K3 such that eq. (**) is true then
  919.   we say that E is a group.
  920.  
  921.   This question of whether DES is a group under this definition was
  922.   extensively studied by Sherman, Kaliski, and Rivest [SHE88]. In their
  923.   paper they give strong evidence for the hypothesis that DES is not a
  924.   group. In fact DES is not a group [CAM93].
  925.  
  926. 5.4. What can be proven about the security of a product cipher?
  927.  
  928.   Recall from above that P_K is a permutation produced by E under
  929.   some key K. The goal of the designer of E is to ensure that P_K
  930.   appears to be a random element of S_{2^N}, the symmetric group.
  931.   Let R be an element of S_{2^N} selected randomly. We will say that P_K
  932.   and R are indistinguishable if an observer given P_K and R in some
  933.   order cannot distinguish between these two permutations in polynomial
  934.   time. That is, with time bounded resources, the observer cannot
  935.   determine which of the permutations is produced by E: the optimal
  936.   decision is no better than simply guessing.
  937.  
  938.   Luby and Rackoff [LUB88] have shown that a class of Feistel ciphers
  939.   are secure in this sense when the round mapping is replaced by
  940.   random boolean functions.
  941.  
  942. 5.5. How are block ciphers used to encrypt data longer than the block size?
  943.  
  944.   There are four standard ``modes of operation'' (and numerous non-standard
  945.   ones as well). The standard modes of operation are defined in the U.S.
  946.   Department of Commerce Federal Information Processing Standard (FIPS) 81,
  947.   published in 1980. See the question about ECB below for more details.
  948.  
  949.   Although they are defined for the DES block cipher, the ``modes of
  950.   operation'' can be used with any block cipher.
  951.  
  952. 5.6. Can symmetric block ciphers be used for message authentication?
  953.  
  954.   You may use a symmetric cryptosystem block cipher to prove to yourself
  955.   that you generated a message, and that the message wasn't altered
  956.   after you created it. But you cannot prove these things to anyone else
  957.   without revealing your key. Thereafter you cannot prove anything about
  958.   messages authenticated with that key.
  959.   
  960.   See ANSI X3.106-1983 and FIPS 113 (1985) for a standard method of message
  961.   authentication using DES.
  962.  
  963. 5.7. What exactly is DES?
  964.  
  965.   DES is the U.S. Government's Data Encryption Standard, a product 
  966.   cipher that operates on 64-bit blocks of data, using a 56-bit key. 
  967.  
  968.   It is defined in FIPS 46-1 (1988) [which supersedes FIPS 46 (1977)].
  969.   FIPS are Federal Information Processing Standards published by NTIS.
  970.   DES is identical to the ANSI standard Data Encryption Algorithm (DEA)
  971.   defined in ANSI X3.92-1981. 
  972.  
  973. 5.8. What is triple DES?
  974.  
  975.   Triple DES is a product cipher which, like DES, operates on 64-bit 
  976.   data blocks. There are several forms, each of which uses the DES
  977.   cipher 3 times. Some forms use two 56-bit keys, some use three.
  978.   The DES ``modes of operation'' may also be used with triple-DES.
  979.  
  980.   Some people refer to E(K1,D(K2,E(K1,x))) as triple-DES.
  981.  
  982.   This method is defined in chapter 7.2 of the ANSI standard X9.17-1985
  983.   ``Financial Institution Key Management'' and is intended for use in
  984.   encrypting DES keys and IVs for ``Automated Key Distribution''. Its
  985.   formal name is ``Encryption and Decryption of a Single Key by a Key
  986.   Pair'', but it is referenced in other standards documents as EDE.
  987.  
  988.   That standard says (section 7.2.1): ``Key encrypting keys may be a single
  989.   DEA key or a DEA key pair. Key pairs shoud be used where additional
  990.   security is needed (e.g., the data protected by the key(s) has a long
  991.   security life). A key pair shall not be encrypted or decrypted using a
  992.   single key.''
  993.  
  994.   Others use the term ``triple-DES'' for E(K1,D(K2,E(K3,x))) or
  995.   E(K1,E(K2,E(K3,x))).
  996.  
  997.   All of these methods are defined only for ECB mode of operation.  The
  998.   security of various methods of achieving other modes of operation (such as
  999.   CBC) is under study at the moment.  For now, it should be assumed that
  1000.   other modes be defined as they are today, but with E(K1,D(K2,E(K1,x))) as
  1001.   the block cipher within the feedback mechanism creating the mode.
  1002.  
  1003.   One of us (Ellison) has long advocated triple DES use in the form
  1004.  
  1005.     E(K1, Tran( E(K2, Tran( E(K3, Compress( x )))))),
  1006.  
  1007.   where each DES instance has its own key and IV (for CBC mode) and Tran is
  1008.   a large-block transposition program. Tran is available from [FTPTR].  This
  1009.   claims to gain security by diffusing single bit changes over a much larger
  1010.   block (Tran's block size).  Other compositions of weak ciphers with DES
  1011.   are possible.  For example, one could use:
  1012.  
  1013.    E(K1, Prngxor(K4, Tran( E(K2, Tran( Prngxor(K5, E(K3, Compress( x )))))))),
  1014.  
  1015.   where Prngxor() [FTPPX] is a simple stream cipher driven from a long-period
  1016.   pseudo-random number generator (PRNG), to make sure that all plaintext or
  1017.   ciphertext patterns are hidden while permitting the use of ECB mode for DES
  1018.   (since there are certain weaknesses in the use of inner CBC loops for
  1019.   multiple-DES, under some attacks, and we do not yet know if these show up
  1020.   under composition with Tran()).
  1021.  
  1022. 5.9. What is differential cryptanalysis?
  1023.  
  1024.   Differential cryptanalysis is a statistical attack that can be
  1025.   applied to any iterated mapping (i.e., any mapping which is based on
  1026.   a repeated round function). The method was recently popularized by
  1027.   Biham and Shamir [BIH91], but Coppersmith has remarked that the
  1028.   S-boxes of DES were optimized against this attack some 20 years ago.
  1029.   This method has proved effective against several product ciphers,
  1030.   notably FEAL [BI91a].
  1031.  
  1032.   Differential cryptanalysis is based on observing a large number of
  1033.   ciphertexts Y, Y' whose corresponding plaintexts X, X' satisfy a
  1034.   known difference D = X+X', where + is componentwise XOR. In the
  1035.   basic Biham-Shamir attack, 2^{47} such plaintext pairs are required
  1036.   to determine the key for DES. Substantially fewer pairs are required
  1037.   if DES is truncated to 6 or 8 rounds. In these cases, the actual key
  1038.   can be recovered in a matter of minutes using a few thousand pairs.
  1039.   For full DES this attack is impractical because it requires so many
  1040.   known plaintexts.
  1041.  
  1042.   The work of Biham and Shamir on DES revealed several startling
  1043.   observations on the algorithm. Most importantly, if the key
  1044.   schedule was removed from DES and a 16*48 = 768-bit key was used,
  1045.   the key could be recovered in less than 2^{64} steps. Thus
  1046.   independent subkeys do not add substantial security to DES.
  1047.   Further, the S-boxes of DES are extremely sensitive in that
  1048.   changing even single entries in these tables yields significant
  1049.   improvement in the differential attack.
  1050.  
  1051.   Adi Shamir is quoted to say (NYTimes Oct 13 1991), ``I would say
  1052.   that, contrary to what some people believe, there is no evidence
  1053.   of tampering with the DES so that the basic design was weakened.''
  1054.  
  1055. 5.10. How was NSA involved in the design of DES?
  1056.  
  1057.   According to Kinnucan [KIN78], Tuchman, a member of the group that
  1058.   developed DES at IBM is quoted as saying, ``We developed the DES
  1059.   algorithm entirely within IBM using IBMers. The NSA did not
  1060.   dictate a single wire!'' Tuchman and Meyer (another developer of
  1061.   DES) spent a year breaking ciphers and finding weaknesses in
  1062.   Lucifer. They then spent two years strengthening Lucifer. ``Their
  1063.   basic approach was to look for strong substitution, permutation,
  1064.   and key scheduling functions ... IBM has classified the notes
  1065.   containing the selection criteria at the request of the NSA....
  1066.   `The NSA told us we had inadvertently reinvented some of the deep
  1067.   secrets it uses to make its own algorithms,' explains Tuchman.''
  1068.   
  1069.   On the other hand, a document called ``Involvement of the NSA in
  1070.   the development of DES: unclassified summary of the United States
  1071.   Select Committee on Intelligence'', printed in the IEEE
  1072.   Communications Magazine, p53-55, 1978, states: ``In the development
  1073.   of DES, NSA convinced IBM that a reduced keysize was sufficient;
  1074.   indirectly assisted in the development of the S-box structures; and
  1075.   certified that the final DES algorithm was, to the best of their
  1076.   knowledge, free from any statistical or mathematical weakness.''
  1077.  
  1078.   Clearly the key size was reduced at the insistence of the NSA.
  1079.   The article further states that the NSA did not tamper with the
  1080.   algorithm itself, just the parameters, which in some sense
  1081.   resolves the apparent conflict in the remarks of Meyer and Tuchman
  1082.   presented above.
  1083.  
  1084. 5.11. Is DES available in software?
  1085.  
  1086.   Several people have made DES code available via ftp (see part 10 for
  1087.   pathnames): Stig Ostholm [FTPSO]; BSD [FTPBK]; Eric Young [FTPEY];
  1088.   Dennis Furguson [FTPDF]; Mark Riordan [FTPMR]; Phil Karn [FTPPK].
  1089.   A Pascal listing of DES is also given in Patterson [PAT87]. Antti 
  1090.   Louko <alo@kampi.hut.fi> has written a version of DES with BigNum
  1091.   packages in [FTPAL].
  1092.  
  1093.   FIPS 46-1 says ``The algorithm specified in this standard is to be
  1094.   implemented ... using hardware (not software) technology. ...
  1095.   Software implementations in general purpose computers are not in
  1096.   compliance with this standard.''  Despite this, software
  1097.   implementations abound, and are used by government agencies.
  1098.  
  1099. 5.12. Is DES available in hardware?
  1100.  
  1101.   The following paragraphs are quoted from messages sent to the editors.
  1102.   We don't vouch for the quality or even existence of the products.
  1103.  
  1104.   Christian Franke, franke@informatik.rwth-aachen.de, says: ``1.
  1105.   Cryptech CRY12C102: 22.5Mbit/s according to Data Sheet, with 32 Bit
  1106.   interface. We use this one, because it was the only one available when
  1107.   we started the project. No problems !  2. Pijnenburg PCC100: 20Mbit/s
  1108.   according to Data Sheet. Address: PIJNENBURG B.V., Boxtelswweg 26,
  1109.   NL-5261 NE Vught, The Netherlands. 3. INFOSYS DES Chip (Germany):
  1110.   S-Boxes must be loaded by software. So you can modify the Algorithm.
  1111.   Sorry, I don't have the data sheet handy. Please E-Mail me if you need
  1112.   further information.''
  1113.  
  1114.   Marcus J Ranum, mjr@tis.com, says: ``SuperCrypt'' 100Mb/sec and faster
  1115.   DES and Proprietary Storage for 16 56-bit keys Key stream generator
  1116.   Integrated hardware DES3 procedure Extended mode with 112 bit keys;
  1117.   Computer Elektronik Infosys; 512-A Herndon Parkway,; Herndon, VA
  1118.   22070; 800-322-3464.
  1119.  
  1120.   Tim Hember, thember@gandalf.ca, says: Newbridge Microsystems sells
  1121.   an AM9568 compatible DES chip that operates at 25MHz, performs a
  1122.   round of encryption in 18 clocks, has a three-stage pipeline,
  1123.   supports ECB, CBC, CFB-8 and >>> CFB-1 <<<<. Further it is very
  1124.   reasonable priced as opposed to other high-end DES chips. Call
  1125.   Newbridge Microsystems, Ottawa, 613-592-0714. (... there are no
  1126.   import/export issues with Canada and the US). If you require custom
  1127.   DES or Public Key ICs then Timestep Engineering developed
  1128.   Newbridge's crypto chips and ICs for other commercial and
  1129.   educational establishments. They can be reached at 613-820-0024.
  1130.  
  1131. 5.13. Can DES be used to protect classified information?
  1132.  
  1133.   DES is not intended to protect classified data. FIPS 46-1 says:
  1134.   ``This standard will be used by Federal departments and agencies for
  1135.   the cryptographic protection of computer data when the following
  1136.   conditions apply: 1. ... cryptographic protection is required; and
  1137.   2. the data is not classified according to the National Security Act
  1138.   of 1947, as amended, or the Atomic Energy Act of 1954, as amended.''
  1139.  
  1140. 5.14. What are ECB, CBC, CFB, OFB, and PCBC encryption?
  1141.  
  1142.   These are methods for using block ciphers, such as DES, to encrypt 
  1143.   messages, files, and blocks of data, known as ``modes of operation.''
  1144.   Four ``modes of operation'' are defined in FIPS 81 (1980 December 2), 
  1145.   and also in ANSI X3.106-1983. 
  1146.  
  1147.   FIPS 81 specifies that when 7-bit ASCII data is sent in octets, the
  1148.   unused most-significant bit is to be set to 1.
  1149.  
  1150.   FIPS 81 also specifies the padding for short blocks.
  1151.  
  1152.   The four FIPS/ANSI standard DES modes of operation are: 
  1153.         Electronic Code Book  (ECB), 
  1154.         Cipher Block Chaining (CBC), 
  1155.         K-bit Cipher FeedBack (CFB), and 
  1156.         K-bit Output FeedBack (OFB).
  1157.  
  1158.   All four of the ANSI/FIPS modes have very little "error extension".
  1159.   For a single bit error in the cipherstream, none of them produce an
  1160.   error burst in the decrypted output stream of longer than 128 bits.
  1161.  
  1162.   A fifth mode of operation, used in Kerberos and elsewhere but not
  1163.   defined in any standard, is error-Propagating Cipher Block Chaining 
  1164.   (PCBC).  Unlike the 4 standard modes, PCBC extends or propagates the
  1165.   effect of a single bit error in the cipherstream throughout remainder 
  1166.   of the decrypted textstream after the point of error.
  1167.  
  1168.   These 5 methods are explained below in a C-language-like notation.
  1169.  
  1170.   Some symbols:
  1171.  
  1172.   P[n]  The n'th block of plaintext, input to encryption, output from
  1173.         decryption. Size of block determined by the mode.
  1174.  
  1175.   C[n]  The n'th block of ciphertext, output from encryption, input to
  1176.         decryption. Size of block determined by the mode.
  1177.  
  1178.   E(m)  The DES encryption function, performed on 64-bit block m, using
  1179.         the 16-key schedule derived from some 56-bit key.
  1180.  
  1181.   D(m)  The DES decryption function, performed on 64-bit block m, using
  1182.         the same key schedule as in E(m), except that the 16 keys
  1183.         in the schedule are used in the opposite order as in E(m).
  1184.  
  1185.   IV    A 64-bit ``initialization vector'', a secret value which, along with
  1186.         the key, is shared by both encryptor and decryptor.
  1187.  
  1188.   I[n]  The n'th value of a 64-bit variable, used in some modes.
  1189.   R[n]  The n'th value of a 64-bit variable, used in some modes.
  1190.  
  1191.   LSB(m,k) The k least significant (right-most) bits of m.
  1192.         e.g. m & ((1 << k) - 1)
  1193.  
  1194.   MSB(m,k) The k most significant (left-most) bits of m.
  1195.         e.g. (m >> (64-k)) & ((1 << k) - 1)
  1196.  
  1197.   = ^ << >> &  operators as defined in the c langage.
  1198.  
  1199.  
  1200.   Electronic Code Book (ECB):
  1201.  
  1202.           P[n] and C[n] are each 64-bits long.
  1203.  
  1204.           Encryption:                   Decryption:
  1205.           C[n] = E(P[n])                P[n] = D(C[n])
  1206.  
  1207.  
  1208.   Cipher Block Chaining (CBC):
  1209.  
  1210.           P[n] and C[n] are each 64-bits long.
  1211.  
  1212.           Encryption:                   Decryption:
  1213.           C[0] = E(P[0]^IV)             P[0] = D(C[0])^IV
  1214.   (n>0)   C[n] = E(P[n]^C[n-1])         P[n] = D(C[n])^C[n-1]
  1215.  
  1216.  
  1217.   Propagating Cipher Block Chaining (PCBC):
  1218.  
  1219.           P[n] and C[n] are each 64-bits long.
  1220.  
  1221.           Encryption:                   Decryption:
  1222.           C[0] = E(P[0]^IV)             P[0] = D(C[0])^IV
  1223.   (n>0)   C[n] = E(P[n]^P[n-1]^C[n-1])  P[n] = D(C[n])^P[n-1]^C[n-1]
  1224.  
  1225.  
  1226.   k-bit Cipher FeedBack (CFB):
  1227.  
  1228.           P[n] and C[n] are each k bits long, 1 <= k <= 64. 
  1229.  
  1230.           Encryption:                   Decryption:
  1231.           I[0] = IV                     I[0] = IV
  1232.   (n>0)   I[n] = I[n-1]<<k | C[n-1]     I[n] = I[n-1]<<k | C[n-1]       
  1233.   (all n) R[n] = MSB(E(I[n]),k)         R[n] = MSB(E(I[n]),k)
  1234.   (all n) C[n] = P[n]^R[n]              P[n] = C[n]^R[n]
  1235.  
  1236.           Note that for k==64, this reduces to:
  1237.  
  1238.           I[0] = IV                     I[0] = IV
  1239.   (n>0)   I[n] = C[n-1]                 I[n] = C[n-1]   
  1240.   (all n) R[n] = E(I[n])                R[n] = E(I[n])
  1241.   (all n) C[n] = P[n]^R[n]              P[n] = C[n]^R[n]
  1242.  
  1243.   CFB notes: Since I[n] depends only on the plain or cipher text from the
  1244.   previous operation, the E() function can be performed in parallel with
  1245.   the reception of the text with which it is used.
  1246.  
  1247.  
  1248.   k-bit Output FeedBack (OFB):
  1249.  
  1250.           P[n] and C[n] are each k bits long, 1 <= k <= 64. 
  1251.  
  1252.           Encryption:                   Decryption:
  1253.           I[0] = IV                     I[0] = IV
  1254.   (n>0)   I[n] = I[n-1]<<k | R[n-1]     I[n] = I[n-1]<<k | R[n-1]       
  1255.   (all n) R[n] = MSB(E(I[n]),k)         R[n] = MSB(E(I[n]),k)
  1256.   (all n) C[n] = P[n]^R[n]              P[n] = C[n]^R[n]
  1257.  
  1258.           Note that for k==64, this reduces to:
  1259.  
  1260.           I[0] = IV                     I[0] = IV
  1261.   (n>0)   I[n] = R[n-1]                 I[n] = R[n-1]   
  1262.   (all n) R[n] = E(I[n])                R[n] = E(I[n])
  1263.   (all n) C[n] = P[n]^R[n]              P[n] = C[n]^R[n]
  1264.  
  1265.   OFB notes: encryption and decryption are identical. Since I[n] is
  1266.   independent of P and C, the E() function can be performed in advance of
  1267.   the receipt of the plain/cipher text with which it is to be used.
  1268.  
  1269.  
  1270.   Additional notes on DES ``modes of operation'':
  1271.  
  1272.   ECB and CBC use E() to encrypt and D() to decrypt, but the feedback
  1273.   modes use E() to both encrypt and decrypt. This disproves the following 
  1274.   erroneous claim: ``DES implementations which provide E() but not D()
  1275.   cannot be used for data confidentiality.''
  1276.  
  1277. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  1278. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  1279. From: crypt-comments@math.ncsu.edu
  1280. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  1281. Subject: Cryptography FAQ (06/10: Public Key Cryptography)
  1282. Supersedes: <cryptography-faq/part06_775545033@rtfm.mit.edu>
  1283. Followup-To: poster
  1284. Date: 20 Aug 1994 16:36:39 GMT
  1285. Organization: The Crypt Cabal
  1286. Lines: 274
  1287. Approved: news-answers-request@MIT.Edu
  1288. Expires: 24 Sep 1994 16:36:22 GMT
  1289. Message-ID: <cryptography-faq/part06_777400582@rtfm.mit.edu>
  1290. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  1291. Reply-To: crypt-comments@math.ncsu.edu
  1292. NNTP-Posting-Host: bloom-picayune.mit.edu
  1293. X-Last-Updated: 1994/07/05
  1294. Originator: faqserv@bloom-picayune.MIT.EDU
  1295. Xref: ankh.iia.org sci.crypt:7650 talk.politics.crypto:4466 sci.answers:635 news.answers:9730 talk.answers:159
  1296.  
  1297. Archive-name: cryptography-faq/part06
  1298. Last-modified: 94/06/07
  1299.  
  1300.  
  1301. This is the sixth of ten parts of the sci.crypt FAQ. The parts are
  1302. mostly independent, but you should read the first part before the rest.
  1303. We don't have the time to send out missing parts by mail, so don't ask.
  1304. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  1305.  
  1306. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  1307. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  1308. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  1309. sci.answers, and news.answers every 21 days.
  1310.  
  1311.  
  1312.  
  1313. Contents:
  1314.  
  1315. 6.1. What is public-key cryptography?
  1316. 6.2. How does public-key cryptography solve cryptography's Catch-22?
  1317. 6.3. What is the role of the `trapdoor function' in public key schemes?
  1318. 6.4. What is the role of the `session key' in public key schemes?
  1319. 6.5. What's RSA?
  1320. 6.6. Is RSA secure?
  1321. 6.7. What's the difference between the RSA and Diffie-Hellman schemes?
  1322. 6.8. What is `authentication' and the `key distribution problem'?
  1323. 6.9. How fast can people factor numbers?
  1324. 6.10. What about other public-key cryptosystems?
  1325. 6.11. What is the `RSA Factoring Challenge?'
  1326.  
  1327.  
  1328. 6.1. What is public-key cryptography?
  1329.  
  1330.   In a classic cryptosystem, we have encryption functions E_K and
  1331.   decryption functions D_K such that D_K(E_K(P)) = P for any plaintext
  1332.   P. In a public-key cryptosystem, E_K can be easily computed from some
  1333.   ``public key'' X which in turn is computed from K. X is published, so
  1334.   that anyone can encrypt messages. If decryption D_K cannot be easily 
  1335.   computed from public key X without knowledge of private key K, but 
  1336.   readily with knowledge of K, then only the person who generated K can 
  1337.   decrypt messages. That's the essence of public-key cryptography, 
  1338.   introduced by Diffie and Hellman in 1976. 
  1339.   
  1340.   This document describes only the rudiments of public key cryptography.
  1341.   There is an extensive literature on security models for public-key 
  1342.   cryptography, applications of public-key cryptography, other 
  1343.   applications of the mathematical technology behind public-key 
  1344.   cryptography, and so on; consult the references at the end for more 
  1345.   refined and thorough presentations.
  1346.  
  1347. 6.2. How does public-key cryptography solve cryptography's Catch-22?
  1348.  
  1349.   In a classic cryptosystem, if you want your friends to be able to
  1350.   send secret messages to you, you have to make sure nobody other than
  1351.   them sees the key K. In a public-key cryptosystem, you just publish 
  1352.   X, and you don't have to worry about spies. Hence public key 
  1353.   cryptography `solves' one of the most vexing problems of all prior 
  1354.   cryptography: the necessity of establishing a secure channel for the 
  1355.   exchange of the key. To establish a secure channel one uses 
  1356.   cryptography, but private key cryptography requires a secure channel! 
  1357.   In resolving the dilemma, public key cryptography has been considered 
  1358.   by many to be a `revolutionary technology,' representing a 
  1359.   breakthrough that makes routine communication encryption practical 
  1360.   and potentially ubiquitous.
  1361.  
  1362. 6.3. What is the role of the `trapdoor function' in public key schemes?
  1363.   
  1364.   Intrinsic to public key cryptography is a `trapdoor function' D_K 
  1365.   with the properties that computation in one direction (encryption, 
  1366.   E_K) is easy and in the other is virtually impossible (attack,
  1367.   determining P from encryption E_K(P) and public key X). Furthermore, 
  1368.   it has the special property that the reversal of the computation 
  1369.   (decryption, D_K) is again tractable if the private key K is known.
  1370.  
  1371. 6.4. What is the role of the `session key' in public key schemes?
  1372.  
  1373.   In virtually all public key systems, the encryption and decryption 
  1374.   times are very lengthy compared to other block-oriented 
  1375.   algorithms such as DES for equivalent data sizes. Therefore in most
  1376.   implementations of public-key systems, a temporary, random `session 
  1377.   key' of much smaller length than the message is generated for each 
  1378.   message and alone encrypted by the public key algorithm. The message 
  1379.   is actually encrypted using a faster private key algorithm with the 
  1380.   session key. At the receiver side, the session key is decrypted using 
  1381.   the public-key algorithms and the recovered `plaintext' key is used 
  1382.   to decrypt the message.
  1383.   
  1384.   The session key approach blurs the distinction between `keys' and 
  1385.   `messages' -- in the scheme, the message includes the key, and the 
  1386.   key itself is treated as an encryptable `message'. Under this 
  1387.   dual-encryption approach, the overall cryptographic strength is 
  1388.   related to the security of either the public- and private-key 
  1389.   algorithms.
  1390.  
  1391. 6.5. What's RSA?
  1392.  
  1393.   RSA is a public-key cryptosystem defined by Rivest, Shamir, and
  1394.   Adleman. Here's a small example. See also [FTPDQ].
  1395.  
  1396.   Plaintexts are positive integers up to 2^{512}. Keys are quadruples
  1397.   (p,q,e,d), with p a 256-bit prime number, q a 258-bit prime number,
  1398.   and d and e large numbers with (de - 1) divisible by (p-1)(q-1). We
  1399.   define E_K(P) = P^e mod pq, D_K(C) = C^d mod pq. All quantities are
  1400.   readily computed from classic and modern number theoretic algorithms 
  1401.   (Euclid's algorithm for computing the greatest common divisor yields
  1402.   an algorithm for the former, and historically newly explored
  1403.   computational approaches to finding large `probable' primes, such as 
  1404.   the Fermat test, provide the latter.)
  1405.  
  1406.   Now E_K is easily computed from the pair (pq,e)---but, as far as
  1407.   anyone knows, there is no easy way to compute D_K from the pair
  1408.   (pq,e). So whoever generates K can publish (pq,e). Anyone can send a
  1409.   secret message to him; he is the only one who can read the messages.
  1410.  
  1411. 6.6. Is RSA secure?
  1412.  
  1413.   Nobody knows. An obvious attack on RSA is to factor pq into p and q.
  1414.   See below for comments on how fast state-of-the-art factorization
  1415.   algorithms run. Unfortunately nobody has the slightest idea how to
  1416.   prove that factorization---or any realistic problem at all, for that
  1417.   matter---is inherently slow. It is easy to formalize what we mean by
  1418.   ``RSA is/isn't strong''; but, as Hendrik W. Lenstra, Jr., says,
  1419.   ``Exact definitions appear to be necessary only when one wishes to
  1420.   prove that algorithms with certain properties do _not_ exist, and
  1421.   theoretical computer science is notoriously lacking in such negative
  1422.   results.''
  1423.  
  1424.   Note that there may even be a `shortcut' to breaking RSA other than
  1425.   factoring. It is obviously sufficient but so far not provably 
  1426.   necessary. That is, the security of the system depends on two 
  1427.   critical assumptions: (1) factoring is required to break the system,
  1428.   and (2) factoring is `inherently computationally intractable',
  1429.   or, alternatively, `factoring is hard' and `any approach that can 
  1430.   be used to break the system is at least as hard as factoring'.
  1431.  
  1432.   Historically even professional cryptographers have made mistakes
  1433.   in estimating and depending on the intractability of various 
  1434.   computational problems for secure cryptographic properties. For 
  1435.   example, a system called a `Knapsack cipher' was in vogue in the
  1436.   literature for years until it was demonstrated that the instances
  1437.   typically generated could be efficiently broken, and the whole
  1438.   area of research fell out of favor.
  1439.  
  1440. 6.7. What's the difference between the RSA and Diffie-Hellman schemes?
  1441.  
  1442.   Diffie and Hellman proposed a system that requires the dynamic 
  1443.   exchange of keys for every sender-receiver pair (and in practice, 
  1444.   usually every communications session, hence the term `session key').  
  1445.   This two-way key negotiation is useful in further complicating 
  1446.   attacks, but requires additional communications overhead. The RSA 
  1447.   system reduces communications overhead with the ability to have 
  1448.   static, unchanging keys for each receiver that are `advertised' by 
  1449.   a formal `trusted authority' (the hierarchical model) or distributed 
  1450.   in an informal `web of trust'.
  1451.  
  1452. 6.8. What is `authentication' and the `key-exchange problem'?
  1453.  
  1454.   The ``key exchange problem'' involves (1) ensuring that keys are
  1455.   exchanged so that the sender and receiver can perform encryption and
  1456.   decryption, and (2) doing so in such a way that ensures an
  1457.   eavesdropper or outside party cannot break the code. `Authentication'
  1458.   adds the requirement that (3) there is some assurance to the receiver
  1459.   that a message was encrypted by `a given entity' and not `someone 
  1460.   else'.
  1461.  
  1462.   The simplest but least available method to ensure all constraints 
  1463.   above are satisfied (successful key exchange and valid authentication)
  1464.   is employed by private key cryptography: exchanging the key secretly.
  1465.   Note that under this scheme, the problem of authentication is 
  1466.   implicitly resolved. The assumption under the scheme is that only the
  1467.   sender will have the key capable of encrypting sensible messages
  1468.   delivered to the receiver. 
  1469.  
  1470.   While public-key cryptographic methods solve a critical aspect of the 
  1471.   `key-exchange problem', specifically their resistance to analysis
  1472.   even with the presence a passive eavesdropper during exchange of keys, 
  1473.   they do not solve all problems associated with key exchange. In
  1474.   particular, since the keys are considered `public knowledge,'
  1475.   (particularly with RSA) some other mechanism must be
  1476.   developed to testify to authenticity, because possession of keys 
  1477.   alone (sufficient to encrypt intelligible messages) is no evidence
  1478.   of a particular unique identity of the sender.
  1479.  
  1480.   One solution is to develop a key distribution mechanism that assures
  1481.   that listed keys are actually those of the given entities, sometimes
  1482.   called a `trusted authority'. The authority typically does not actually
  1483.   generate keys, but does ensure via some mechanism that the lists of 
  1484.   keys and associated identities kept and advertised for reference
  1485.   by senders and receivers are `correct'. Another method relies on users
  1486.   to distribute and track each other's keys and trust in an informal,
  1487.   distributed fashion. This has been popularized as a viable alternative
  1488.   by the PGP software which calls the model the `web of trust'.
  1489.  
  1490.   Under RSA, if a person wishes to send evidence of their identity in
  1491.   addition to an encrypted message, they simply encrypt some information
  1492.   with their private key called the `signature', additionally included in
  1493.   the message sent under the public-key encryption to the receiver. 
  1494.   The receiver can use the RSA algorithm `in reverse' to verify that the
  1495.   information decrypts sensibly, such that only the given entity could
  1496.   have encrypted the plaintext by use of the secret key. Typically the
  1497.   encrypted `signature' is a `message digest' that comprises a unique
  1498.   mathematical `summary' of the secret message (if the signature were
  1499.   static across multiple messages, once known previous receivers could 
  1500.   use it falsely). In this way, theoretically only the sender of the
  1501.   message could generate their valid signature for that message, thereby
  1502.   authenticating it for the receiver. `Digital signatures' have many 
  1503.   other design properties as described in Section 7.
  1504.  
  1505.  
  1506. 6.9. How fast can people factor numbers?
  1507.  
  1508.   It depends on the size of the numbers, and their form. Numbers
  1509.   in special forms, such as a^n - b for `small' b, are more readily
  1510.   factored through specialized techniques and not necessarily related
  1511.   to the difficulty of factoring in general. Hence a specific factoring 
  1512.   `breakthrough' for a special number form may have no practical value 
  1513.   or relevance to particular instances (and those generated for use
  1514.   in cryptographic systems are specifically `filtered' to resist such
  1515.   approaches.) The most important observation about factoring is that
  1516.   all known algorithms require an exponential amount of time in the
  1517.   _size_ of the number (measured in bits, log2(n) where `n' is the 
  1518.   number). Cryptgraphic algorithms built on the difficulty of factoring
  1519.   generally depend on this exponential-time property. (The distinction
  1520.   of `exponential' vs. `polynomial time' algorithms, or NP vs. P, is a 
  1521.   major area of active computational research, with insights very 
  1522.   closely intertwined with cryptographic security.)
  1523.   
  1524.   In October 1992 Arjen Lenstra and Dan Bernstein factored 2^523 - 1 
  1525.   into primes, using about three weeks of MasPar time. (The MasPar is 
  1526.   a 16384-processor SIMD machine; each processor can add about 200000 
  1527.   integers per second.) The algorithm there is called the ``number field 
  1528.   sieve''; it is quite a bit faster for special numbers like 2^523 - 1 
  1529.   than for general numbers n, but it takes time only 
  1530.   exp(O(log^{1/3} n log^{2/3} log n)) in any case.
  1531.  
  1532.   An older and more popular method for smaller numbers is the ``multiple
  1533.   polynomial quadratic sieve'', which takes time exp(O(log^{1/2} n
  1534.   log^{1/2} log n))---faster than the number field sieve for small n,
  1535.   but slower for large n. The breakeven point is somewhere between 100
  1536.   and 150 digits, depending on the implementations.
  1537.  
  1538.   Factorization is a fast-moving field---the state of the art just a few
  1539.   years ago was nowhere near as good as it is now. If no new methods are
  1540.   developed, then 2048-bit RSA keys will always be safe from
  1541.   factorization, but one can't predict the future. (Before the number
  1542.   field sieve was found, many people conjectured that the quadratic
  1543.   sieve was asymptotically as fast as any factoring method could be.)
  1544.  
  1545. 6.10. What about other public-key cryptosystems?
  1546.  
  1547.   We've talked about RSA because it's well known and easy to describe.
  1548.   But there are lots of other public-key systems around, many of which
  1549.   are faster than RSA or depend on problems more widely believed to be
  1550.   difficult. This has been just a brief introduction; if you really want
  1551.   to learn about the many facets of public-key cryptography, consult the
  1552.   books and journal articles listed in part 10.
  1553.  
  1554. 6.11. What is the ``RSA Factoring Challenge''?
  1555.  
  1556.   [Note: The e-mail addresses below have been reported as invalid.]
  1557.   In ~1992 the RSA Data Securities Inc., owner and licensor of multiple
  1558.   patents on the RSA hardware and public key cryptographic techniques in
  1559.   general, and maker of various software encryption packages and 
  1560.   libraries, announced on sci.math and elsewhere the creation of an 
  1561.   ongoing Factoring Challenge contest to gauge the state of the art in
  1562.   factoring technology. Every month a series of numbers are posted and
  1563.   monetary awards are given to the first respondent to break them into
  1564.   factors. Very significant hardware resources are required to succeed 
  1565.   by beating other participants. Information can be obtained via 
  1566.   automated reply from
  1567.  
  1568.     challenge-rsa-honor-roll@rsa.com
  1569.     challenge-partition-honor-roll@rsa.com
  1570.  
  1571.  
  1572. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:15 1994
  1573. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  1574. From: crypt-comments@math.ncsu.edu
  1575. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  1576. Subject: Cryptography FAQ (07/10: Digital Signatures)
  1577. Supersedes: <cryptography-faq/part07_775545033@rtfm.mit.edu>
  1578. Followup-To: poster
  1579. Date: 20 Aug 1994 16:36:41 GMT
  1580. Organization: The Crypt Cabal
  1581. Lines: 83
  1582. Approved: news-answers-request@MIT.Edu
  1583. Expires: 24 Sep 1994 16:36:22 GMT
  1584. Message-ID: <cryptography-faq/part07_777400582@rtfm.mit.edu>
  1585. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  1586. Reply-To: crypt-comments@math.ncsu.edu
  1587. NNTP-Posting-Host: bloom-picayune.mit.edu
  1588. X-Last-Updated: 1994/07/05
  1589. Originator: faqserv@bloom-picayune.MIT.EDU
  1590. Xref: ankh.iia.org sci.crypt:7651 talk.politics.crypto:4467 sci.answers:636 news.answers:9731 talk.answers:160
  1591.  
  1592. Archive-name: cryptography-faq/part07
  1593. Last-modified: 93/10/10
  1594.  
  1595. This is the seventh of ten parts of the sci.crypt FAQ. The parts are
  1596. mostly independent, but you should read the first part before the rest.
  1597. We don't have the time to send out missing parts by mail, so don't ask.
  1598. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  1599.  
  1600. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  1601. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  1602. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  1603. sci.answers, and news.answers every 21 days.
  1604.  
  1605.  
  1606.  
  1607. Contents:
  1608.  
  1609. 7.1. What is a one-way hash function?
  1610. 7.2. What is the difference between public, private, secret, shared, etc.?
  1611. 7.3. What are MD4 and MD5?
  1612. 7.4. What is Snefru?
  1613.  
  1614.  
  1615. 7.1. What is a one-way hash function?
  1616.  
  1617.   A typical one-way hash function takes a variable-length message and
  1618.   produces a fixed-length hash. Given the hash it is computationally
  1619.   impossible to find a message with that hash; in fact one can't
  1620.   determine any usable information about a message with that hash, not
  1621.   even a single bit. For some one-way hash functions it's also
  1622.   computationally impossible to determine two messages which produce the
  1623.   same hash.
  1624.  
  1625.   A one-way hash function can be private or public, just like an
  1626.   encryption function. Here's one application of a public one-way hash
  1627.   function, like MD5 or Snefru. Most public-key signature systems are
  1628.   relatively slow. To sign a long message may take longer than the user
  1629.   is willing to wait. Solution: Compute the one-way hash of the message,
  1630.   and sign the hash, which is short. Now anyone who wants to verify the
  1631.   signature can do the same thing.
  1632.  
  1633.   Another name for one-way hash function is message digest function.
  1634.  
  1635. 7.2. What is the difference between public, private, secret, shared, etc.?
  1636.  
  1637.   There is a horrendous mishmash of terminology in the literature for a
  1638.   very small set of concepts. Here are the concepts: (1) When an
  1639.   algorithm depends on a key which isn't published, we call it a private
  1640.   algorithm; otherwise we call it a public algorithm. (2) We have
  1641.   encryption functions E and decryption functions D, so that D(E(M)) = M
  1642.   for any message M. (3) We also have hashing functions H and
  1643.   verification functions V, such that V(M,X) = 1 if and only if X = H(M).
  1644.  
  1645.   A public-key cryptosystem has public encryption and private
  1646.   decryption. Checksums, such as the application mentioned in the
  1647.   previous question, have public hashing and public verification.
  1648.   Digital signature functions have private hashing and public
  1649.   verification: only one person can produce the hash for a message,
  1650.   but everyone can verify that the hash is correct.
  1651.  
  1652.   Obviously, when an algorithm depends on a private key, it's meant to
  1653.   be unusable by anyone who doesn't have the key. There's no real
  1654.   difference between a ``shared'' key and a private key: a shared key
  1655.   isn't published, so it's private. If you encrypt data for a friend
  1656.   rather than ``for your eyes only'', are you suddenly doing
  1657.   ``shared-key encryption'' rather than private-key encryption? No.
  1658.  
  1659. 7.3. What are MD4 and MD5?
  1660.  
  1661.   MD4 and MD5 are message digest functions developed by Ron Rivest.
  1662.   Definitions appear in RFC 1320 and RFC 1321 (see part 10). Code is
  1663.   available from [FTPMD].
  1664.  
  1665.   Note that a transcription error was found in the original MD5 draft
  1666.   RFC. The corrected algorithm should be called MD5a, though some
  1667.   people refer to it as MD5.
  1668.  
  1669. 7.4. What is Snefru?
  1670.  
  1671.   Snefru is a family of message digest functions developed by Ralph
  1672.   Merkle. Snefru-8 is an 8-round function, the newest in the family.
  1673.   Definitions appear in Merkle's paper [ME91a]. Code is available from
  1674.   [FTPSF].
  1675.  
  1676. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:16 1994
  1677. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  1678. From: crypt-comments@math.ncsu.edu
  1679. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  1680. Subject: Cryptography FAQ (08/10: Technical Miscellany)
  1681. Supersedes: <cryptography-faq/part08_775545033@rtfm.mit.edu>
  1682. Followup-To: poster
  1683. Date: 20 Aug 1994 16:36:43 GMT
  1684. Organization: The Crypt Cabal
  1685. Lines: 381
  1686. Approved: news-answers-request@MIT.Edu
  1687. Expires: 24 Sep 1994 16:36:22 GMT
  1688. Message-ID: <cryptography-faq/part08_777400582@rtfm.mit.edu>
  1689. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  1690. Reply-To: crypt-comments@math.ncsu.edu
  1691. NNTP-Posting-Host: bloom-picayune.mit.edu
  1692. X-Last-Updated: 1994/07/05
  1693. Originator: faqserv@bloom-picayune.MIT.EDU
  1694. Xref: ankh.iia.org sci.crypt:7652 talk.politics.crypto:4468 sci.answers:637 news.answers:9732 talk.answers:161
  1695.  
  1696. Archive-name: cryptography-faq/part08
  1697. Last-modified: 94/01/25
  1698.  
  1699.  
  1700. This is the eighth of ten parts of the sci.crypt FAQ. The parts are
  1701. mostly independent, but you should read the first part before the rest.
  1702. We don't have the time to send out missing parts by mail, so don't ask.
  1703. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  1704.  
  1705. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  1706. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  1707. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  1708. sci.answers, and news.answers every 21 days.
  1709.  
  1710.  
  1711.  
  1712. Contents
  1713.  
  1714. 8.1. How do I recover from lost passwords in WordPerfect?
  1715. 8.2. How do I break a Vigenere (repeated-key) cipher?
  1716. 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]
  1717. 8.4. Is the UNIX crypt command secure?
  1718. 8.5. How do I use compression with encryption?
  1719. 8.6. Is there an unbreakable cipher?
  1720. 8.7. What does ``random'' mean in cryptography?
  1721. 8.8. What is the unicity point (a.k.a. unicity distance)?
  1722. 8.9. What is key management and why is it important?
  1723. 8.10. Can I use pseudo-random or chaotic numbers as a key stream?
  1724. 8.11. What is the correct frequency list for English letters?
  1725. 8.12. What is the Enigma?
  1726. 8.13. How do I shuffle cards?
  1727. 8.14. Can I foil S/W pirates by encrypting my CD-ROM?
  1728. 8.15. Can you do automatic cryptanalysis of simple ciphers?
  1729. 8.16. What is the coding system used by VCR+?
  1730.  
  1731.  
  1732. 8.1. How do I recover from lost passwords in WordPerfect?
  1733.  
  1734.   WordPerfect encryption has been shown to be very easy to break.
  1735.   The method uses XOR with two repeating key streams: a typed password
  1736.   and a byte-wide counter initialized to 1+<the password length>. Full
  1737.   descriptions are given in Bennett [BEN87] and Bergen and Caelli
  1738.   [BER91].
  1739.  
  1740.   Chris Galas writes: ``Someone awhile back was looking for a way to
  1741.   decrypt WordPerfect document files and I think I have a solution. 
  1742.   There is a software company named: Accessdata (87 East 600 South,
  1743.   Orem, UT 84058), 1-800-658-5199 that has a software package that will
  1744.   decrypt any WordPerfect, Lotus 1-2-3, Quatro-Pro, MS Excel and Paradox
  1745.   files. The cost of the package is $185. Steep prices, but if you
  1746.   think your pw key is less than 10 characters, (or 10 char) give them a
  1747.   call and ask for the free demo disk. The demo disk will decrypt files
  1748.   that have a 10 char or less pw key.'' Bruce Schneier says the phone
  1749.   number for AccessData is 801-224-6970.
  1750.  
  1751. 8.2. How do I break a Vigenere (repeated-key) cipher?
  1752.  
  1753.   A repeated-key cipher, where the ciphertext is something like the
  1754.   plaintext xor KEYKEYKEYKEY (and so on), is called a Vigenere cipher.
  1755.   If the key is not too long and the plaintext is in English, do the
  1756.   following: 
  1757.  
  1758.   1. Discover the length of the key by counting coincidences.
  1759.   (See Gaines [GAI44], Sinkov [SIN66].) Trying each displacement of
  1760.   the ciphertext against itself, count those bytes which are equal. 
  1761.   If the two ciphertext portions have used the same key, something
  1762.   over 6% of the bytes will be equal. If they have used different
  1763.   keys, then less than 0.4% will be equal (assuming random 8-bit bytes
  1764.   of key covering normal ASCII text). The smallest displacement which
  1765.   indicates an equal key is the length of the repeated key.
  1766.  
  1767.   2. Shift the text by that length and XOR it with itself. This
  1768.   removes the key and leaves you with text XORed with itself. Since
  1769.   English has about 1 bit of real information per byte, 2 streams of
  1770.   text XORed together has 2 bits of info per 8-bit byte, providing
  1771.   plenty of redundancy for choosing a unique decryption. (And in fact
  1772.   one stream of text XORed with itself has just 1 bit per byte.)
  1773.  
  1774.   If the key is short, it might be even easier to treat this as a
  1775.   standard polyalphabetic substitution. All the old cryptanalysis
  1776.   texts show how to break those. It's possible with those methods, in
  1777.   the hands of an expert, if there's only ten times as much text as key.
  1778.   See, for example, Gaines [GAI44], Sinkov [SIN66].
  1779.  
  1780. 8.3. How do I send encrypted mail under UNIX? [PGP, RIPEM, PEM, ...]
  1781.  
  1782.   Here's one popular method, using the des command:
  1783.  
  1784.     cat file | compress | des private_key | uuencode | mail
  1785.  
  1786.   Meanwhile, there is a de jure Internet standard in the works called
  1787.   PEM (Privacy Enhanced Mail). It is described in RFCs 1421 through
  1788.   1424. To join the PEM mailing list, contact pem-dev-request@tis.com.
  1789.   There is a beta version of PEM being tested at the time of this
  1790.   writing.
  1791.  
  1792.   There are also two programs available in the public domain for encrypting
  1793.   mail: PGP and RIPEM. Both are available by FTP. Each has its own
  1794.   newsgroup: alt.security.pgp and alt.security.ripem. Each has its own FAQ
  1795.   as well.
  1796.  
  1797.   PGP is most commonly used outside the USA since it uses the RSA algorithm
  1798.   without a license and RSA's patent is valid only (or at least primarily)
  1799.   in the USA.
  1800.  
  1801.   RIPEM is most commonly used inside the USA since it uses the RSAREF which
  1802.   is freely available within the USA but not available for shipment outside
  1803.   the USA.
  1804.  
  1805.   Since both programs use a secret key algorithm for encrypting the body of
  1806.   the message (PGP used IDEA; RIPEM uses DES) and RSA for encrypting the
  1807.   message key, they should be able to interoperate freely. Although there
  1808.   have been repeated calls for each to understand the other's formats and
  1809.   algorithm choices, no interoperation is available at this time (as far as
  1810.   we know).
  1811.  
  1812. 8.4. Is the UNIX crypt command secure?
  1813.  
  1814.   No. See [REE84]. There is a program available called cbw (crypt
  1815.   breaker's workbench) which can be used to do ciphertext-only attacks
  1816.   on files encrypted with crypt. One source for CBW is [FTPCB].
  1817.  
  1818. 8.5. How do I use compression with encryption?
  1819.  
  1820.   A number of people have proposed doing perfect compression followed by
  1821.   some simple encryption method (e.g., XOR with a repeated key).  This
  1822.   would work, if you could do perfect compression.  Unfortunately, you can
  1823.   only compress perfectly if you know the exact distribution of possible
  1824.   inputs, and that is almost certainly not possible.
  1825.  
  1826.   Compression aids encryption by reducing the redundancy of the plaintext.
  1827.   This increases the amount of ciphertext you can send encrypted under a
  1828.   given number of key bits.  (See "unicity distance")
  1829.  
  1830.   Nearly all practical compression schemes, unless they have been designed
  1831.   with cryptography in mind, produce output that actually starts off with
  1832.   high redundancy. For example, the output of UNIX compress begins with a
  1833.   well-known three-byte ``magic number''.  This produces a field of "known
  1834.   plaintext" which can be used for some forms of cryptanalytic attack.
  1835.   Compression is generally of value, however, because it removes other
  1836.   known plaintext in the middle of the file being encrypted.  In general,
  1837.   the lower the redundancy of the plaintext being fed an encryption
  1838.   algorithm, the more difficult the cryptanalysis of that algorithm.
  1839.  
  1840.   In addition, compression shortens the input file, shortening the output
  1841.   file and reducing the amount of CPU required to do the encryption
  1842.   algorithm, so even if there were no enhancement of security, compression
  1843.   before encryption would be worthwhile.
  1844.  
  1845.   Compression after encryption is silly.  If an encryption algorithm is
  1846.   good, it will produce output which is statistically indistinguishable
  1847.   from random numbers and no compression algorithm will successfully
  1848.   compress random numbers.  On the other hand, if a compression algorithm
  1849.   succeeds in finding a pattern to compress out of an encryption's output,
  1850.   then a flaw in that algorithm has been found.
  1851.  
  1852. 8.6. Is there an unbreakable cipher?
  1853.  
  1854.   Yes. The one-time pad is unbreakable; see part 4. Unfortunately the
  1855.   one-time pad requires secure distribution of as much key material as
  1856.   plaintext.
  1857.  
  1858.   Of course, a cryptosystem need not be utterly unbreakable to be
  1859.   useful. Rather, it needs to be strong enough to resist attacks by
  1860.   likely enemies for whatever length of time the data it protects is
  1861.   expected to remain valid.
  1862.  
  1863. 8.7. What does ``random'' mean in cryptography?
  1864.  
  1865.   Cryptographic applications demand much more out of a pseudorandom
  1866.   number generator than most applications. For a source of bits to be
  1867.   cryptographically random, it must be computationally impossible to
  1868.   predict what the Nth random bit will be given complete knowledge of
  1869.   the algorithm or hardware generating the stream and the sequence of
  1870.   0th through N-1st bits, for all N up to the lifetime of the source.
  1871.  
  1872.   A software generator (also known as pseudo-random) has the function
  1873.   of expanding a truly random seed to a longer string of apparently
  1874.   random bits. This seed must be large enough not to be guessed by
  1875.   the opponent. Ideally, it should also be truly random (perhaps
  1876.   generated by a hardware random number source).
  1877.  
  1878.   Those who have Sparcstation 1 workstations could, for example,
  1879.   generate random numbers using the audio input device as a source of
  1880.   entropy, by not connecting anything to it. For example,
  1881.  
  1882.         cat /dev/audio | compress - >foo
  1883.  
  1884.   gives a file of high entropy (not random but with much randomness in
  1885.   it). One can then encrypt that file using part of itself as a key,
  1886.   for example, to convert that seed entropy into a pseudo-random
  1887.   string.
  1888.  
  1889.   When looking for hardware devices to provide this entropy, it is
  1890.   important really to measure the entropy rather than just assume that
  1891.   because it looks complicated to a human, it must be "random". For
  1892.   example, disk operation completion times sound like they might be
  1893.   unpredictable (to many people) but a spinning disk is much like a
  1894.   clock and its output completion times are relatively low in entropy.
  1895.  
  1896. 8.8. What is the unicity point (a.k.a. unicity distance)?
  1897.  
  1898.   See [SHA49]. The unicity distance is an approximation to that amount
  1899.   of ciphertext such that the sum of the real information (entropy) in
  1900.   the corresponding source text and encryption key equals the number
  1901.   of ciphertext bits used. Ciphertexts significantly longer than this
  1902.   can be shown probably to have a unique decipherment. This is used to
  1903.   back up a claim of the validity of a ciphertext-only cryptanalysis. 
  1904.   Ciphertexts significantly shorter than this are likely to have
  1905.   multiple, equally valid decryptions and therefore to gain security
  1906.   from the opponent's difficulty choosing the correct one.
  1907.  
  1908.   Unicity distance, like all statistical or information-theoretic
  1909.   measures, does not make deterministic predictions but rather gives
  1910.   probabilistic results: namely, the minimum amount of ciphertext
  1911.   for which it is likely that there is only a single intelligible
  1912.   plaintext corresponding to the ciphertext, when all possible keys
  1913.   are tried for the decryption. Working cryptologists don't normally
  1914.   deal with unicity distance as such. Instead they directly determine
  1915.   the likelihood of events of interest.
  1916.  
  1917.   Let the unicity distance of a cipher be D characters. If fewer than
  1918.   D ciphertext characters have been intercepted, then there is not
  1919.   enough information to distinguish the real key from a set of
  1920.   possible keys. DES has a unicity distance of 17.5 characters,
  1921.   which is less than 3 ciphertext blocks (each block corresponds to
  1922.   8 ASCII characters). This may seem alarmingly low at first, but
  1923.   the unicity distance gives no indication of the computational work
  1924.   required to find the key after approximately D characters have been
  1925.   intercepted.
  1926.  
  1927.   In fact, actual cryptanalysis seldom proceeds along the lines used
  1928.   in discussing unicity distance. (Like other measures such as key
  1929.   size, unicity distance is something that guarantees insecurity if
  1930.   it's too small, but doesn't guarantee security if it's high.) Few
  1931.   practical cryptosystems are absolutely impervious to analysis; all
  1932.   manner of characteristics might serve as entering ``wedges'' to crack
  1933.   some cipher messages. However, similar information-theoretic
  1934.   considerations are occasionally useful, for example, to determine a
  1935.   recommended key change interval for a particular cryptosystem.
  1936.   Cryptanalysts also employ a variety of statistical and
  1937.   information-theoretic tests to help guide the analysis in the most
  1938.   promising directions.
  1939.  
  1940.   Unfortunately, most literature on the application of information
  1941.   statistics to cryptanalysis remains classified, even the seminal
  1942.   1940 work of Alan Turing (see [KOZ84]). For some insight into the
  1943.   possibilities, see [KUL68] and [GOO83].
  1944.  
  1945. 8.9. What is key management and why is it important?
  1946.  
  1947.   One of the fundamental axioms of cryptography is that the enemy is in
  1948.   full possession of the details of the general cryptographic system,
  1949.   and lacks only the specific key data employed in the encryption. (Of
  1950.   course, one would assume that the CIA does not make a habit of telling
  1951.   Mossad about its cryptosystems, but Mossad probably finds out anyway.)
  1952.   Repeated use of a finite amount of key provides redundancy that can
  1953.   eventually facilitate cryptanalytic progress. Thus, especially in
  1954.   modern communication systems where vast amounts of information are
  1955.   transferred, both parties must have not only a sound cryptosystem but
  1956.   also enough key material to cover the traffic.
  1957.  
  1958.   Key management refers to the distribution, authentication, and
  1959.   handling of keys.
  1960.  
  1961.   A publicly accessible example of modern key management technology
  1962.   is the STU III secure telephone unit, which for classified use
  1963.   employs individual coded ``Crypto Ignition Keys'' and a central Key
  1964.   Management Center operated by NSA. There is a hierarchy in that
  1965.   certain CIKs are used by authorized cryptographic control
  1966.   personnel to validate the issuance of individual traffic keys and
  1967.   to perform installation/maintenance functions, such as the
  1968.   reporting of lost CIKs.
  1969.  
  1970.   This should give an inkling of the extent of the key management
  1971.   problem. For public-key systems, there are several related issues,
  1972.   many having to do with ``whom do you trust?''
  1973.  
  1974. 8.10. Can I use pseudo-random or chaotic numbers as a key stream?
  1975.  
  1976.   Chaotic equations and fractals produce an apparent randomness from
  1977.   relatively compact generators. Perhaps the simplest example is a
  1978.   linear congruential sequence, one of the most popular types of random
  1979.   number generators, where there is no obvious dependence between seeds
  1980.   and outputs. Unfortunately the graph of any such sequence will, in a
  1981.   high enough dimension, show up as a regular lattice. Mathematically
  1982.   this lattice corresponds to structure which is notoriously easy for
  1983.   cryptanalysts to exploit. More complicated generators have more
  1984.   complicated structure, which is why they make interesting pictures---
  1985.   but a cryptographically strong sequence will have no computable
  1986.   structure at all.
  1987.  
  1988.   See [KNU81], exercise 3.5-7; [REE77]; and [BOY89].
  1989.  
  1990. 8.11. What is the correct frequency list for English letters?
  1991.  
  1992.   There are three answers to this question, each slightly deeper than
  1993.   the one before. You can find the first answer in various books:
  1994.   namely, a frequency list computed directly from a certain sample of
  1995.   English text.
  1996.  
  1997.   The second answer is that ``the English language'' varies from author
  1998.   to author and has changed over time, so there is no definitive list.
  1999.   Of course the lists in the books are ``correctly'' computed, but
  2000.   they're all different: exactly which list you get depends on which
  2001.   sample was taken. Any particular message will have different
  2002.   statistics from those of the language as a whole.
  2003.  
  2004.   The third answer is that yes, no particular message is going to have
  2005.   exactly the same characteristics as English in general, but for all
  2006.   reasonable statistical uses these slight discrepancies won't matter.
  2007.   In fact there's an entire field called ``Bayesian statistics'' (other
  2008.   buzzwords are ``maximum entropy methods'' and ``maximum likelihood
  2009.   estimation'') which studies questions like ``What's the chance that a
  2010.   text with these letter frequencies is in English?'' and comes up with
  2011.   reasonably robust answers.
  2012.  
  2013.   So make your own list from your own samples of English text. It will
  2014.   be good enough for practical work, if you use it properly.
  2015.  
  2016. 8.12. What is the Enigma?
  2017.  
  2018.   ``For a project in data security we are looking for sources of
  2019.   information about the German Enigma code and how it was broken by
  2020.   the British during WWII.''
  2021.  
  2022.   See [WEL82], [DEA85], [KOZ84], [HOD83], [KAH91].
  2023.  
  2024. 8.13. How do I shuffle cards?
  2025.  
  2026.   Card shuffling is a special case of the permutation of an array of
  2027.   values, using a random or pseudo-random function. All possible output
  2028.   permutations of this process should be equally likely. To do this, you
  2029.   need a random function (modran(x)) which will produce a uniformly
  2030.   distributed random integer in the interval [0..x-1]. Given that
  2031.   function, you can shuffle with the following [C] code: (assuming ARRLTH
  2032.   is the length of array arr[] and swap() interchanges values at the two
  2033.   addresses given)
  2034.  
  2035.   for ( n = ARRLTH-1; n > 0 ; n-- ) swap( &arr[modran( n+1 )], &arr[n] ) ;
  2036.  
  2037.   modran(x) can not be achieved exactly with a simple (ranno() % x) since
  2038.   ranno()'s interval may not be divisible by x, although in most cases the
  2039.   error will be very small. To cover this case, one can take ranno()'s
  2040.   modulus mod x, call that number y, and if ranno() returns a value less
  2041.   than y, go back and get another ranno() value.
  2042.  
  2043.   See [KNU81] for further discussion.
  2044.  
  2045. 8.14. Can I foil S/W pirates by encrypting my CD-ROM?
  2046.  
  2047.   Someone will frequently express the desire to publish a CD-ROM with
  2048.   possibly multiple pieces of software, perhaps with each encrypted
  2049.   separately, and will want to use different keys for each user (perhaps
  2050.   even good for only a limited period of time) in order to avoid piracy.
  2051.  
  2052.   As far as we know, this is impossible, since there is nothing in standard
  2053.   PC or workstation hardware which uniquely identifies the user at the
  2054.   keyboard. If there were such an identification, then the CD-ROM could be
  2055.   encrypted with a key based in part on the one sold to the user and in
  2056.   part on the unique identifier. However, in this case the CD-ROM is one
  2057.   of a kind and that defeats the intended purpose.
  2058.  
  2059.   If the CD-ROM is to be encrypted once and then mass produced, there must
  2060.   be a key (or set of keys) for that encryption produced at some stage in
  2061.   the process. That key is useable with any copy of the CD-ROM's data.
  2062.   The pirate needs only to isolate that key and sell it along with the
  2063.   illegal copy.
  2064.  
  2065. 8.15. Can you do automatic cryptanalysis of simple ciphers?
  2066.  
  2067.   Certainly. For commercial products you can try AccessData; see
  2068.   question 8.1. We are not aware of any FTP sites for such software,
  2069.   but there are many papers on the subject. See [PEL79], [LUC88],
  2070.   [CAR86], [CAR87], [KOC87], [KOC88], [KIN92], [KIN93], [SPI93].
  2071.  
  2072. 8.16. What is the coding system used by VCR+?
  2073.  
  2074.   One very frequently asked question in sci.crypt is how the VCR+ codes
  2075.   work. The codes are used to program a VCR based on numerical input.
  2076.   See [SHI92] for an attempt to describe it.
  2077.  
  2078. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:16 1994
  2079. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  2080. From: crypt-comments@math.ncsu.edu
  2081. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  2082. Subject: Cryptography FAQ (09/10: Other Miscellany)
  2083. Supersedes: <cryptography-faq/part09_775545033@rtfm.mit.edu>
  2084. Followup-To: poster
  2085. Date: 20 Aug 1994 16:36:45 GMT
  2086. Organization: The Crypt Cabal
  2087. Lines: 178
  2088. Approved: news-answers-request@MIT.Edu
  2089. Expires: 24 Sep 1994 16:36:22 GMT
  2090. Message-ID: <cryptography-faq/part09_777400582@rtfm.mit.edu>
  2091. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  2092. Reply-To: crypt-comments@math.ncsu.edu
  2093. NNTP-Posting-Host: bloom-picayune.mit.edu
  2094. X-Last-Updated: 1994/07/05
  2095. Originator: faqserv@bloom-picayune.MIT.EDU
  2096. Xref: ankh.iia.org sci.crypt:7653 talk.politics.crypto:4469 sci.answers:638 news.answers:9733 talk.answers:162
  2097.  
  2098. Archive-name: cryptography-faq/part09
  2099. Last-modified: 94/06/07
  2100.  
  2101.  
  2102. This is the ninth of ten parts of the sci.crypt FAQ. The parts are
  2103. mostly independent, but you should read the first part before the rest.
  2104. We don't have the time to send out missing parts by mail, so don't ask.
  2105. Notes such as ``[KAH67]'' refer to the reference list in the last part.
  2106.  
  2107. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  2108. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  2109. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  2110. sci.answers, and news.answers every 21 days.
  2111.  
  2112.  
  2113. Contents:
  2114.  
  2115. 9.1. What is the National Security Agency (NSA)?
  2116. 9.2. What are the US export regulations?
  2117. 9.3. What is TEMPEST?
  2118. 9.4. What are the Beale Ciphers, and are they a hoax?
  2119. 9.5. What is the American Cryptogram Association, and how do I get in touch?
  2120. 9.6. Is RSA patented?
  2121. 9.7. What about the Voynich manuscript?
  2122.  
  2123.  
  2124. 9.1. What is the National Security Agency (NSA)?
  2125.  
  2126.   The NSA is the official communications security body of the U.S.
  2127.   government. It was given its charter by President Truman in the early
  2128.   50's, and has continued research in cryptology till the present. The 
  2129.   NSA is known to be the largest employer of mathematicians in the world,
  2130.   and is also the largest purchaser of computer hardware in the
  2131.   world. Governments in general have always been prime employers of
  2132.   cryptologists. The NSA probably possesses cryptographic expertise many
  2133.   years ahead of the public state of the art, and can undoubtedly break
  2134.   many of the systems used in practice; but for reasons of national
  2135.   security almost all information about the NSA is classified.
  2136.  
  2137.   Bamford's book [BAMFD] gives a history of the people and operations of
  2138.   the NSA. The following quote from Massey [MAS88] highlights the
  2139.   difference between public and private research in cryptography:
  2140.  
  2141.   ``... if one regards cryptology as the prerogative of government,
  2142.   one accepts that most cryptologic research will be conducted
  2143.   behind closed doors. Without doubt, the number of workers engaged
  2144.   today in such secret research in cryptology far exceeds that of
  2145.   those engaged in open research in cryptology. For only about 10
  2146.   years has there in fact been widespread open research in
  2147.   cryptology. There have been, and will continue to be, conflicts
  2148.   between these two research communities. Open research is common
  2149.   quest for knowledge that depends for its vitality on the open
  2150.   exchange of ideas via conference presentations and publications in
  2151.   scholarly journals. But can a government agency, charged with
  2152.   responsibilities of breaking the ciphers of other nations,
  2153.   countenance the publication of a cipher that it cannot break? Can
  2154.   a researcher in good conscience publish such a cipher that might
  2155.   undermine the effectiveness of his own government's code-breakers?
  2156.   One might argue that publication of a provably-secure cipher would
  2157.   force all governments to behave like Stimson's `gentlemen', but one
  2158.   must be aware that open research in cryptography is fraught with
  2159.   political and ethical considerations of a severity than in most
  2160.   scientific fields. The wonder is not that some conflicts have
  2161.   occurred between government agencies and open researchers in
  2162.   cryptology, but rather that these conflicts (at least those of which
  2163.   we are aware) have been so few and so mild.''
  2164.  
  2165. 9.2. What are the US export regulations?
  2166.  
  2167.   In a nutshell, there are two government agencies which control
  2168.   export of encryption software. One is the Bureau of Export
  2169.   Administration (BXA) in the Department of Commerce, authorized by
  2170.   the Export Administration Regulations (EAR). Another is the Office
  2171.   of Defense Trade Controls (DTC) in the State Department, authorized
  2172.   by the International Traffic in Arms Regulations (ITAR). As a rule
  2173.   of thumb, BXA (which works with COCOM) has less stringent
  2174.   requirements, but DTC (which takes orders from NSA) wants to see
  2175.   everything first and can refuse to transfer jurisdiction to BXA.
  2176.  
  2177.   The newsgroup misc.legal.computing carries many interesting
  2178.   discussions on the laws surrounding cryptographic export, what
  2179.   people think about those laws, and many other complex issues which
  2180.   go beyond the scope of technical groups like sci.crypt. Make sure to
  2181.   consult your lawyer before doing anything which will get you thrown in
  2182.   jail; if you are lucky, your lawyer might know a lawyer who has at
  2183.   least heard of the ITAR.
  2184.  
  2185. 9.3. What is TEMPEST?
  2186.  
  2187.   TEMPEST is a standard for electromagnetic shielding for computer
  2188.   equipment. It was created in response to the discovery that
  2189.   information can be read from computer radiation (e.g., from a CRT) at
  2190.   quite a distance and with little effort.
  2191.  
  2192.   Needless to say, encryption doesn't do much good if the cleartext
  2193.   is available this way.
  2194.  
  2195. 9.4. What are the Beale Ciphers, and are they a hoax?
  2196.  
  2197.   (Thanks to Jim Gillogly for this information and John King for
  2198.   corrections.)
  2199.  
  2200.   The story in a pamphlet by J. B. Ward (1885) goes: Thomas
  2201.   Jefferson Beale and a party of adventurers accumulated a huge mass
  2202.   of treasure and buried it in Bedford County, Virginia, leaving
  2203.   three ciphers with an innkeeper; the ciphers describe the
  2204.   location, contents, and intended beneficiaries of the treasure.
  2205.   Ward gives a decryption of the second cipher (contents) called B2;
  2206.   it was encrypted as a book cipher using the initial letters of the
  2207.   Declaration of Independence (DOI) as key. B1 and B3 are unsolved;
  2208.   many documents have been tried as the key to B1.
  2209.  
  2210.   Aficionados can join a group that attempts to solve B1 by various
  2211.   means with an eye toward splitting the treasure:
  2212.  
  2213.   The Beale Cypher Association
  2214.   P.O. Box 975
  2215.   Beaver Falls, PA 15010
  2216.  
  2217.   You can get the ciphers from the rec.puzzles FAQL by including the
  2218.   line:
  2219.  
  2220.   send index
  2221.  
  2222.   in a message to netlib@peregrine.com and following the directions.
  2223.   (There are apparently several different versions of the cipher
  2224.   floating around. The correct version is based on the 1885 pamphlet,
  2225.   says John King <kingj@hpcc01.corp.hp.com>.)
  2226.  
  2227.   Some believe the story is a hoax. Kruh [KRU88] gives a long list of
  2228.   problems with the story. Gillogly [GIL80] decrypted B1 with the DOI
  2229.   and found some unexpected strings, including ABFDEFGHIIJKLMMNOHPP.
  2230.   Hammer (president of the Beale Cypher Association) agrees that this
  2231.   string couldn't appear by chance, but feels there must be an
  2232.   explanation; Gwyn (sci.crypt expert) is unimpressed with this
  2233.   string.
  2234.  
  2235. 9.5. What is the American Cryptogram Association, and how do I get in touch?
  2236.  
  2237.   The ACA is an organization devoted to cryptography, with an emphasis
  2238.   on cryptanalysis of systems that can be attacked either with
  2239.   pencil-and-paper or computers. Its organ ``The Cryptogram'' includes
  2240.   articles and challenge ciphers. Among the more than 50 cipher types in
  2241.   English and other languages are simple substitution, Playfair,
  2242.   Vigenere, bifid, Bazeries, grille, homophonic, and cryptarithm.
  2243.  
  2244.   Dues are $20 per year (6 issues) for new members, $15 thereafter; more
  2245.   outside North America; less for students under 18 and seniors.  Send
  2246.   checks to ACA Treasurer, P.O. Box 198, Vernon Hills, IL 60061-0198.
  2247.  
  2248. 9.6. Is RSA patented?
  2249.  
  2250.   Yes. The patent number is 4,405,829, filed 12/14/77, granted 9/20/83.
  2251.   For further discussion of this patent, whether it should have been
  2252.   granted, algorithm patents in general, and related legal and moral
  2253.   issues, see comp.patents and misc.legal.computing. For information
  2254.   about the League for Programming Freedom see [FTPPF]. Note that one of
  2255.   the original purposes of comp.patents was to collect questions such as
  2256.   ``should RSA be patented?'', which often flooded sci.crypt and other
  2257.   technical newsgroups, into a more appropriate forum.
  2258.  
  2259. 9.7. What about the Voynich manuscript?
  2260.  
  2261.   The Voynich manuscript is an elaborately lettered and illustrated
  2262.   document, in a script never deciphered. It has been handed down for
  2263.   centuries by a line of art collectors and has uncertain origination.
  2264.   Much speculation and attention has been focused on its potential
  2265.   meaning.
  2266.  
  2267.   nelson@reed.edu (Nelson Minar) says there is a mailing list on the
  2268.   subject. The address to write to subscribe to the VMS mailing list
  2269.   is: <voynich-request@rand.org>
  2270.  
  2271.   the ftp archive is: rand.org:/pub/voynich
  2272.  
  2273.   There's all sorts of information about the manuscript itself, of
  2274.   course. A good bibliography can be found on the ftp site. [KAH67]
  2275.   gives a good introduction.
  2276.  
  2277. From ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv Sun Aug 28 10:03:16 1994
  2278. Path: ankh.iia.org!uunet!spool.mu.edu!bloom-beacon.mit.edu!senator-bedfellow.mit.edu!faqserv
  2279. From: crypt-comments@math.ncsu.edu
  2280. Newsgroups: sci.crypt,talk.politics.crypto,sci.answers,news.answers,talk.answers
  2281. Subject: Cryptography FAQ (10/10: References)
  2282. Supersedes: <cryptography-faq/part10_775545033@rtfm.mit.edu>
  2283. Followup-To: poster
  2284. Date: 20 Aug 1994 16:36:48 GMT
  2285. Organization: The Crypt Cabal
  2286. Lines: 380
  2287. Approved: news-answers-request@MIT.Edu
  2288. Expires: 24 Sep 1994 16:36:22 GMT
  2289. Message-ID: <cryptography-faq/part10_777400582@rtfm.mit.edu>
  2290. References: <cryptography-faq/part01_777400582@rtfm.mit.edu>
  2291. Reply-To: crypt-comments@math.ncsu.edu
  2292. NNTP-Posting-Host: bloom-picayune.mit.edu
  2293. X-Last-Updated: 1994/07/05
  2294. Originator: faqserv@bloom-picayune.MIT.EDU
  2295. Xref: ankh.iia.org sci.crypt:7654 talk.politics.crypto:4470 sci.answers:639 news.answers:9734 talk.answers:163
  2296.  
  2297. Archive-name: cryptography-faq/part10
  2298. Last-modified: 94/06/13
  2299.  
  2300.  
  2301. This is the tenth of ten parts of the sci.crypt FAQ. The parts are
  2302. mostly independent, but you should read the first part before the rest.
  2303. We don't have the time to send out missing parts by mail, so don't ask.
  2304. Notes such as ``[KAH67]'' refer to the reference list in this part.
  2305.  
  2306. The sections of this FAQ are available via anonymous FTP to rtfm.mit.edu 
  2307. as /pub/usenet/news.answers/cryptography-faq/part[xx]. The Cryptography 
  2308. FAQ is posted to the newsgroups sci.crypt, talk.politics.crypto, 
  2309. sci.answers, and news.answers every 21 days.
  2310.  
  2311.  
  2312.  
  2313. Contents
  2314.  
  2315. 10.1. Books on history and classical methods
  2316. 10.2. Books on modern methods
  2317. 10.3. Survey articles
  2318. 10.4. Reference articles
  2319. 10.5. Journals, conference proceedings
  2320. 10.6. Other
  2321. 10.7. How may one obtain copies of FIPS and ANSI standards cited herein?
  2322. 10.8. Electronic sources
  2323. 10.9. RFCs (available from [FTPRF])
  2324. 10.10. Related newsgroups
  2325.  
  2326.  
  2327. 10.1. Books on history and classical methods
  2328.  
  2329.   [FRIE1] Lambros D. Callimahos, William F. Friedman, Military Cryptanalytics.
  2330.           Aegean Park Press, ?.
  2331.   [DEA85] Cipher A. Deavours & Louis Kruh, Machine Cryptography and
  2332.           Modern Cryptanalysis. Artech House, 610 Washington St.,
  2333.           Dedham, MA 02026, 1985.
  2334.   [FRIE2] William F. Friedman, Solving German Codes in World War I.
  2335.           Aegean Park Press, ?.
  2336.   [GAI44] H. Gaines, Cryptanalysis, a study of ciphers and their
  2337.           solution. Dover Publications, 1944.
  2338.   [HIN00] F.H.Hinsley, et al., British Intelligence in the Second
  2339.           World War. Cambridge University Press. (vol's 1, 2, 3a, 3b
  2340.           & 4, so far). XXX Years and authors, fix XXX
  2341.   [HOD83] Andrew Hodges, Alan Turing: The Enigma. Burnett Books
  2342.           Ltd., 1983
  2343.   [KAH91] David Kahn, Seizing the Enigma. Houghton Mifflin, 1991.
  2344.   [KAH67] D. Kahn, The Codebreakers. Macmillan Publishing, 1967.
  2345.           [history] [The abridged paperback edition left out most
  2346.           technical details; the original hardcover edition is
  2347.           recommended.]
  2348.   [KOZ84] W. Kozaczuk, Enigma. University Publications of America, 1984
  2349.   [KUL76] S. Kullback, Statistical Methods in Cryptanalysis. Aegean
  2350.           Park Press, 1976.
  2351.   [SIN66] A. Sinkov, Elementary Cryptanalysis. Math. Assoc. Am. 1966.
  2352.   [WEL82] Gordon Welchman, The Hut Six Story. McGraw-Hill, 1982.
  2353.   [YARDL] Herbert O. Yardley, The American Black Chamber. Aegean Park
  2354.           Press, ?.
  2355.  
  2356. 10.2. Books on modern methods
  2357.  
  2358.   [BEK82] H. Beker, F. Piper, Cipher Systems. Wiley, 1982.
  2359.   [BRA88] G. Brassard, Modern Cryptology: a tutorial.
  2360.           Spinger-Verlag, 1988.
  2361.   [DEN82] D. Denning, Cryptography and Data Security. Addison-Wesley
  2362.           Publishing Company, 1982.
  2363.   [KOB89] N. Koblitz, A course in number theory and cryptography.
  2364.           Springer-Verlag, 1987.
  2365.   [KON81] A. Konheim, Cryptography: a primer. Wiley, 1981.
  2366.   [MEY82] C. Meyer and S. Matyas, Cryptography: A new dimension in
  2367.           computer security. Wiley, 1982.
  2368.   [PAT87] Wayne Patterson, Mathematical Cryptology for Computer
  2369.           Scientists and Mathematicians. Rowman & Littlefield, 1987.
  2370.   [PFL89] C. Pfleeger, Security in Computing. Prentice-Hall, 1989.
  2371.   [PRI84] W. Price, D. Davies, Security for computer networks. Wiley, 1984. 
  2372.   [RUE86] R. Rueppel, Design and Analysis of Stream Ciphers.
  2373.           Springer-Verlag, 1986.
  2374.   [SAL90] A. Saloma, Public-key cryptography. Springer-Verlag, 1990.
  2375.   [SCH94] B. Schneier, Applied Cryptography. John Wiley & Sons, 1994.
  2376.       [errata avbl from schneier@chinet.com]
  2377.   [WEL88] D. Welsh, Codes and Cryptography. Claredon Press, 1988.
  2378.  
  2379. 10.3. Survey articles
  2380.  
  2381.   [ANG83] D. Angluin, D. Lichtenstein, Provable Security in Crypto-
  2382.           systems: a survey. Yale University, Department of Computer
  2383.           Science, #288, 1983.
  2384.   [BET90] T. Beth, Algorithm engineering for public key algorithms.
  2385.           IEEE Selected Areas of Communication, 1(4), 458--466,
  2386.           1990.
  2387.   [DAV83] M. Davio, J. Goethals, Elements of cryptology. in Secure
  2388.           Digital Communications, G. Longo ed., 1--57, 1983.
  2389.   [DIF79] W. Diffie, M. Hellman, Privacy and Authentication: An
  2390.           introduction to cryptography. IEEE proceedings, 67(3),
  2391.           397--427, 1979.
  2392.   [DIF88] W. Diffie, The first ten years of public key cryptography.
  2393.           IEEE proceedings, 76(5), 560--577, 1988.
  2394.   [FEI73] H. Feistel, Cryptography and Computer Privacy. Scientific 
  2395.           American, 228(5), 15--23, 1973.
  2396.   [FEI75] H. Feistel, H, W. Notz, J. Lynn Smith. Some cryptographic
  2397.           techniques for machine-to-machine data communications,
  2398.           IEEE IEEE proceedings, 63(11), 1545--1554, 1975.
  2399.   [HEL79] M. Hellman, The mathematics of public key cryptography.
  2400.           Scientific American, 130--139, 1979.
  2401.   [LAK83] S. Lakshmivarahan, Algorithms for public key
  2402.           cryptosystems. In Advances in Computers, M. Yovtis ed.,
  2403.           22, Academic Press, 45--108, 1983.
  2404.   [LEM79] A. Lempel, Cryptology in transition, Computing Surveys,
  2405.           11(4), 285--304, 1979.
  2406.   [MAS88] J. Massey, An introduction to contemporary cryptology, IEEE
  2407.           proceedings, 76(5), 533--549, 1988.
  2408.   [SIM91] G. Simmons (ed.), Contemporary Cryptology: the Science of
  2409.           Information Integrity. IEEE press, 1991.
  2410.  
  2411. 10.4. Reference articles
  2412.  
  2413.   [AND83] D. Andelman, J. Reeds, On the cryptanalysis of rotor and
  2414.           substitution-permutation networks. IEEE Trans. on Inform.
  2415.           Theory, 28(4), 578--584, 1982.
  2416.   [BEN87] John Bennett, Analysis of the Encryption Algorithm Used in
  2417.           the WordPerfect Word Processing Program. Cryptologia 11(4),
  2418.           206--210, 1987.
  2419.   [BER91] H. A. Bergen and W. J. Caelli, File Security in WordPerfect
  2420.           5.0. Cryptologia 15(1), 57--66, January 1991.
  2421.   [BIH91] E. Biham and A. Shamir, Differential cryptanalysis of
  2422.           DES-like cryptosystems. Journal of Cryptology, vol. 4, #1,
  2423.           3--72, 1991.
  2424.   [BI91a] E. Biham, A. Shamir, Differential cryptanalysis of Snefru,
  2425.           Khafre, REDOC-II, LOKI and LUCIFER. In Proceedings of CRYPTO
  2426.           '91, ed. by J. Feigenbaum, 156--171, 1992.
  2427.   [BOY89] J. Boyar, Inferring Sequences Produced by Pseudo-Random
  2428.           Number Generators. Journal of the ACM, 1989.
  2429.   [BRI86] E. Brickell, J. Moore, M. Purtill, Structure in the
  2430.           S-boxes of DES. In Proceedings of CRYPTO '86, A. M. Odlyzko
  2431.           ed., 3--8, 1987.
  2432.   [BRO89] L. Brown, A proposed design for an extended DES, Computer
  2433.           Security in the Computer Age. Elsevier Science Publishers
  2434.           B.V. (North Holland), IFIP, W. J. Caelli ed., 9--22, 1989.
  2435.   [BRO90] L. Brown, J. Pieprzyk, J. Seberry, LOKI - a cryptographic
  2436.           primitive for authentication and secrecy applications.
  2437.           In Proceedings of AUSTCRYPT 90, 229--236, 1990.
  2438.   [CAE90] H. Gustafson, E. Dawson, W. Caelli, Comparison of block
  2439.           ciphers. In Proceedings of AUSCRYPT '90, J. Seberry and J.
  2440.           Piepryzk eds., 208--220, 1990.
  2441.   [CAM93] K. W. Campbell, M. J. Wiener, Proof the DES is Not a Group.
  2442.           In Proceedings of CRYPTO '92, 1993.
  2443.   [CAR86] John Carrol and Steve Martin, The Automated Cryptanalysis
  2444.           of Substitution Ciphers. Cryptologia 10(4), 193--209, 1986.
  2445.   [CAR87] John Carrol and Lynda Robbins, Automated Cryptanalysis of
  2446.           Polyalphabetic Ciphers. Cryptologia 11(4), 193--205, 1987.
  2447.   [ELL88] Carl M. Ellison, A Solution of the Hebern Messages. Cryptologia,
  2448.           vol. XII, #3, 144-158, Jul 1988.
  2449.   [EVE83] S. Even, O. Goldreich, DES-like functions can generate the
  2450.           alternating group. IEEE Trans. on Inform. Theory, vol. 29,
  2451.           #6, 863--865, 1983.
  2452.   [GAR91] G. Garon, R. Outerbridge, DES watch: an examination of the
  2453.           sufficiency of the Data Encryption Standard for financial
  2454.           institutions in the 1990's. Cryptologia, vol. XV, #3,
  2455.           177--193, 1991.
  2456.   [GIL80] Gillogly, ?. Cryptologia 4(2), 1980.
  2457.   [GM82]  Shafi Goldwasser, Silvio Micali, Probabilistic Encryption and
  2458.           How To Play Mental Poker Keeping Secret All Partial Information.
  2459.           Proceedings of the Fourteenth Annual ACM Symposium on Theory of
  2460.           Computing, 1982.
  2461.   [HUM83] D. G. N. Hunter and A. R. McKenzie, Experiments with
  2462.           Relaxation Algorithms for Breaking Simple Substitution
  2463.           Ciphers. Computer Journal 26(1), 1983.
  2464.   [KAM78] J. Kam, G. Davida, A structured design of substitution-
  2465.           permutation encryption networks. IEEE Trans. Information
  2466.           Theory, 28(10), 747--753, 1978.
  2467.   [KIN78] P. Kinnucan, Data encryption gurus: Tuchman and Meyer.
  2468.           Cryptologia, vol. II #4, 371--XXX, 1978.
  2469.   [KIN92] King and Bahler, Probabilistic Relaxation in the
  2470.           Cryptanalysis of Simple Substitution Ciphers. Cryptologia
  2471.           16(3), 215--225, 1992.
  2472.   [KIN93] King and Bahler, An Algorithmic Solution of Sequential
  2473.           Homophonic Ciphers. Cryptologia 17(2), in press.
  2474.   [KOC87] Martin Kochanski, A Survey of Data Insecurity Packages.
  2475.           Cryptologia 11(1), 1--15, 1987.
  2476.   [KOC88] Martin Kochanski, Another Data Insecurity Package.
  2477.           Cryptologia 12(3), 165--177, 1988.
  2478.   [KRU88] Kruh, ?. Cryptologia 12(4), 1988.
  2479.   [LAI90] X. Lai, J. Massey, A proposal for a new block encryption 
  2480.           standard. EUROCRYPT 90, 389--404, 1990.
  2481.   [LUB88] C. Rackoff, M. Luby, How to construct psuedorandom
  2482.           permutations from psuedorandom functions. SIAM Journal of
  2483.           Computing, vol. 17, #2, 373--386, 1988.
  2484.   [LUC88] Michael Lucks, A Constraint Satisfaction Algorithm for the
  2485.           Automated Decryption of Simple Substitution Ciphers. In
  2486.           CRYPTO '88.
  2487.   [MAS88] J. Massey, An introduction to contemporary cryptology.
  2488.           IEEE proceedings, 76(5), 533--549, 1988.
  2489.   [ME91a] R. Merkle, Fast software encryption functions. In Proceedings
  2490.           of CRYPTO '90, Menezes and Vanstone ed., 476--501, 1991.
  2491.   [MEY78] C. Meyer, Ciphertext/plaintext and ciphertext/key
  2492.           dependence vs. number of rounds for the Data Encryption
  2493.           Standard. AFIPS Conference proceedings, 47, 1119--1126,
  2494.           1978.
  2495.   [NBS77] Data Encryption Standard. National Bureau of Standards,
  2496.           FIPS PUB 46, Washington, DC, January 1977.
  2497.   [PEL79] S. Peleg and A. Rosenfeld, Breaking Substitution Ciphers
  2498.           Using a Relaxation Algorithm. CACM 22(11), 598--605, 1979.
  2499.   [REE77] J. Reeds, `Cracking' a Random Number Generator.
  2500.           Cryptologia 1(1), 20--26, 1977.
  2501.   [REE84] J. A. Reeds and P. J. Weinberger, File Security and the UNIX
  2502.           Crypt Command. AT&T Bell Laboratories Technical Journal,
  2503.           Vol. 63 #8, part 2, 1673--1684, October, 1984.
  2504.   [SHA49] C. Shannon, Communication Theory of Secrecy Systems. Bell
  2505.           System Technical Journal 28(4), 656--715, 1949.
  2506.   [SHE88] B. Kaliski, R. Rivest, A. Sherman, Is the Data Encryption
  2507.           Standard a Group. Journal of Cryptology, vol. 1, #1,
  2508.           1--36, 1988.
  2509.   [SHI88] A. Shimizu, S. Miyaguchi, Fast data encipherment algorithm
  2510.           FEAL. EUROCRYPT '87, 267--278, 1988.
  2511.   [SHI92] K. Shirriff, C. Welch, A. Kinsman, Decoding a VCR Controller
  2512.           Code. Cryptologia 16(3), 227--234, 1992.
  2513.   [SOR84] A. Sorkin, LUCIFER: a cryptographic algorithm.
  2514.           Cryptologia, 8(1), 22--35, 1984.
  2515.   [SPI93] R. Spillman et al., Use of Genetic Algorithms in
  2516.           Cryptanalysis of Simple Substitution Ciphers. Cryptologia
  2517.           17(1), 31--44, 1993.
  2518.         
  2519. 10.5. Journals, conference proceedings
  2520.  
  2521.   CRYPTO
  2522.   Eurocrypt
  2523.   IEEE Transactions on Information Theory
  2524.   Cryptologia: a cryptology journal, quarterly since Jan 1977.
  2525.           Cryptologia; Rose-Hulman Institute of Technology; Terre Haute
  2526.           Indiana 47803 [general: systems, analysis, history, ...]
  2527.   Journal of Cryptology; International Association for Cryptologic
  2528.           Research; published by Springer Verlag (quarterly since
  2529.           1988).
  2530.   The Cryptogram (Journal of the American Cryptogram Association);
  2531.           18789 West Hickory Street; Mundelein, IL 60060; [primarily
  2532.           puzzle cryptograms of various sorts]
  2533.   Cryptosystems Journal, Published by Tony Patti, P.O. Box 188,
  2534.           Newtown PA, USA 18940-0188 or tony_s_patti@cup.portal.com.
  2535.           Publisher's comment: Includes complete cryptosystems with
  2536.           source and executable programs on diskettes. Tutorial. The
  2537.           typical cryptosystems supports multi-megabit keys and Galois
  2538.           Field arithmetic. Inexpensive hardware random number
  2539.           generator details.
  2540.   Computer and Communication Security Reviews, published by Ross Anderson.
  2541.           Sample issue available from various ftp sites, including
  2542.           black.ox.ac.uk. Editorial c/o rja14@cl.cam.ac.uk. Publisher's
  2543.           comment: We review all the conference proceedings in this field,
  2544.           including not just Crypto and Eurocrypt, but regional gatherings
  2545.           like Auscrypt and Chinacrypt. We also abstract over 50 journals,
  2546.           and cover computer security as well as cryptology, so readers can
  2547.           see the research trends in applications as well as theory.
  2548.   Infosecurity News, MIS Training Institute Press, Inc. 498 Concord Street
  2549.           Framingham MA 01701-2357. This trade journal is oriented toward 
  2550.           administrators and covers viruses, physical security, hackers, 
  2551.           and so on more than cryptology. Furthermore, most of the articles 
  2552.           are written by vendors and hence are biased.  Nevertheless, there 
  2553.           are occasionally some rather good cryptography articles.
  2554.  
  2555. 10.6. Other
  2556.  
  2557.   Address of note: Aegean Park Press, P.O. Box 2837, Laguna Hills, CA
  2558.   92654-0837. Answering machine at 714-586-8811.  Toll Free at 800 736-
  2559.   3587, and FAX at 714 586-8269.
  2560.  
  2561.   The ``Orange Book'' is DOD 5200.28-STD, published December 1985 as
  2562.   part of the ``rainbow book'' series. Write to Department of Defense,
  2563.   National Security Agency, ATTN: S332, 9800 Savage Road, Fort Meade, MD
  2564.   20755-6000, and ask for the Trusted Computer System Evaluation
  2565.   Criteria. Or call 301-766-8729.
  2566.  
  2567.   The ``Orange Book'' will eventually be replaced by the U.S. Federal 
  2568.   Criteria for Information Technology Security (FC) online at the NIST
  2569.   site [FTPNS], which also contains information on other various proposed 
  2570.   and active federal standards.
  2571.  
  2572.   [BAMFD] Bamford, The Puzzle Palace. Penguin Books, 1982.
  2573.   [GOO83] I. J. Good, Good Thinking: the foundations of probability and
  2574.           its applications. University of Minnesota Press, 1983.
  2575.   [KNU81] D. E. Knuth, The Art of Computer Programming, volume 2:
  2576.           Seminumerical Algorithms. Addison-Wesley, 1981.
  2577.   [KUL68] Soloman Kullback, Information Theory and Statistics.
  2578.           Dover, 1968.
  2579.   [YAO88] A. Yao, Computational Information Theory. In Complexity in
  2580.           Information Theory, ed. by Abu-Mostafa, 1988.
  2581.  
  2582. 10.7. How may one obtain copies of FIPS and ANSI standards cited herein?
  2583.  
  2584.   Many textbooks on cryptography contain complete reprints of the FIPS
  2585.   standards, which are not copyrighted.
  2586.  
  2587.   The following standards may be ordered from the
  2588.       U.S. Department of Commerce, National Technical Information Service,
  2589.       Springfield, VA 22161.
  2590.  
  2591.       FIPS PUB 46-1 Data Encryption Standard  (this is DES)
  2592.       FIPS PUB 74   Guidelines for Implementing as Using the NBS DES
  2593.       FIPS PUB 81   DES Modes of Operation
  2594.       FIPS PUB 113  Computer Data Authentication (using DES)
  2595.  
  2596.   [Note: The address below has been reported as invalid.]
  2597.   The following standards may be ordered from the
  2598.       American National Standards Institute Sales Office,
  2599.       1430 Broadway, New York, NY 10018.
  2600.       Phone 212.642.4900
  2601.  
  2602.       ANSI X3.92-1981  Data Encryption Algorithm (identical to FIPS 46-1)
  2603.       ANSI X3.106-1983 DEA Modes of Operation    (identical to FIPS 113)
  2604.  
  2605.   Notes:  Figure 3 in FIPS PUB 46-1 is in error, but figure 3 in X3.92-1981
  2606.       is correct. The text is correct in both publications.
  2607.  
  2608.  
  2609. 10.8. Electronic sources
  2610.  
  2611.   Anonymous ftp:
  2612.  
  2613.   [FTPAL] kampi.hut.fi:alo/des-dist.tar.Z
  2614.   [FTPBK] ftp.uu.net:bsd-sources/usr.bin/des/
  2615.   [FTPCB] ftp.uu.net:usenet/comp.sources.unix/volume10/cbw/
  2616.   [FTPCP] soda.berkeley.edu:/pub/cypherpunks
  2617.   [FTPDF] ftp.funet.fi:pub/unix/security/destoo.tar.Z
  2618.   [FTPDQ] rsa.com:pub/faq/
  2619.   [FTPEY] ftp.psy.uq.oz.au:pub/DES/
  2620.   [FTPMD] rsa.com:?
  2621.   [FTPMR] ripem.msu.edu:pub/crypt/newdes.tar.Z
  2622.   [FTPNS] csrc.nist.gov:/bbs/nistpubs
  2623.   [FTPOB] ftp.3com.com:Orange-Book
  2624.   [FTPPF] prep.ai.mit.edu:pub/lpf/
  2625.   [FTPPK] ucsd.edu:hamradio/packet/tcpip/crypto/des.tar.Z
  2626.   [FTPPX] ripem.msu.edu:pub/crypt/other/tran-and-prngxor.shar
  2627.   [FTPRF] nic.merit.edu:documents/rfc/
  2628.   [FTPSF] beta.xerox.com:pub/hash/
  2629.   [FTPSO] chalmers.se:pub/unix/des/des-2.2.tar.Z
  2630.   [FTPTR] ripem.msu.edu:pub/crypt/other/tran-and-prngxor.shar
  2631.   [FTPUF] ftp.uu.net:usenet/comp.sources.unix/volume28/ufc-crypt/
  2632.   [FTPWP] garbo.uwasa.fi:pc/util/wppass2.zip
  2633.  
  2634.   World Wide Web pages:
  2635.  
  2636.   [WWWQC] http://www.quadralay.com/www/Crypt/Crypt.html
  2637.           Quadralay Cryptography archive
  2638.   [WWWVC] ftp://furmint.nectar.cs.cmu.edu/security/README.html
  2639.           Vince Cate's Cypherpunk Page 
  2640.  
  2641. 10.9. RFCs (available from [FTPRF])
  2642.  
  2643.   [1424]  B. Kaliski, Privacy Enhancement for Internet Electronic Mail:
  2644.           Part IV: Key Certification and Related Services. RFC 1424,
  2645.           February 1993.
  2646.   [1423]  D. Balenson, Privacy Enhancement for Internet Electronic Mail:
  2647.           Part III: Algorithms, Modes, and Identifiers. RFC 1423,
  2648.           February 1993.
  2649.   [1422]  S. Kent, Privacy Enhancement for Internet Electronic Mail:
  2650.           Part II: Certificate-Based Key Management. RFC 1422, February
  2651.           1993.
  2652.   [1421]  J. Linn, Privacy Enhancement for Internet Electronic Mail:
  2653.           Part I: Message Encryption and Authentication Procedures. RFC
  2654.           1421, February 1993.
  2655.  
  2656. 10.10. Related newsgroups
  2657.  
  2658.   There are other newsgroups which a sci.crypt reader might want also to
  2659.   read. Some have their own FAQs as well.
  2660.  
  2661.   alt.privacy.clipper           Clipper, Capstone, Skipjack, Key Escrow
  2662.   alt.security                  general security discussions
  2663.   alt.security.index            index to alt.security
  2664.   alt.security.pgp              discussion of PGP
  2665.   alt.security.ripem            discussion of RIPEM
  2666.   alt.society.civil-liberty     general civil liberties, including privacy
  2667.   comp.compression              discussion of compression algorithms and code
  2668.   comp.org.eff.news             News reports from EFF
  2669.   comp.org.eff.talk             discussion of EFF related issues
  2670.   comp.patents                  discussion of S/W patents, including RSA
  2671.   comp.risks                    some mention of crypto and wiretapping
  2672.   comp.society.privacy          general privacy issues
  2673.   comp.security.announce        announcements of security holes
  2674.   misc.legal.computing          software patents, copyrights, computer laws
  2675.   sci.math                      general math discussion
  2676.   talk.politics.crypto        politics of cryptography
  2677.  
  2678.