home *** CD-ROM | disk | FTP | other *** search
/ Chaos Computer Club 1997 February / cccd_beta_feb_97.iso / contrib / faq / crypto / snakeoil.txt < prev   
Text File  |  1997-02-28  |  31KB  |  654 lines

  1. Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!news.bbnplanet.com!cam-news-hub1.bbnplanet.com!howland.erols.net!feed1.news.erols.com!news.magicnet.net!news.sprintlink.net!news-atl-21.sprintlink.net!news.sprintlink.net!news-pull.sprintlink.net!news.sprintlink.net!news-dc-9.sprintlink.net!news2.ee.net!usenet
  2. From: C Matthew Curtin <cmcurtin@research.megasoft.com>
  3. Newsgroups: sci.crypt,alt.security,comp.security,comp.infosystems,comp.answers,sci.answers,alt.answers,news.answers
  4. Subject: Avoiding bogus encryption products: Snake Oil FAQ
  5. Followup-To: poster
  6. Date: 12 Jan 1997 09:27:40 -0500
  7. Organization: Megasoft Research
  8. Lines: 636
  9. Sender: cmcurtin@goffette.research.megasoft.com
  10. Approved: news-answers-request@MIT.EDU
  11. Message-ID: <864tgndl43.fsf@goffette.research.megasoft.com>
  12. NNTP-Posting-Host: gw.research.megasoft.com
  13. Summary: Identifying and avoiding weak cryptography products.
  14. Original-Sender: cmcurtin@research.megasoft.com
  15. X-Face: "&>g(&eGr?u^F:nFihL%BsyS1[tCqG7}I2rGk4{aKJ5I_5A\*6RYn4"N.`1pPF9LO!Fa<(gj:12)?=uP2l01e10Gij"7j&-)torL^iBrNf\s7PDLm=rf[PjxtSbZ{J(@@j"q2/iV9^Mx<e%nT[:7s7.-#u*}GAH,bEfbfh-NDqSG`+s
  16. X-Newsreader: Gnus v5.2.25/XEmacs 19.14
  17. Xref: senator-bedfellow.mit.edu sci.crypt:60073 alt.security:41657 comp.infosystems:9202 comp.answers:23614 sci.answers:5730 alt.answers:23180 news.answers:91784
  18.  
  19. URL: http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.html
  20. Version: 1.3
  21. Archive-name: cryptography-faq/snake-oil
  22. Posting-Frequency: monthly
  23.  
  24.                           Snake Oil Warning Signs:
  25.                         Encryption Software to Avoid
  26.  
  27. $Id: snake-oil-faq.html,v 1.3 1997/01/11 21:59:12 cmcurtin Exp $
  28.  
  29.                       Copyright ⌐1996, 1997 Matt Curtin
  30.  
  31. Contents
  32.  
  33.  
  34.    * Obligatory Administrativia
  35.         o Distribution
  36.         o Disclaimer
  37.         o Document History
  38.         o Contributors
  39.    * Introduction
  40.    * Basic Concepts
  41.         o Symmetric vs. Asymmetric Cryptography
  42.         o Secrecy vs. Integrity: What are you trying to protect?
  43.         o Key Sizes
  44.         o Keys vs. Passphrases
  45.         o Implementation Environment
  46.    * Snake Oil Warning Signs
  47.         o ``Trust Us, We Know What We're Doing''
  48.         o Technobabble
  49.         o Secret Algorithms
  50.         o Revolutionary Breakthroughs
  51.         o Experienced Security Experts, Rave Reviews, and Other Useless
  52.           Certificates
  53.         o Excessively Large Keys
  54.         o Unbreakability
  55.         o One-Time-Pads
  56.         o Algorithm or product X is insecure
  57.         o Recoverable Keys
  58.         o Exportable from the USA
  59.         o ``Military Grade''
  60.    * Other Considerations
  61.    * Glossary
  62.    * References
  63.  
  64. Obligatory Administrativia
  65.  
  66. Distribution
  67.  
  68. Distribution of this document is unlimited. We're specifically trying to
  69. reach people who are not experts in cryptography or security but find
  70. themselves making decisions about what sorts of crypto (if any) to use, both
  71. for their organizations and for themselves.
  72.  
  73. The Snake Oil FAQ is posted monthly to sci.crypt, alt.security,
  74. comp.security, comp.answers, and comp.infosystems. It is available in
  75. PostScript form (ideal for printing) via the web at
  76.  
  77.      http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.ps
  78.  
  79. and HTML at
  80.  
  81.      http://www.research.megasoft.com/people/cmcurtin/snake-oil-faq.html
  82.  
  83. Disclaimer
  84.  
  85. All contributors' employers will no doubt disown any statements herein.
  86. We're not speaking for anyone but ourselves.
  87.  
  88. This is a compilation of common habits of snake oil vendors. It cannot be
  89. the sole method of rating a security product, since there can be exceptions
  90. to most of these rules. From time to time, a reputable vendor will produce
  91. something that is actually quite good, but will promote it with braindead
  92. marketing techniques. But if you're looking at something that exhibits
  93. several warning signs, you're probably dealing with snake oil.
  94.  
  95. Every effort has been made to produce an accurate and useful document, but
  96. the information herein is completely without warranty. This is a
  97. work-in-progress; feedback is greatly appreciated. If you find any errors or
  98. otherwise wish to contribute, please contact the document keeper, Matt
  99. Curtin <cmcurtin@research.megasoft.com>
  100.  
  101. Document History
  102.  
  103. With the rise in the number of crypto products came a rise in the number of
  104. ineffective or outright bogus products. After some discussion about this on
  105. the cypherpunks list, Robert Rothenburg <wlkngowl@unix.asb.com> wrote the
  106. first iteration of the Snake Oil FAQ. Matt Curtin took the early text and
  107. munged it into its current state with the help of the listed contributors
  108. (and probably some others whose names have inadvertently missed. Sorry in
  109. advance, if this is the case.)
  110.  
  111. Contributors
  112.  
  113. The following folks have contributed to this FAQ.
  114. Jeremey Barrett <jeremey@forequest.com>
  115. Matt Blaze <mab@research.att.com>
  116. Gary Ellison <gary.f.ellison@att.com>
  117. <fifersl@ibm.net>
  118. <geeman@best.com>
  119. Larry Kilgallen <KILGALLEN@Eisner.DECUS.Org>
  120. Dutra Lacerda <dutra.lacerda@mail.telepac.pt>
  121. Felix Lee <flee@teleport.com>
  122. Colin Plumb <colin@nyx.net>
  123. Jim Ray <liberty@gate.net>
  124. Terry Ritter <ritter@io.com>
  125. Robert Rothenburg <wlkngowl@unix.asb.com>
  126. Adam Shostack <adam@homeport.org>
  127. Rick Smith <smith@sctc.com>
  128. Randall Williams <ac387@yfn.ysu.edu>
  129.  
  130. Introduction
  131.  
  132. Good cryptography is an excellent and necessary tool for almost anyone. Many
  133. good cryptographic products are available commercially, as shareware, or
  134. free. However, there are also extremely bad cryptographic products which not
  135. only fail to provide security, but also contribute to the many
  136. misconceptions and misunderstandings surrounding cryptography and security.
  137.  
  138. Why ``snake oil''? The term is used in many fields to denote something sold
  139. without consideration of its quality or its ability to fulfill its vendor's
  140. claims. This term originally applied to elixirs sold in traveling medicine
  141. shows. The salesmen would claim their elixir would cure just about any
  142. ailment that a potential customer could have. Listening to the claims made
  143. by some crypto vendors, ``snake oil'' is a surprisingly apt name.
  144.  
  145. Superficially, it is difficult to distinguish snake oil from the Real Thing:
  146. all encryption utilities produce garbled output. The purpose of this
  147. document is to present some simple ``red flags'' that can help you detect
  148. snake oil.
  149.  
  150. For a variety of reasons, this document does not mention specific products
  151. or algorithms as being ``good'' or ``snake oil.''
  152.  
  153. Basic Concepts
  154.  
  155. In an effort to make this FAQ more complete, some basic information is
  156. covered here. The Cryptography FAQ [3] is a more general tutorial of
  157. cryptography and should also be consulted.
  158.  
  159. When evaluating any product, be sure to understand your needs. For data
  160. security products, what are you trying to protect? Do you want a data
  161. archiver, an e-mail plug-in, or something that encrypts on-line
  162. communications? Do you need to encrypt an entire disk or just a few files?
  163.  
  164. And how secure is secure enough? Does the data need to be unreadable by
  165. ``spies'' for five minutes, one year, or 100 years? Is the spy someone's kid
  166. sister, a corporation, or a government?
  167.  
  168. Symmetric vs. Asymmetric Cryptography
  169.  
  170. There are two basic types of cryptosystems: symmetric (also known as
  171. ``conventional'' or ``secret key'') and asymmetric (``public key.'')
  172.  
  173. Symmetric ciphers require both the sender and the recipient to have the same
  174. key. This key is used by the sender to encrypt the data, and again by the
  175. recipient to decrypt the data. The problem here is getting the sender and
  176. recipient to share the key.
  177.  
  178. Asymmetric ciphers are much more flexible from a key management perspective.
  179. Each user has a pair of keys: a public key and a private key. Messages
  180. encrypted with one key can only be decrypted by the other key. The public
  181. key can be published widely while the private key is kept secret.
  182.  
  183. So if Alice wishes to send Bob some secrets, she simply finds and verifies
  184. Bob's public key, encrypts her message with it, and mails it off to Bob.
  185. When Bob gets the message, he uses his private key to decrypt it.
  186.  
  187. Verification of public keys is an important step. Failure to verify that the
  188. public key really does belong to Bob leaves open the possibility that Alice
  189. is using a key whose associated private key is in the hands of an enemy.
  190.  
  191. Asymmetric ciphers are much slower than their symmetric counterparts. Also,
  192. key sizes generally must be much larger. See the Cryptography FAQ [3] for a
  193. more detailed discussion of these topics.
  194.  
  195. Secrecy vs. Integrity: What are you trying to protect?
  196.  
  197. For many users of computer-based crypto, preserving the contents of a
  198. message is as important as protecting its secrecy. Damage caused by
  199. tampering can often be worse than damage caused by disclosure. For example,
  200. it may be disquieting to discover that a hacker has read the contents of
  201. your funds-transfer authorization, but it's a disaster for him to change the
  202. transfer destination to his own account.
  203.  
  204. Encryption by itself does not protect a message from tampering. In fact,
  205. there are several techniques for changing the contents of an encrypted
  206. message without ever figuring out the encryption key. If the integrity of
  207. your messages is important, don't rely on just secrecy to protect them.
  208. Check how the vendor protects messages from undetected modification.
  209.  
  210. Key Sizes
  211.  
  212. Even if a cipher is secure against analytical attacks, it will be vulnerable
  213. to brute-force attacks if the key is too small. In a brute-force attack, the
  214. attacker simply tries every possible key until the right one is found. How
  215. long this takes depends on the size of the key and the amount of processing
  216. power available. So when trying to secure data, you need to consider how
  217. long it must remain secure and how much computing power an attacker can use.
  218.  
  219. [1] and [2] offer some guidelines for choosing an appropriate key length.
  220. For instance, Table 1 shows the cost of breaking symmetric keys by brute
  221. force, as noted by [2]. This shows us that using symmetric keys of 75 bits
  222. or more is wise for many applications, and for those applications requiring
  223. significant strength, 128 or even 160 bit keys is not completely
  224. unreasonable.
  225.  
  226.  
  227.                    Table 1: Time and Cost of Key Recovery
  228.  
  229.      Type of                           Time and Cost per  Length Needed for
  230.      Attacker     Budget      Tool        40-bit Key     Protection in Late
  231.                                            Recovered            1995
  232.                          Scavenged
  233.  Pedestrian      Tiny    Computer Time 1 Week            45
  234.  Hacker
  235.                  $400    FPGA          5 Hours ($0.08)   50
  236.  
  237.  Small business  $10,000 FPGA          12 Minutes        55
  238.                                        ($0.08)
  239.  
  240.                          FPGA          24 seconds
  241.  Corporate                             ($0.08)
  242.  Department      $300K                 .005 seconds      60
  243.                          ASIC
  244.                                        ($.001)
  245.                          FPGA          .7 seconds
  246.  Big Company     $10M                  .0005 seconds     70
  247.                          ASIC
  248.                                        ($0.001)
  249.  Intelligence                          .0002 seconds
  250.  Agency          $300M   ASIC          ($0.001)          75
  251.  
  252. As mentioned earlier, asymmetric ciphers typically require significantly
  253. longer keys to provide the same level of security as symmetric ciphers.
  254. Comparing key lengths between algorithms is awkward because different
  255. algorithms have different characteristics. Knowing the key size is useless
  256. if you don't know what type of algorithm is being used.
  257.  
  258. But to give you some idea of what's reasonable, Table 2, from [1], compares
  259. symmetric keys against one type of asymmetric key: those based on the
  260. ``factoring problem'' or the ``discrete log problem.'' (Algorithms based on
  261. the ``elliptical curve discrete log problem'' are more resistant to
  262. brute-force attacks and can use much smaller keys. In fact, they don't have
  263. to be much larger than symmetric keys, as far as we know right now.)
  264.  
  265.  
  266.    Table 2: Key Lengths With Similar
  267.    Resistance to Brute-Force Attacks
  268.  
  269.  Symmetric Key LengthPublic Key Length
  270.  56 bits             384 bits
  271.  64 bits             512 bits
  272.  80 bits             768 bits
  273.  112 bits            1792 bits
  274.  128 bits            2304 bits
  275.  
  276. Keys vs. Passphrases
  277.  
  278. A ``key'' is not the same thing as a ``passphrase'' or ``password.'' In
  279. order to resist attack, all possible keys must be equally probable. If some
  280. keys are more likely to be used than others, then an attacker can use this
  281. information to reduce the work needed to break the cipher.
  282.  
  283. Essentially, the key must be random. However, a passphrase generally needs
  284. to be easy to remember, so it has significantly less randomness than its
  285. length suggests. For example, a 20-letter English phrase, rather than having
  286. 20 x 8 = 150 bits of randomness, only has about 20 x 2 = 40 bits of
  287. randomness.
  288.  
  289. So, most cryptographic software will convert a passphrase into a key through
  290. a process called ``hashing'' or ``key initialization.'' Avoid cryptosystems
  291. that skip this phase by using a password directly as a key.
  292.  
  293. Implementation Environment
  294.  
  295. Other factors that can influence the relative security of a product are
  296. related to its environment. For example, in software-based encryption
  297. packages, is there any plaintext that's written to disk (perhaps in
  298. temporary files)? What about operating systems that have the ability to swap
  299. processes out of memory on to disk? When something to be encrypted has its
  300. plaintext counterpart deleted, is the extent of its deletion a standard
  301. removal of its name from the directory contents, or has it been written
  302. over? If it's been written over, how well has it been written over? Is that
  303. level of security an issue for you? Are you storing cryptographic keys on a
  304. multi-user machine? The likelihood of having your keys illicitly accessed is
  305. much higher, if so. It's important to consider such things when trying to
  306. decide how secure something you implement is (or isn't) going to be.
  307.  
  308. Snake Oil Warning Signs
  309.  
  310. ``Trust Us, We Know What We're Doing''
  311.  
  312. Perhaps the biggest warning sign of all is the ``trust us, we know what
  313. we're doing'' message that's either stated directly or implied by the
  314. vendor. If the vendor is concerned about the security of their system after
  315. describing exactly how it works, it is certainly worthless. Regardless of
  316. whether or not they tell, smart people will be able to figure it out. The
  317. bad guys after your secrets (especially if you are an especially attractive
  318. target, such as a large company, bank, etc.) are not stupid. They will
  319. figure out the flaws. If the vendor won't tell you exactly and clearly
  320. what's going on inside, you can be sure that they're hiding something, and
  321. that the only one to suffer as a result will be you, the customer.
  322.  
  323. Technobabble
  324.  
  325. If the vendor's description appears to be confusing nonsense, it may very
  326. well be so, even to an expert in the field. One sign of technobabble is a
  327. description which uses newly invented terms or trademarked terms without
  328. actually explaining how the system works. Technobabble is a good way to
  329. confuse a potential user and to mask the vendor's own lack of expertise.
  330.  
  331. And consider this: if the marketing material isn't clear, why expect the
  332. instruction manual to be any better? Even the best product can be useless if
  333. it isn't applied properly. If you can't understand what a vendor is saying,
  334. you're probably better off finding something that makes more sense.
  335.  
  336. Secret Algorithms
  337.  
  338. Avoid software which uses secret algorithms. This is not considered a safe
  339. means of protecting data. If the vendor isn't confident that its encryption
  340. method can withstand scrutiny, then you should be wary of trusting it.
  341.  
  342. A common excuse for not disclosing an algorithm is that ``hackers might try
  343. to crack the program's security.'' While this may be a valid concern, it
  344. should be noted that such ``hackers'' can reverse-engineer the program to
  345. see how it works anyway. This is not a problem if the algorithm is strong
  346. and the program is implemented properly.
  347.  
  348. Using a well-known trusted algorithm, providing technical notes explaining
  349. the implementation, and making the source code available are signs that a
  350. vendor is confident about its product's security. You can take the
  351. implementation apart and test it yourself. Even if the algorithm is good, a
  352. poor implementation will render a cryptography product completely useless.
  353. However, a lock that attackers can't break even when they can see its
  354. internal mechanisms is a strong lock indeed. Good cryptography is exactly
  355. this kind of lock.
  356.  
  357. Note that a vendor who specializes in cryptography may have a proprietary
  358. algorithm which they will reveal only under a non-disclosure agreement. The
  359. crypto product may be perfectly adequate if the vendor is reputable. (But
  360. how does a non-expert know if a vendor is reputable in cryptography?) In
  361. general, you're best off avoiding secret algorithms.
  362.  
  363. Revolutionary Breakthroughs
  364.  
  365. Beware of any vendor who claims to have invented a ``new type of
  366. cryptography'' or a ``revolutionary breakthrough.'' True breakthroughs are
  367. likely to show up in research literature, and professionals in the field
  368. typically won't trust them until after years of analysis, when they're not
  369. so new anymore.
  370.  
  371. The strength of any encryption scheme is only proven by the test of time.
  372. New crypto is like new pharmaceuticals, not new cars. And in some ways it's
  373. worse: if a pharmaceutical company produces bogus drugs, people will start
  374. getting sick, but if you're using bogus crypto, you probably won't have any
  375. indication that your secrets aren't as secret as you think.
  376.  
  377. Avoid software which claims to use `new paradigms' of computing such as
  378. cellular automata, neural nets, genetic algorithms, chaos theory, etc. Just
  379. because software uses a different method of computation doesn't make it more
  380. secure. (In fact, these techniques are the subject of ongoing cryptographic
  381. research, and nobody has published successful results based on their use
  382. yet.)
  383.  
  384. Also be careful of specially modified versions of well-known algorithms.
  385. This may intentionally or unintentionally weaken the cipher.
  386.  
  387. It's important to understand the difference between a new cipher and a new
  388. product. Engaging in the practice of developing ciphers and cryptographic
  389. products is a fine thing to do. However, to do both at the same time is
  390. foolish. Many snake oil vendors brag about how they do this, despite the
  391. lack of wisdom in such activity.
  392.  
  393. Experienced Security Experts, Rave Reviews, and Other Useless Certificates
  394.  
  395. Beware of any product that claims it was analyzed by ``experienced security
  396. experts'' without providing references. Always look for the bibliography.
  397. Any cipher that they're using should appear in a number of scholarly
  398. references. If not, it's obviously not been tested well enough to prove or
  399. disprove its security.
  400.  
  401. Don't rely on reviews in newspapers, magazines, or television shows, since
  402. they generally don't have cryptographers to analyze software for them.
  403. (Celebrity ``hackers'' who know telephone systems are not necessarily crypto
  404. experts.)
  405.  
  406. Just because a vendor is a well known company or the algorithm is patented
  407. doesn't make it secure either.
  408.  
  409. Excessively Large Keys
  410.  
  411. A common feature of snake oil is to have key lengths that are much longer
  412. than practical. This is often due to confusion between symmetric and
  413. asymmetric ciphers. For example, a vendor who claims to use a strong
  414. symmetric cipher with a 2048-bit key probably lacks some basic understanding
  415. of key length requirements and of the computational expense of using such
  416. keys. [2] recommends key lengths of 75 to 90 bits for most applications.
  417.  
  418. Unbreakability
  419.  
  420. Some vendors will claim their software is ``unbreakable.'' This is marketing
  421. hype, and a common sign of snake oil. No algorithm is unbreakable. Even the
  422. best algorithms are susceptible to brute-force attacks, though this can be
  423. impractical if the key is large enough.
  424.  
  425. Some companies that claim unbreakability actually have serious reasons for
  426. saying so. Unfortunately, these reasons generally depend on some narrow
  427. definition of what it means to ``break'' security. For example, one-time
  428. pads (see the next section) are technically unbreakable as far as secrecy
  429. goes, but only if several difficult and important conditions are true. Even
  430. then, they are trivially vulnerable to known plaintext attacks on the
  431. message's integrity. Other systems may be unbreakable only if one of the
  432. communicating devices (such as a laptop) isn't stolen. So be sure to find
  433. out exactly what the ``unbreakable'' properties of the system are, and see
  434. if the more breakable parts of the system also provide adequate security.
  435.  
  436. Often, less-experienced vendor representatives will roll their eyes and say,
  437. ``Of course it's not unbreakable if you do such-and-such.'' The point is
  438. that the exact nature of ``such and such'' will vary from one product to
  439. another. Pick the one that best matches your operational needs without
  440. sacraficing your security requirements.
  441.  
  442. One-Time-Pads
  443.  
  444. A vendor might claim the system uses a one-time-pad (OTP), which is provably
  445. unbreakable. Technically, the encrypted output of an OTP system is equally
  446. likely to decrypt to any same-size plaintext. For example,
  447.  
  448.      598v *$ _+~ xCtMB0
  449.  
  450. has an equal chance of decrypting to any of these:
  451.  
  452.      the answer is yes
  453.      the answer is no!
  454.      you are a weenie!
  455.  
  456. Snake oil vendors will try to capitalize on the known strength of an OTP.
  457. But it is important to understand that any variation in the implementation
  458. means that it is not an OTP and has nowhere near the security of an OTP.
  459.  
  460. An OTP system works by having a ``pad'' of random bits in the possession of
  461. both the sender and recipient, but absolutely no one else. Originally, paper
  462. pads were used before general-purpose computers came into being. The pad
  463. must be sent from one party to the other securely, such as in a locked
  464. briefcase handcuffed to the carrier.
  465.  
  466. To encrypt an n-bit message, the next n bits in the pad are used as a key.
  467. After the bits are used from the pad, they're destroyed, and can never be
  468. used again.
  469.  
  470. The bits in the pad cannot be generated by an algorithm or cipher. They must
  471. be truly random, using a real random source such as specialized hardware,
  472. radioactive decay timings, etc. Anything else is not an OTP.
  473.  
  474. OTPs are seriously vulnerable if you ever reuse a pad. For instance, the
  475. NSA's VENONA project [4], without the benefit of computer assistance,
  476. managed to decrypt a series of KGB messages encrypted with faulty pads. It
  477. doesn't take much work to crack a reused pad.
  478.  
  479. The real limitation to practical use of OTPs is the generation and
  480. distribution of truly random keys. You have to distribute at least one bit
  481. of key for every bit of data transmitted. So OTPs are awkward for general
  482. purpose cryptography. They're only practical for extremely-low-bandwidth
  483. communication channels where two parties can exchange pads with a method
  484. different than they exchange messages. (It is rumored that a link from
  485. Washington, D.C., to Moscow was encrypted with an OTP.)
  486.  
  487. Further, if pads are provided by a vendor, you cannot verify the quality of
  488. the pads. How do you know the vendor isn't sending the same bits to
  489. everyone? Keeping a copy for themselves? Or selling a copy to your rivals?
  490.  
  491. Also, some vendors may try to confuse random session keys or initialization
  492. vectors with OTPs.
  493.  
  494. Algorithm or product X is insecure
  495.  
  496. Be wary of anything that claims that competing algorithms or products are
  497. insecure without providing evidence for these claims. Sometimes attacks are
  498. theoretical or impractical, requiring special circumstances or massive
  499. computing power over many years, and it's easy to confuse a layman by
  500. mentioning these.
  501.  
  502. Recoverable Keys
  503.  
  504. If there is a key-backup or key-escrow system, are you in control of the
  505. backup or does someone else hold a copy of the key? Can a third party
  506. recover your key without much trouble? Remember, you have no security
  507. against someone who has your key.
  508.  
  509. If the vendor claims it can recover lost keys without using some type of
  510. key-escrow service, avoid it. The security is obviously flawed.
  511.  
  512. Exportable from the USA
  513.  
  514. If the software is made in the USA, can it be exported? Strong cryptography
  515. is considered dangerous munitions by the United States and requires approval
  516. from the US State Department before it can leave the country. (The U.S.
  517. isn't alone in this; some other nations have similar export restrictions on
  518. strong cryptography.) Chances are, if the software has been approved for
  519. export, the algorithm is weak or crackable.
  520.  
  521. If the vendor is unaware of export restrictions, avoid their software. For
  522. example, if they claim that the IDEA cipher can be exported when most
  523. vendors (and the State Department!) do not make such a claim, then the
  524. vendor is probably lacking sufficient clue to provide you with good
  525. cryptography.
  526.  
  527. Because of export restrictions, some decent crypto products come in two
  528. flavors: US-only and exportable. The exportable version will be crippled,
  529. probably by using smaller keys, making it easy to crack.
  530.  
  531. There are no restrictions on importing crypto products into the US, so a
  532. non-US vendor can legally offer a single, secure version of a product for
  533. the entire world.
  534.  
  535. Note that a cryptosystem may not be exportable from the US even if it is
  536. available outside the US: sometimes a utility is illegally exported and
  537. posted on an overseas site.
  538.  
  539. ``Military Grade''
  540.  
  541. Many crypto vendors claim their system is ``military grade.'' This is a
  542. meaningless term, since there isn't a standard that defines ``military
  543. grade,'' other than actually being used by various armed forces. Since these
  544. organizations don't reveal what crypto they use, it isn't possible to prove
  545. or disprove that something is ``military grade.''
  546.  
  547. Unfortunately, some good crypto products also use this term. Watch for this
  548. in combination with other snake oil indicators, e.g., ``our military-grade
  549. encryption system is exportable from the US!''
  550.  
  551. Other Considerations
  552.  
  553. Avoid vendors who don't seem to understand anything described in the ``Basic
  554. Concepts'' section above.
  555.  
  556. Avoid anything that doesn't let you generate your own keys (e.g., the vendor
  557. sends you keys in the mail, or keys are embedded in the copy of the software
  558. you buy).
  559.  
  560. Avoid anything that allows someone with your copy of the software to access
  561. files, data, etc. without needing some sort of key or passphrase.
  562.  
  563. Beware of products that are designed for a specific task, such as data
  564. archiving, and have encryption as an additional feature. Typically, it's
  565. better to use an encryption utility for encryption, rather than some tool
  566. designed for another purpose that adds encryption as an afterthought.
  567.  
  568. No product is secure if used improperly. You can be the weakest link in the
  569. chain if you use a product carelessly. Do not trust any product to be
  570. foolproof, and be wary of any product that claims it is.
  571.  
  572. Interface isn't everything: user-friendliness is important, but be wary of
  573. anything that puts too much emphasis on ease of use without due
  574. consideration to cryptographic strength.
  575.  
  576. Glossary
  577.  
  578. algorithm
  579.      A procedure or mathematical formula. Cryptographic algorithms convert
  580.      plaintext to and from ciphertext.
  581. cipher
  582.      Synonym for ``cryptographic algorithm''
  583. cryptanalysis
  584.      To solve or ``break'' a cryptosystem.
  585. escrow
  586.      A third party able to decrypt messages sent from one person to another.
  587.      Although this term is often used in connection with the US Government's
  588.      ``Clipper'' proposals, it isn't limited to government-mandated ability
  589.      to access encrypted information at will. Some corporations might wish
  590.      to have their employees use cryptosystems with escrow features when
  591.      conducting the company's business, so the information can be retrieved
  592.      should the employee be unable to unlock it himself later, (if he were
  593.      to forget his passphrase, suddenly quit, get run over by a bus, etc.)
  594.      Or, someone might wish his spouse or lawyer to be able to recover
  595.      encrypted data, etc., in which case he could use a cryptosystem with an
  596.      escrow feature.
  597. initialization vector
  598.      One of the problems with encrypting such things as files in specific
  599.      formats (i.e., that of a word processor, email, etc.) is that there is
  600.      a high degree of predictability about the first bytes of the message.
  601.      This could be used to break the encrypted message easier than by brute
  602.      force. In ciphers where one block of data is used to influence the
  603.      ciphertext of the next (such as CBC), a random block of data is
  604.      encrypted and used as the first block of the encrypted message,
  605.      resulting in a less predictable ciphertext message. This random block
  606.      is known as the initialization vector. The decryption process also
  607.      performs the function of removing the first block, resulting in the
  608.      original plaintext.
  609.  
  610. ITAR
  611.      International Traffic in Arms Regulations. These are the rules by which
  612.      munitions (including cryptography), as defined by the US State
  613.      Department, may (or may not) be exported from the US.
  614.  
  615. key
  616.      A piece of data that, when fed to an algorithm along with ciphertext,
  617.      will yield plaintext. (Or, when fed to an algorithm along with
  618.      plaintext, will yield ciphertext.
  619.  
  620. random session key
  621.      This is a temporary key that is generated specifically for one message.
  622.      Typically, in public key cryptosystems, the message to be sent is
  623.      encrypted with a symmetric key that was specifically generated for that
  624.      message. The encrypted version of that message, as well as the
  625.      associated session key can then be encrypted with the recipient's
  626.      public key. When the recipient decrypts the message, then, the system
  627.      will actually decrypt the message it gets (which is the ciphertext
  628.      message and the symmetric key to decrypt it), and then use the
  629.      symmetric key to decrypt the ciphertext. The result is the plaintext
  630.      message. This is often done because of the tremendous difference in the
  631.      speed of symmetric vs. asymmetric ciphers.
  632.  
  633. References
  634.  
  635. 1     B. Schneier. Applied Cryptography, 2e. John Wiley & Sons. 1996.
  636. 2     M. Blaze, W. Diffie, R. L. Rivest, B. Schneier, T. Shimomura, E.
  637.      Thompson, M. Wiener. ``Minimal Key Lengths for Symmetric Ciphers to
  638.      Provide Adequate Commercial Security''. Available at
  639.      ftp://ftp.research.att.com/dist/mab/keylength.ps.
  640. 3     The Crypt Cabal. Cryptography FAQ. Available at
  641.      http://www.cis.ohio-state.edu/hypertext/faq/usenet/cryptography-faq/top.html.
  642. 4     The National Security Agency. The VENONA Project. Available at
  643.      http://www.nsa.gov/docs/venona/venona.html.
  644.  
  645. ----------------------------------------------------------------------------
  646.  
  647. C Matthew Curtin
  648. Sat Jan 11 16:27:57 EST 1997
  649.  
  650. -- 
  651. Matt Curtin  Chief Scientist  Megasoft, Inc.  cmcurtin@research.megasoft.com
  652. http://www.research.megasoft.com/people/cmcurtin/    I speak only for myself
  653. Hacker Security Firewall Crypto PGP Privacy Unix Perl Java Internet Intranet
  654.