home *** CD-ROM | disk | FTP | other *** search
/ Hacker 2 / HACKER2.mdf / cud / cud560.txt < prev    next >
Text File  |  1995-01-03  |  43KB  |  918 lines

  1.  
  2.  
  3. Computer underground Digest    Wed  Aug 11 1993   Volume 5 : Issue 60
  4.                            ISSN  1004-042X
  5.  
  6.        Editors: Jim Thomas and Gordon Meyer (TK0JUT2@NIU.BITNET)
  7.        Archivist: Brendan Kehoe
  8.        Shadow-Archivists: Dan Carosone / Paul Southworth
  9.                           Ralph Sims / Jyrki Kuoppala
  10.                           Ian Dickinson
  11.        Copie Editor: Etaoin Shrdlu, Senior
  12.  
  13. CONTENTS, #5.60 (Aug 11 1993)
  14. File 1--CuD #5.59 Glitch & Some Belated Thanks from CuD to "helpers"
  15. File 2--Computers, Freedom & Privacy, '94 -- Conference INFO
  16. File 3--Congressional Fellowships for PhD/s-telecommunications
  17. File 4--$50,000 Fine for "Software Theft" (Canadian News)
  18. File 5--SKIPJACK Review  (Encryption Background and Assessment)
  19.  
  20. Cu-Digest is a weekly electronic journal/newsletter. Subscriptions are
  21. available at no cost electronically from tk0jut2@mvs.cso.niu.edu. The
  22. editors may be contacted by voice (815-753-0303), fax (815-753-6302)
  23. or U.S. mail at:  Jim Thomas, Department of Sociology, NIU, DeKalb, IL
  24. 60115.
  25.  
  26. Issues of CuD can also be found in the Usenet comp.society.cu-digest
  27. news group; on CompuServe in DL0 and DL4 of the IBMBBS SIG, DL1 of
  28. LAWSIG, and DL1 of TELECOM; on GEnie in the PF*NPC RT
  29. libraries and in the VIRUS/SECURITY library; from America Online in
  30. the PC Telecom forum under "computing newsletters;"
  31. On Delphi in the General Discussion database of the Internet SIG;
  32. on the PC-EXEC BBS at (414) 789-4210; and on: Rune Stone BBS (IIRG
  33. WHQ) (203) 832-8441 NUP:Conspiracy; RIPCO BBS (312) 528-5020
  34. CuD is also available via Fidonet File Request from 1:11/70; unlisted
  35. nodes and points welcome.
  36. EUROPE:   from the ComNet in LUXEMBOURG BBS (++352) 466893;
  37.           In ITALY: Bits against the Empire BBS: +39-461-980493
  38.  
  39. ANONYMOUS FTP SITES:
  40.   UNITED STATES:  ftp.eff.org (192.88.144.4) in /pub/cud
  41.                   etext.archive.umich.edu (141.211.164.18)  in /pub/CuD/cud
  42.                   halcyon.com( 202.135.191.2) in /pub/mirror/cud
  43.                   aql.gatech.edu (128.61.10.53) in /pub/eff/cud
  44.   AUSTRALIA:      ftp.ee.mu.oz.au (128.250.77.2) in /pub/text/CuD.
  45.   EUROPE:         nic.funet.fi in pub/doc/cud. (Finland)
  46.                   ftp.warwick.ac.uk in pub/cud (United Kingdom)
  47.  
  48. COMPUTER UNDERGROUND DIGEST is an open forum dedicated to sharing
  49. information among computerists and to the presentation and debate of
  50. diverse views.  CuD material may  be reprinted for non-profit as long
  51. as the source is cited. Authors hold a presumptive copyright, and
  52. they should be contacted for reprint permission.  It is assumed that
  53. non-personal mail to the moderators may be reprinted unless otherwise
  54. specified.  Readers are encouraged to submit reasoned articles
  55. relating to computer culture and communication.  Articles are
  56. preferred to short responses.  Please avoid quoting previous posts
  57. unless absolutely necessary.
  58.  
  59. DISCLAIMER: The views represented herein do not necessarily represent
  60.             the views of the moderators. Digest contributors assume all
  61.             responsibility for ensuring that articles submitted do not
  62.             violate copyright protections.
  63.  
  64. ----------------------------------------------------------------------
  65.  
  66. Date: Tue, 3 Aug 1993 18:31:44 CDT
  67. From: CuD Moderators <cudigest@mindvox.phantom.com>
  68. Subject: File 1--CuD #5.59 Glitch & Some Belated Thanks from CuD to "helpers"
  69.  
  70. By now, those who receive CuD from the mailing list are aware of a
  71. major glitch that occurred in #5.59. The good news is that the glitch
  72. was *NOT* our error (or even a human error). It was a software glitch
  73. in the mailer, apparently resulting from an overload. It has hopefully
  74. been corrected, but we will likely move to another distribution site
  75. to accommodate the growing list.  We estimate that CuD currently has a
  76. readership of about 80,000, only about 1.8 percent of whom are
  77. on the mailing list, so the glitch did not affect most readers.
  78. Nonetheless, we are embarrassed and regret any inconvenience it
  79. caused.
  80.  
  81. We're also pleased with the CuD readers' response when they discovered
  82. the glitch. Only one displayed the mildest of pique.  The rest ranged
  83. from a matter of fact "oops" to floor-rolling funny lines. Proving, of
  84. course, what we've suspected all along:  CuD readers are a bright,
  85. gentle, and forgiving lot. The best line comes from Scott Best:
  86.  
  87.       Of course, if "glitch"'s keep happening, they soon become
  88.       "snafu"'s. And snafus become bugs. And, finally, bugs will
  89.       ulitimately become performance features.
  90.  
  91. And, while we're at it:
  92.  
  93. Gordon Meyer and I put out CuD, and--if we run a good issue--we
  94. generally receive a few accolades. But, CuD is actually a collective
  95. enterprise that depends heavily on readers for contributions and other
  96. services. Without them, we couldn't continue.  Some belated thanks to
  97. people who have been helpful over the past few months:
  98.  
  99. 1.  Special enthusiastic gratitudinous thanks to the folks at Central
  100. Michigan University who provided us with a site for mailing out CuDs.
  101. Their patience and assistance have been invaluable in reducing mailing
  102. time and the load on NIU's system.  There have been fewer bounces,
  103. faster delivery, and (we hope) better service.
  104.  
  105. 2. Thanks to Mike Stack, Mike Preis, and the other computer gurus at
  106. NIU who have been helpful in redirecting mail, patient and calm
  107. despite the habitually crashed mailer (prior to the mailserv switch)
  108. and have remained low-key and supportive despite the strain we've
  109. placed on the system. Thanks also to Neil Rickert, just on general
  110. principle. Someday, the NIU administrators may find it in their hearts
  111. to replace WYLBUR, an archaic operating system, but until then, these
  112. guys--along with Phil Rider and others--nurse us along with humor and
  113. invariable magic.
  114.  
  115. 3. Thanks to everybody who sends in articles. We often hear that
  116. somebody didn't send something--such as a news blurb or other
  117. info--because they assumed somebody else would do it. WHEN IT DOUBT,
  118. SEND!  It's better that we have multiple copies of something than
  119. none--so, keep the articles and news blurbs coming. We're especially
  120. in need of local or regional "computer crime" cases that we might not
  121. see in the Chicago or New York papers.
  122.  
  123. 4. Thanks to all the people who complimented us (as well as to those
  124. who offered constructive criticism). And, thanks to those who felt
  125. like flaming but hit the delete key instead.
  126.  
  127. 5. Thanks to the BBS readers who lack Net access, but who nonetheless
  128. send in their contributions via disk or call with information.
  129. Sometimes we can't run it, but the information is crucial to keeping
  130. us informed about the BBS world.
  131.  
  132. 6. We're indebted to a number of individuals and groups who've been
  133. supportive and helpful over the years. These include the LOD crowd,
  134. PHRACK folk, Pat and Bruce at Mindvox (telnet mindvox.phantom.com),
  135. John McMullen for allowing reprints of his piece, Joe Abernathy for
  136. the same, Netta Gilboa of Gray Areas (one of the most promising new
  137. 'Zines to come along), Jack Ricard of Boardwatch (an essential 'Zine
  138. for anybody interested in the BBS world), Dark Adept, Kim Clancy, Dr.
  139. Ripco, and many, many others. And, of course, Chenko Kaninovich and
  140. Maggie T. Katt.  These, and others we don't have space to name
  141. (short-term memory loss notwithstanding) have been invaluable over the
  142. years, and we're grateful.
  143.  
  144. 7. Thanks to Bill Cook and the Secret Service, without whom there
  145. would be no Cu-Digest.
  146.  
  147. There are others we've probably forgotten to acknowledge, so thanks to
  148. all of them.  And, of course, thanks to Pat Townson, CuD's symbolic
  149. progenitor.
  150.  
  151. ------------------------------
  152.  
  153. Date: Tue, 3 Aug 1993 18:31:44 CDT
  154. From: CuD Moderators <cudigest@mindvox.phantom.com>
  155. Subject: File 2--Computers, Freedom & Privacy, '94 -- Conference INFO
  156.  
  157.                    "Computers, Freedom & Privacy '94"
  158.                    George B. Trubow, General Chair
  159.                 Timothy R. Rabel, Conference Coordinator
  160.  
  161.                         John Marshall Law School
  162.                         315 South Plymouth Court
  163.                            Chicago, IL 60604
  164.  
  165.     e-mail = cfp94@jmls.edu                        voice = (312) 987-1419
  166.                           fax = (312) 427-8307
  167.    *-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*-*
  168.  
  169.  
  170.               Conference Announcement and Call for Papers
  171.                   Computers, Freedom, and Privacy 1994
  172.                             23-26 March 1994
  173.  
  174.  Announcement
  175.  
  176.       The fourth annual conference, "Computers, Freedom, and Privacy,"
  177.  will be held in Chicago, Il., March 23-26, 1994.  This conference
  178.  will be jointly sponsored by the Association for Computing Machinery
  179.  (ACM) and The John Marshall Law School.  George B. Trubow, professor
  180.  of law and director of the Center for Informatics Law at The John
  181.  Marshall Law School, is general chairman of the conference.
  182.  
  183.       The advance of computer and communications technologies holds
  184.  great promise for individuals and society.  From conveniences for
  185.  consumers and efficiencies in commerce to improved public health and
  186.  safety and increased knowledge of and participation in government and
  187.  community, these technologies are fundamentally transforming our
  188.  environment and our lives.
  189.  
  190.       At the same time, these technologies present challenges to the
  191.  idea of a free and open society.  Personal privacy is increasingly at
  192.  risk from invasions by high-tech surveillance and monitoring; a
  193.  myriad of personal information data bases expose private life to
  194.  constant scrutiny; new forms of illegal activity may threaten the
  195.  traditional barriers between citizen and state and present new tests
  196.  of Constitutional protection; geographic boundaries of state and
  197.  nation may be recast by information exchange that knows no boundaries
  198.  as governments and economies are caught up in global data networks.
  199.  
  200.       Computers, Freedom, and Privacy '94 will present an assemblage
  201.  of experts, advocates and interested parties from diverse
  202.  perspectives and disciplines to consider the effects on freedom and
  203.  privacy resulting from the rapid technological advances in computer
  204.  and telecommunication science.  Participants come from fields of
  205.  computer science, communications, law, business and commerce,
  206.  research, government, education, the media, health, public advocacy
  207.  and consumer affairs, and a variety of other backgrounds. A series of
  208.  pre-conference tutorials will be offered on March 23, 1994, with the
  209.  conference program beginning on Thursday, March 24, and running
  210.  through Saturday, March 26, 1994.
  211.  
  212.       The Palmer House, a Hilton hotel located at the corner of State
  213.  Street and Washington Ave. in Chicago's "loop," and only about a
  214.  block from The John Marshall Law School buildings, will be the
  215.  conference headquarters.  Room reservations should be made directly
  216.  with the hotel, mentioning The John Marshall Law School or "CFP'94"
  217.  to get the special conference rate of $99.00, plus tax.
  218.  
  219.                       The Palmer House Hilton
  220.                 17 E. Monroe., Chicago, Il., 60603
  221.        Tel: 312-726-7500;  1-800-HILTONS;  Fax 312-263-2556
  222.  
  223.  Call for Papers and Program Suggestions
  224.  
  225.       The emphasis at CFP'94 will be on examining the many potential
  226.  uses of new technology and considering recommendations for dealing
  227.  with them.  Specific suggestions to harness the new technologies so
  228.  society can enjoy the benefits while avoiding negative implications
  229.  are solicited.
  230.  
  231.       Proposals are requested from anyone working on a relevant paper,
  232.  or who has an idea for a program presentation that will demonstrate
  233.  new computer or communications technology and suggest what can be
  234.  done with it.  Any proposal must:  state the title of the paper or
  235.  program; describe the theme and content in a short paragraph; set out
  236.  the credentials and experience of the author or suggested speakers;
  237.  and should not exceed two pages.  If an already completed paper is
  238.  being proposed for presentation, then a copy should be included with
  239.  the proposal.
  240.  
  241.  Student Papers and Scholarships
  242.  
  243.       It is anticipated that announcement of a student writing
  244.  competition for CFP'94 will be made soon, together with information
  245.  regarding the availability of a limited number of student
  246.  scholarships for the conference.
  247.  
  248.  Timetables
  249.  
  250.       Proposals for papers and programs are being accepted at this
  251.  time.  It is intended that program committees will be finalized by
  252.  August 1, 1993.  Proposals must be received by October 1, 1993.
  253.  
  254.  Communications
  255.  
  256.  Conference communications should be sent to:
  257.                               CFP'94
  258.                      The John Marshall Law School
  259.                         315 S. Plymouth Ct.
  260.                          Chicago, IL 60604
  261.  
  262.  (Voice: 312-987-1419; Fax: 312-427-8307; E-mail: CFP94@jmls.edu)
  263.  
  264. ------------------------------
  265.  
  266. Date: Mon, 2 Aug 1993 18:29:01 CDT
  267. From: CuD Moderators <tk0jut2@mvs.cso.niu.edu>
  268. Subject: File 3--Congressional Fellowships for PhD/s-telecommunications
  269.  
  270. CONGRESSIONAL FELLOWSHIPS for Ph.D. level scholars of any
  271. discipline who have a demonstrated interest in telecommunications
  272. and in public policy. Candidates must show promise of making a
  273. significant contribution to the public's understanding of the
  274. political process. Ten month program of practical experience on
  275. Capitol Hill begins November 1994 and concludes August 1995.
  276. Application deadline, DECEMBER 1, 1993. Information:  Director,
  277. Congressional Fellowship Program, American Political Science
  278. Association, 1527 New Hampshire Ave., N.W., Washington, DC 20036.
  279. ph 202-483-2512.
  280.  
  281. ------------------------------
  282.  
  283. Date:         Tue, 10 Aug 93 16:34:27 CDT
  284. From:         Mitch Pravatiner <U15289@UICVM.BITNET>
  285. Subject: File 4--$50,000 Fine for "Software Theft" (Canadian News)
  286.  
  287. The following story from the July 24 _Vancouver Sun_ business section
  288. may be of interest, especially the final paragraph.
  289.  
  290.                    $50,000 FINE FOR SOFTWARE THEFT
  291.  
  292. TORONTO--The first corporation in Canada to be charged with software
  293. theft has pleaded guilty and been fined $50,000.
  294.  
  295. Rexcan Circuits Inc., of Belleville, Ont., has also agreed to submit
  296. to a software audit by the Canadian Alliance Against Software Theft, a
  297. computer industry association.
  298.  
  299. Related charges against two senior Rexcan executives were dropped.
  300.  
  301. Rexcan, a circuit board manufacturer employing 200, is a subsidiary of
  302. Kuriko Electrical Industry Co. Ltd of Japan.
  303.  
  304. Software theft occurs when a single computer disk is used to load
  305. software into more than one computer.
  306.  
  307. ------------------------------
  308.  
  309. Date: Mon, 02 Aug 1993 15:23:28 -0400 (EDT)
  310. From: denning@CS.GEORGETOWN.EDU(Dorothy Denning)
  311. Subject: File 5--SKIPJACK Review  (Encryption Background and Assessment)
  312.  
  313.                             SKIPJACK Review
  314.  
  315.                              Interim Report
  316.  
  317.                         The SKIPJACK Algorithm
  318.  
  319.  
  320.            Ernest F. Brickell, Sandia National Laboratories
  321.                Dorothy E. Denning, Georgetown University
  322.             Stephen T. Kent, BBN Communications Corporation
  323.                           David P. Maher, AT&T
  324.                   Walter Tuchman, Amperif Corporation
  325.  
  326.                               July 28, 1993
  327.  
  328.                             (copyright 1993)
  329.  
  330.  
  331. Executive Summary
  332.  
  333. The objective of the SKIPJACK review was to provide a mechanism whereby
  334. persons outside the government could evaluate the strength of the
  335. classified encryption algorithm used in the escrowed encryption devices
  336. and publicly report their findings.  Because SKIPJACK is but one
  337. component of a large, complex system, and because the security of
  338. communications encrypted with SKIPJACK depends on the security of the
  339. system as a whole, the review was extended to encompass other
  340. components of the system.  The purpose of this Interim Report is to
  341. report on our evaluation of the SKIPJACK algorithm.  A later Final
  342. Report will address the broader system issues.
  343.  
  344. The results of our evaluation of the SKIPJACK algorithm are as
  345. follows:
  346.  
  347.   1. Under an assumption that the cost of processing power is halved
  348.      every eighteen months, it will be 36 years before the cost of
  349.      breaking SKIPJACK by exhaustive search will be equal to the cost
  350.      of breaking DES today.  Thus, there is no significant risk that
  351.      SKIPJACK will be broken by exhaustive search in the next 30-40
  352.      years.
  353.  
  354.   2. There is no significant risk that SKIPJACK can be broken through a
  355.      shortcut method of attack.
  356.  
  357.   3. While the internal structure of SKIPJACK must be classified in
  358.      order to protect law enforcement and national security objectives,
  359.      the strength of SKIPJACK against a cryptanalytic attack does not
  360.      depend on the secrecy of the algorithm.
  361.  
  362.  
  363.  
  364. 1.  Background
  365.  
  366. On April 16, the President announced a new technology initiative aimed
  367. at providing a high level of security for sensitive, unclassified
  368. communications, while enabling lawfully authorized intercepts of
  369. telecommunications by law enforcement officials for criminal
  370. investigations.  The initiative includes several components:
  371.  
  372.     A classified encryption/decryption algorithm called "SKIPJACK."
  373.  
  374.     Tamper-resistant cryptographic devices (e.g., electronic chips),
  375.     each of which contains SKIPJACK, classified control software, a
  376.     device identification number, a family key used by law enforcement,
  377.     and a device unique key that unlocks the session key used to
  378.     encrypt a particular communication.
  379.  
  380.     A secure facility for generating device unique keys and programming
  381.     the devices with the classified algorithms, identifiers, and keys.
  382.  
  383.     Two escrow agents that each hold a component of every device unique
  384.     key.  When combined, those two components form the device unique
  385.     key.
  386.  
  387.     A law enforcement access field (LEAF), which enables an authorized
  388.     law enforcement official to recover the session key.  The LEAF is
  389.     created by a device at the start of an encrypted communication and
  390.     contains the session key encrypted under the device unique key
  391.     together with the device identifier, all encrypted under the family
  392.     key.
  393.  
  394.     LEAF decoders that allow an authorized law enforcement official to
  395.     extract the device identifier and encrypted session key from an
  396.     intercepted LEAF.  The identifier is then sent to the escrow
  397.     agents, who return the components of the corresponding device
  398.     unique key.  Once obtained, the components are used to reconstruct
  399.     the device unique key, which is then used to decrypt the session
  400.     key.
  401.  
  402. This report reviews the security provided by the first component,
  403. namely the SKIPJACK algorithm.  The review was performed pursuant to
  404. the President's direction that "respected experts from outside the
  405. government will be offered access to the confidential details of the
  406. algorithm to assess its capabilities and publicly report their
  407. finding."  The Acting Director of the National Institute of Standards
  408. and Technology (NIST) sent letters of invitation to potential
  409. reviewers.  The authors of this report accepted that invitation.
  410.  
  411. We attended an initial meeting at the Institute for Defense Analyses
  412. Supercomputing Research Center (SRC) from June 21-23.  At that meeting,
  413. the designer of SKIPJACK provided a complete, detailed description of
  414. the algorithm, the rationale for each feature, and the history of the
  415. design.  The head of the NSA evaluation team described the evaluation
  416. process and its results.  Other NSA staff briefed us on the LEAF
  417. structure and protocols for use, generation of device keys, protection
  418. of the devices against reverse engineering, and NSA's history in the
  419. design and evaluation of encryption methods contained in SKIPJACK.
  420. Additional NSA and NIST staff were present at the meeting to answer our
  421. questions and provide assistance.  All staff members were forthcoming
  422. in providing us with requested information.
  423.  
  424. At the June meeting, we agreed to integrate our individual evaluations
  425. into this joint report.  We also agreed to reconvene at SRC from July
  426. 19-21 for further discussions and to complete a draft of the report.
  427. In the interim, we undertook independent tasks according to our
  428. individual interests and availability.  Ernest Brickell specified a
  429. suite of tests for evaluating SKIPJACK.  Dorothy Denning worked at NSA
  430. on the refinement and execution of these and other tests that took into
  431. account suggestions solicited from Professor Martin Hellman at Stanford
  432. University.  NSA staff assisted with the programming and execution of
  433. these tests.  Denning also analyzed the structure of SKIPJACK and its
  434. susceptibility to differential cryptanalysis.  Stephen Kent visited NSA
  435. to explore in more detail how SKIPJACK compared with NSA encryption
  436. algorithms that he already knew and that were used to protect
  437. classified data.  David Maher developed a risk assessment approach
  438. while continuing his ongoing work on the use of the encryption chip in
  439. the AT&T Telephone Security Device.  Walter Tuchman investigated the
  440. anti-reverse engineering properties of the chips.
  441.  
  442. We investigated more than just SKIPJACK because the security of
  443. communications encrypted with the escrowed encryption technology
  444. depends on the security provided by all the components of the
  445. initiative, including protection of the keys stored on the devices,
  446. protection of the key components stored with the escrow agents, the
  447. security provided by the LEAF and LEAF decoder, protection of keys
  448. after they have been transmitted to law enforcement under court order,
  449. and the resistance of the devices to reverse engineering.  In addition,
  450. the success of the technology initiative depends on factors besides
  451. security, for example, performance of the chips.  Because some
  452. components of the escrowed encryption system, particularly the key
  453. escrow system, are still under design, we decided to issue this Interim
  454. Report on the security of the SKIPJACK algorithm and to defer our Final
  455. Report until we could complete our evaluation of the system as a
  456. whole.
  457.  
  458.  
  459. 2.  Overview of the SKIPJACK Algorithm
  460.  
  461. SKIPJACK is a 64-bit "electronic codebook" algorithm that transforms a
  462. 64-bit input block into a 64-bit output block.  The transformation is
  463. parameterized by an 80-bit key, and involves performing 32 steps or
  464. iterations of a complex, nonlinear function.  The algorithm can be used
  465. in any one of the four operating modes defined in FIPS 81 for use with
  466. the Data Encryption Standard (DES).
  467.  
  468. The SKIPJACK algorithm was developed by NSA and is classified SECRET.
  469. It is representative of a family of encryption algorithms developed in
  470. 1980 as part of the NSA suite of "Type I" algorithms, suitable for
  471. protecting all levels of classified data.  The specific algorithm,
  472. SKIPJACK, is intended to be used with sensitive but unclassified
  473. information.
  474.  
  475. The strength of any encryption algorithm depends on its ability to
  476. withstand an attack aimed at determining either the key or the
  477. unencrypted ("plaintext") communications.  There are basically two
  478. types of attack, brute-force and shortcut.
  479.  
  480.  
  481. 3.  Susceptibility to Brute Force Attack by Exhaustive Search
  482.  
  483. In a brute-force attack (also called "exhaustive search"), the
  484. adversary essentially tries all possible keys until one is found that
  485. decrypts the intercepted communications into a known or meaningful
  486. plaintext message.  The resources required to perform an exhaustive
  487. search depend on the length of the keys, since the number of possible
  488. keys is directly related to key length.  In particular, a key of length
  489. N bits has 2^N possibilities.  SKIPJACK uses 80-bit keys, which means
  490. there are 2^80 (approximately 10^24) or more than 1 trillion trillion
  491. possible keys.
  492.  
  493. An implementation of  SKIPJACK optimized for a single processor on the
  494. 8-processor Cray YMP performs about 89,000 encryptions per second.  At
  495. that rate, it would take more than 400 billion years to try all keys.
  496. Assuming the use of all 8 processors and aggressive vectorization, the
  497. time would be reduced to about a billion years.
  498.  
  499. A more speculative attack using a future, hypothetical, massively
  500. parallel machine with 100,000 RISC processors, each of which was
  501. capable of 100,000 encryptions per second, would still take about 4
  502. million years.  The cost of such a machine might be on the order of $50
  503. million.  In an even more speculative attack, a special purpose machine
  504. might be built using 1.2 billion $1 chips with a 1 GHz clock.  If the
  505. algorithm could be pipelined so that one encryption step were performed
  506. per clock cycle, then the $1.2 billion machine could exhaust the key
  507. space in 1 year.
  508.  
  509. Another way of looking at the problem is by comparing a brute force
  510. attack on SKIPJACK with one on DES, which uses 56-bit keys.  Given that
  511. no one has demonstrated a capability for breaking DES, DES offers a
  512. reasonable benchmark.  Since SKIPJACK keys are 24 bits longer than DES
  513. keys, there are 2^24 times more possibilities.  Assuming that the cost
  514. of processing power is halved every eighteen months, then it will not
  515. be for another 24 * 1.5 = 36 years before the cost of breaking
  516. SKIPJACK is equal to the cost of breaking DES today.  Given the lack of
  517. demonstrated capability for breaking DES, and the expectation that the
  518. situation will continue for at least several more years, one can
  519. reasonably expect that SKIPJACK will not be broken within the next
  520. 30-40 years.
  521.  
  522. Conclusion 1:   Under an assumption that the cost of processing power
  523. is halved every eighteen months, it will be 36 years before the cost of
  524. breaking SKIPJACK by exhaustive search will be equal to the cost of
  525. breaking DES today.  Thus, there is no significant risk that SKIPJACK
  526. will be broken by exhaustive search in the next 30-40 years.
  527.  
  528. 4.  Susceptibility to Shortcut Attacks
  529.  
  530. In a shortcut attack, the adversary exploits some property of the
  531. encryption algorithm that enables the key or plaintext to be determined
  532. in much less time than by exhaustive search.  For example, the RSA
  533. public-key encryption method is attacked by factoring a public value
  534. that is the product of two secret primes into its primes.
  535.  
  536. Most shortcut attacks use probabilistic or statistical methods that
  537. exploit a structural weakness, unintentional or intentional (i.e., a
  538. "trapdoor"), in the encryption algorithm.  In order to determine
  539. whether such attacks are possible, it is necessary to thoroughly
  540. examine the structure of the algorithm and its statistical properties.
  541. In the time available for this review, it was not feasible to conduct
  542. an evaluation on the scale that NSA has conducted or that has been
  543. conducted on the DES.  Such review would require many man-years of
  544. effort over a considerable time interval.  Instead, we concentrated on
  545. reviewing NSA's design and evaluation process.  In addition, we
  546. conducted several of our own tests.
  547.  
  548. 4.1  NSA's Design and Evaluation Process
  549.  
  550. SKIPJACK was designed using building blocks and techniques that date
  551. back more than forty years.  Many of the techniques are related to work
  552. that was evaluated by some of the world's most accomplished and famous
  553. experts in combinatorics and abstract algebra.  SKIPJACK's more
  554. immediate heritage dates to around 1980, and its initial design to
  555. 1987.
  556.  
  557. SKIPJACK was designed to be evaluatable, and the design and evaluation
  558. approach was the same used with algorithms that protect the country's
  559. most sensitive classified information.  The specific structures
  560. included in SKIPJACK have a long evaluation history, and the
  561. cryptographic properties of those structures had many prior years of
  562. intense study before the formal process began in 1987.  Thus, an
  563. arsenal of tools and data was available.  This arsenal was used by
  564. dozens of adversarial evaluators whose job was to break SKIPJACK.  Many
  565. spent at least a full year working on the algorithm.  Besides highly
  566. experienced evaluators, SKIPJACK was subjected to cryptanalysis by less
  567. experienced evaluators who were untainted by past approaches.  All
  568. known methods of attacks were explored, including differential
  569. cryptanalysis.  The goal was a design that did not allow a shortcut
  570. attack.
  571.  
  572. The design underwent a sequence of iterations based on feedback from
  573. the evaluation process.  These iterations eliminated properties which,
  574. even though they might not allow successful attack, were related to
  575. properties that could be indicative of vulnerabilities.  The head of
  576. the NSA evaluation team confidently concluded "I believe that SKIPJACK
  577. can only be broken by brute force   there is no better way."
  578.  
  579. In summary, SKIPJACK is based on some of NSA's best technology.
  580. Considerable care went into its design and evaluation in accordance
  581. with the care given to algorithms that protect classified data.
  582.  
  583. 4.2  Independent Analysis and Testing
  584.  
  585. Our own analysis and testing increased our confidence in the strength
  586. of SKIPJACK and its resistance to attack.
  587.  
  588. 4.2.1  Randomness and Correlation Tests
  589.  
  590. A strong encryption algorithm will behave like a random function of the
  591. key and plaintext so that it is impossible to determine any of the key
  592. bits or plaintext bits from the ciphertext bits (except by exhaustive
  593. search).  We ran two sets of tests aimed at determining whether
  594. SKIPJACK is a good pseudo random number generator.  These tests were
  595. run on a Cray YMP at NSA.  The results showed that SKIPJACK behaves
  596. like a random function and that ciphertext bits are not correlated with
  597. either key bits or plaintext bits.  Appendix A gives more details.
  598.  
  599. 4.2.2  Differential Cryptanalysis
  600.  
  601. Differential cryptanalysis is a powerful method of attack that exploits
  602. structural properties in an encryption algorithm.  The method involves
  603. analyzing the structure of the algorithm in order to determine the
  604. effect of particular differences in plaintext pairs on the differences
  605. of their corresponding ciphertext pairs, where the differences are
  606. represented by the exclusive-or of the pair.  If it is possible to
  607. exploit these differential effects in order to determine a key in less
  608. time than with exhaustive search, an encryption algorithm is said to be
  609. susceptible to differential cryptanalysis.  However, an actual attack
  610. using differential cryptanalysis may require substantially more chosen
  611. plaintext than can be practically acquired.
  612.  
  613. We examined the internal structure of SKIPJACK to determine its
  614. susceptibility to differential cryptanalysis.  We concluded it was not
  615. possible to perform an attack based on differential cryptanalysis in
  616. less time than with exhaustive search.
  617.  
  618. 4.2.3  Weak Key Test
  619.  
  620. Some algorithms have "weak keys" that might permit a shortcut
  621. solution.  DES has a few weak keys, which follow from a pattern of
  622. symmetry in the algorithm.  We saw no pattern of symmetry in the
  623. SKIPJACK algorithm which could lead to weak keys.  We also
  624. experimentally tested the all "0" key (all 80 bits are "0") and the all
  625. "1" key to see if they were weak and found they were not.
  626.  
  627. 4.2.4  Symmetry Under Complementation Test
  628.  
  629. The DES satisfies the property that for a given plaintext-ciphertext
  630. pair and associated key, encryption of the one's complement of the
  631. plaintext with the one's complement of the key yields the one's
  632. complement of the ciphertext.  This "complementation property" shortens
  633. an attack by exhaustive search by a factor of two since half the keys
  634. can be tested by computing complements in lieu of performing a more
  635. costly encryption.  We tested SKIPJACK for this property and found that
  636. it did not hold.
  637.  
  638. 4.2.5  Comparison with Classified Algorithms
  639.  
  640. We compared the structure of SKIPJACK to that of NSA Type I algorithms
  641. used in current and near-future devices designed to protect classified
  642. data.  This analysis was conducted with the close assistance of the
  643. cryptographer who developed SKIPJACK and included an in-depth
  644. discussion of design rationale for all of the algorithms involved.
  645. Based on this comparative, structural analysis of SKIPJACK against
  646. these other algorithms, and a detailed discussion of the similarities
  647. and differences between these algorithms, our confidence in the basic
  648. soundness of SKIPJACK was further increased.
  649.  
  650. Conclusion 2:  There is no significant risk that SKIPJACK can be broken
  651. through a shortcut method of attack.
  652.  
  653.  
  654. 5.   Secrecy of the Algorithm
  655.  
  656. The SKIPJACK algorithm is sensitive for several reasons.  Disclosure of
  657. the algorithm would permit the construction of devices that fail to
  658. properly implement the LEAF, while still interoperating with legitimate
  659. SKIPJACK devices.  Such devices would provide high quality
  660. cryptographic security without preserving the law enforcement access
  661. capability that distinguishes this cryptographic initiative.
  662. Additionally, the SKIPJACK algorithm is classified SECRET   NOT
  663. RELEASABLE TO FOREIGN NATIONALS.  This classification reflects the high
  664. quality of the algorithm, i.e., it incorporates design techniques that
  665. are representative of algorithms used to protect classified
  666. information.  Disclosure of the algorithm would permit analysis that
  667. could result in discovery of these classified design techniques, and
  668. this would be detrimental to national security.
  669.  
  670. However, while full exposure of the internal details of SKIPJACK would
  671. jeopardize law enforcement and national security objectives, it would
  672. not jeopardize the security of encrypted communications.  This is
  673. because a shortcut attack is not feasible even with full knowledge of
  674. the algorithm.  Indeed, our analysis of the susceptibility of SKIPJACK
  675. to a brute force or shortcut attack was based on the assumption that
  676. the algorithm was known.
  677.  
  678. Conclusion 3:  While the internal structure of SKIPJACK must be
  679. classified in order to protect law enforcement and national security
  680. objectives, the strength of SKIPJACK against a cryptanalytic attack
  681. does not depend on the secrecy of the algorithm.
  682.  
  683. ++++++++++++++++++++++
  684. Appendix in LaTeX
  685. ++++++++++++++++++++++
  686. %documentstyle%article%
  687. %textheight 8.25in
  688. %topmargin -.25in
  689. %textwidth 6.5in
  690. %oddsidemargin 0in
  691. %begin%document%
  692. %parskip .25in
  693. %large
  694. %raggedright
  695. %setcounter%page%%8%
  696. %centerline%%bf Appendix A%
  697.  
  698. %%bf A.1 Cycle Structure Tests%
  699.  
  700. The first set of tests examined the cycle structure of SKIPJACK.  Fix
  701. a set of keys, $%cal K$, a plaintext, $m$, and a function $h%; : %;
  702. %%cal M% %longrightarrow %%cal K%$, where $%%cal M%$ is the set of all
  703. 64 bit messages.  Let $f %; : %; %%cal K% %longrightarrow %%cal K%$ be
  704. defined as $f(k) = h ( SJ(k,m))$ (where $SJ(k,m)$ denotes the SKIPJACK
  705. encryption of plaintext $m$ with key $k$).  Let $N = |%cal K|$.  The
  706. expected cycle length of $f$ is $%sqrt%%pi N /8%$.  We chose sets of
  707. $%cal K$ with $N %; = %; 2^%10%, 2^%16%, 2^%24%, 2^%32%,
  708. 2^%40%, 2^%48%, 2^%56%$.  For all of these $N$, the mean of the cycle
  709. lengths computed across all experiments was close to an expected
  710. relative error of
  711. $(1/%sqrt%j%$ for $j$ experiments) of the expected cycle length.
  712. We did not do this test with larger sets of keys because of the time
  713. constraints.
  714.  
  715. %begin%center%
  716. %begin%tabular%%lrrrrr%
  717. $N$ & %# of exps & Mean cycle len & Expec cycle len &
  718. Rel Err & Expec rel err %%
  719. %hline
  720. $2^%10%$ & 5000 & 20.4 & 20.1 & .019 & .014 %%
  721. $2^%16%$ & 3000 & 164.7 & 160.4 & .027 & .018 %%
  722. $2^%24%$ & 2000 & 2576.6 & 2566.8 & .004 & .022 %%
  723. $2^%32%$ & 2000 & 40343.2 & 41068.6 & .018 & .022 %%
  724. $2^%40%$ & 1000 & 646604.9 & 657097.6 & .016 & .032 %%
  725. $2^%48%$ & 10 & 8,980,043 & 10,513,561 & .145 & .316 %%
  726. $2^%56%$ & 1 & 28,767,197 & 168,216,976 & .829 & 1 %%
  727. %end%tabular%
  728. %end%center%
  729.  
  730. %%bf A.2 Statistical Randomness and Correlation Tests%
  731.  
  732. The second set of tests examined whether there were any correlations
  733. between the input and output of SKIPJACK, or between a key and the
  734. output.  We also looked for nonrandomness in functions of the form
  735. $SJ(k,m) %oplus SJ(k,m %oplus h)$ and functions of the form $SJ(k,m) %oplus
  736. SJ(k %oplus h , m)$ for all $h$ of Hamming weight 1 and 2 and for some
  737. randomly chosen $h$.  All results were consistent with these functions
  738. behaving like random functions.
  739.  
  740. Given a set of $N$ numbers of $k$-bits each, a chi-square test will
  741. test the hypothesis that this set of numbers was drawn (with
  742. replacement) from a uniform distribution on all of the $2^k$, $k$-bit
  743. numbers.  We ran the tests using a 99%% confidence level.  A truly
  744. random function would pass the test approximately 99%% of the time.
  745. The test is not appropriate when $N/2^k$ is too small, say $%leq 5$.
  746. Since it was infeasible to run the test for $k = 64$, we would pick 8
  747. bit positions, and generate a set of $N= 10,000$ numbers, and run the
  748. test on the $N$ numbers restricted to those 8 bit positions (thus
  749. $k=8$).  In some of the tests, we selected the 8 bits from the output
  750. of the function we were testing, and in others, we selected 4 bits
  751. from the input and 4 from the output.
  752.  
  753. Some of the tests were run on both the encryption and decryption
  754. functions of SKIPJACK.  The notation $SJ^%-1%(k,m)$ will be used to
  755. denote the decryption function of SKIPJACK with key $k$ on message
  756. $m$.
  757.  
  758. %%bf Test 1: Randomness test on output.  % In a single test: Fix $k$,
  759. fix mask of 8 output bits, select 10,000 random messages, run
  760. chi-square on the 10,000 outputs restricted to the mask of 8 output
  761. bits.  Repeat this single test for 200 different values of $k$ and 50
  762. different masks, for a total of 10,000 chi-square tests.  We found
  763. that .87%% of the tests failed the 99%% confidence level chi-square
  764. test.  This is within a reasonable experimental error of the expected
  765. value of 1%%.  On the decryption function, there were only .64%% of
  766. the tests that failed.  This was on a much smaller test set.
  767.  
  768. %begin%center%
  769. %begin%tabular%%|c|c|c|c|c|%
  770. %hline
  771. %# $k$  & %# masks &  function, $f(m)$ & mask & %% failed %%
  772. %hline
  773. 200 & 50 & $SJ(k,m)$ & 8 of $f(m)$ & .87 %%
  774. %hline
  775. 25 & 50 & $SJ^%-1%(k,m)$ & 8 of $f(m)$ & .64 %%
  776. %hline
  777. %end%tabular%
  778. %end%center%
  779.  
  780. %%bf Test 2: Correlation test between messages and output.%
  781. Single test:  Fix $k$, fix mask of 4 message bits and 4 output bits,
  782. select 10,000 random messages, run chi-square.
  783.  
  784. %begin%center%
  785. %begin%tabular%%|c|c|c|c|c|%
  786. %hline
  787. %# $k$  & %# masks &  function, $f(m)$ & mask & %% failed %%
  788. %hline
  789. 200 & 1000  & $SJ(k,m)$ & 4 of $m$, 4 of $f(m)$ & 1.06 %%
  790. %hline
  791. 25 & 1000 & $SJ^%-1%(k,m)$ & 4 of $m$, 4 of $f(m)$ & 1.01 %%
  792. %hline
  793. %end%tabular%
  794. %end%center%
  795.  
  796. %%bf Test 3: Randomness test on the xor of outputs, given a fixed xor of
  797. inputs.  %
  798. Single test: Fix $k$, fix mask of 8 output bits, select 10,000 random
  799. messages.
  800. Let $%cal H$ be the union of all 64 bit words of Hamming
  801. weight 1 (64 of these), all 64 bit words of Hamming weight 2 (2016 of
  802. these), and some randomly chosen 64 bit words (920 of these).
  803. Repeat this single test for all $h %in %cal H$, 50 different masks,
  804. and  4 different values
  805. of $k$.
  806.  
  807. %begin%center%
  808. %begin%tabular%%|c|c|c|c|c|c|%
  809. %hline
  810. %# $k$  & %# masks  & %# $h$ &  function, $f(m)$ & mask & %% failed %%
  811. %hline
  812. 4 & 50 & 3000 & $SJ(k,m) %oplus SJ(k,m %oplus h)$ & 8 of $f(m)$ & .99 %%
  813. %hline
  814. %end%tabular%
  815. %end%center%
  816.  
  817.  
  818. %%bf Test 4: Correlation test between message xors and output xors.  %
  819. Single test: Fix $k$, fix mask of 4 bits of $h$ and 4 bits of output,
  820. select 10,000 random $(m,h)$ pairs.
  821.  
  822. %begin%center%
  823. %begin%tabular%%|c|c|c|c|c|%
  824. %hline
  825. %# $k$  & %# masks &  function, $f(m,h)$ & mask & %% failed %%
  826. %hline
  827. 200 & 1000 & $SJ(k,m) %oplus SJ(k,m %oplus h)$ & 4 of $h$, 4 of $f(m,h)$
  828. & .99 %%
  829. %hline
  830. 25 & 1000 & $SJ^%-1%(k,m)  %oplus SJ^%-1%(k,m %oplus h)$ & 4 of $h$, 4 of
  831. $f(m,h)$ & 1.02 %%
  832. %hline
  833. %end%tabular%
  834. %end%center%
  835.  
  836. %%bf Test 5: Correlation test between messages and output xors.%
  837. Single test: Fix $k$, fix mask of 4 bits of $m$ and 4 bits of output
  838. xor, select 10,000 random messages.  Let $%cal H$ be the union of all
  839. 64 bit words of Hamming weight 1 (64 of these), some of the 64 bit
  840. words of Hamming weight 2 (100 of these), and some randomly chosen 64
  841. bit words (100 of these).
  842.  
  843. %begin%center%
  844. %begin%tabular%%|c|c|c|c|c|c|%
  845. %hline
  846. %# $k$  & %# masks & %# $h$&  function, $f(m)$ & mask & %% failed %%
  847. %hline
  848. 2 & 1000 & 264 & $SJ(k,m) %oplus SJ(k,m %oplus h)$ & 4 of $m$, 4 of $f(m)$
  849. & .99 %%
  850. %hline
  851. %end%tabular%
  852. %end%center%
  853.  
  854. %%bf Test 6: Correlation test between keys and output.%
  855. Single test:  Fix $m$, fix mask of 4 key bits and 4 output bits,
  856. select 10,000 random keys.
  857.  
  858. %begin%center%
  859. %begin%tabular%%|c|c|c|c|c|%
  860. %hline
  861. %# $m$ & %# masks &  function, $f(k)$ & mask & %% failed %%
  862. %hline
  863. 200 & 1000  & $SJ(k,m)$ & 4 of $k$, 4 of $f(k)$ & 1.00 %%
  864. %hline
  865. 25 & 1000 & $SJ^%-1%(k,m)$ & 4 of $k$, 4 of $f(k)$ & 1.02 %%
  866. %hline
  867. %end%tabular%
  868. %end%center%
  869.  
  870. %%bf Test 7: Randomness test on the xor of outputs, given a fixed xor of
  871. keys.  %
  872. Single test: Fix $m$, fix mask of 8 output bits, select 10,000 random
  873. keys.
  874. Let $%cal H$ be the union of all 80 bit words of Hamming
  875. weight 1 (80 of these), all 80 bit words of Hamming weight 2 (3160 of
  876. these), and some randomly chosen 80 bit words (760 of these).
  877. Repeat this single test for all $h %in %cal H$, 50 different masks,
  878. and  2 different values
  879. of $m$.
  880.  
  881. %begin%center%
  882. %begin%tabular%%|c|c|c|c|c|c|%
  883. %hline
  884. %# $m$ & %# masks  & %# $h$ &  function, $f(k)$ & mask & %% failed %%
  885. %hline
  886. 2 & 50 & 4000 & $SJ(k,m) %oplus SJ(k%oplus h,m )$ & 8 of $f(k)$ & .99 %%
  887. %hline
  888. %end%tabular%
  889. %end%center%
  890.  
  891.  
  892. %%bf Test 8: Correlation test between key xors and output xors.  %
  893. Single test: Fix $m$, fix mask of 4 bits of $h$ and 4 bits of output,
  894. select 10,000 random $(k,h)$ pairs.
  895.  
  896. %begin%center%
  897. %begin%tabular%%|c|c|c|c|c|%
  898. %hline
  899. %# $m$ & %# masks &  function, $f(k,h)$ & mask & %% failed %%
  900. %hline
  901. 200 & 1000 & $SJ(k,m) %oplus SJ(k%oplus h,m )$ & 4 of $h$, 4 of $f(k,h)$
  902. & 1.02 %%
  903. %hline
  904. 25 & 1000 & $SJ^%-1%(k,m) %oplus SJ^%-1%(k%oplus h,m )$ & 4 of $h$, 4
  905. of $f(k,h)$ & 1.1 %%
  906. %hline
  907. %end%tabular%
  908. %end%center%
  909. %end%document%
  910.  
  911. ------------------------------
  912.  
  913. End of Computer Underground Digest #5.60
  914. ************************************
  915.  
  916. 
  917. Downloaded From P-80 International Information Systems 304-744-2253
  918.