home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / etc / privacy / priv_520.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  26.6 KB  |  550 lines

  1. PRIVACY Forum Digest      Monday, 28 October 1996      Volume 05 : Issue 20
  2.  
  3.             Moderated by Lauren Weinstein (lauren@vortex.com)         
  4.               Vortex Technology, Woodland Hills, CA, U.S.A.
  5.     
  6.                        ===== PRIVACY FORUM =====              
  7.  
  8.     -------------------------------------------------------------------
  9.                The PRIVACY Forum is supported in part by the          
  10.                  ACM (Association for Computing Machinery)
  11.              Committee on Computers and Public Policy,      
  12.           "internetMCI" (a service of the Data Services Division         
  13.       of MCI Telecommunications Corporation), and Cisco Systems, Inc.
  14.                                  - - -
  15.              These organizations do not operate or control the     
  16.           PRIVACY Forum in any manner, and their support does not
  17.            imply agreement on their part with nor responsibility   
  18.         for any materials posted on or related to the PRIVACY Forum.
  19.     -------------------------------------------------------------------
  20.  
  21.  
  22. CONTENTS 
  23.     Postal "Change of Address" Issues on PRIVACY Forum Radio
  24.        (Lauren Weinstein; PRIVACY Forum Moderator)
  25.     Web Search Service Exposes Searches to Public Viewing
  26.        (Lauren Weinstein; PRIVACY Forum Moderator)
  27.     "Holographic" Full-Body Security Scanning
  28.        (Lauren Weinstein; PRIVACY Forum Moderator)
  29.     Re: Blood and Privacy? (Joe Decker)
  30.     A new attack on DES (Monty Solomon)
  31.     IEEE Symposium on Security and Privacy - call for papers
  32.        (Mary Ellen Zurko)
  33.  
  34.  
  35.  *** Please include a RELEVANT "Subject:" line on all submissions! ***
  36.             *** Submissions without them may be ignored! ***
  37.  
  38. -----------------------------------------------------------------------------
  39. The Internet PRIVACY Forum is a moderated digest for the discussion and
  40. analysis of issues relating to the general topic of privacy (both personal
  41. and collective) in the "information age" of the 1990's and beyond.  The
  42. moderator will choose submissions for inclusion based on their relevance and
  43. content.  Submissions will not be routinely acknowledged.
  44.  
  45. All submissions should be addressed to "privacy@vortex.com" and must have
  46. RELEVANT "Subject:" lines; submissions without appropriate and relevant
  47. "Subject:" lines may be ignored.  Excessive "signatures" on submissions are
  48. subject to editing.  Subscriptions are by an automatic "listserv" system; for
  49. subscription information, please send a message consisting of the word
  50. "help" (quotes not included) in the BODY of a message to:
  51. "privacy-request@vortex.com".  Mailing list problems should be reported to
  52. "list-maint@vortex.com". 
  53.  
  54. All messages included in this digest represent the views of their
  55. individual authors and all messages submitted must be appropriate to be
  56. distributable without limitations. 
  57.  
  58. The PRIVACY Forum archive, including all issues of the digest and all
  59. related materials, is available via anonymous FTP from site "ftp.vortex.com",
  60. in the "/privacy" directory.  Use the FTP login "ftp" or "anonymous", and
  61. enter your e-mail address as the password.  The typical "README" and "INDEX"
  62. files are available to guide you through the files available for FTP
  63. access.  PRIVACY Forum materials may also be obtained automatically via
  64. e-mail through the listserv system.  Please follow the instructions above
  65. for getting the listserv "help" information, which includes details
  66. regarding the "index" and "get" listserv commands, which are used to access
  67. the PRIVACY Forum archive.  
  68.  
  69. All PRIVACY Forum materials are available through the Internet Gopher system
  70. via a gopher server on site "gopher.vortex.com".  Access to PRIVACY Forum
  71. materials is also available through the Internet World Wide Web (WWW) via
  72. the Vortex Technology WWW server at the URL: "http://www.vortex.com";
  73. full keyword searching of all PRIVACY Forum files is available via
  74. WWW access.
  75. -----------------------------------------------------------------------------
  76.  
  77. VOLUME 05, ISSUE 20
  78.  
  79.    Quote for the day:
  80.  
  81.      "A stereo's a stereo.  Art is forever."
  82.  
  83.             -- Neil (Cheech Marin)
  84.                "After Hours" (Geffen/Warner Bros.; 1985)
  85.  
  86. ----------------------------------------------------------------------
  87.  
  88. Date:    Sun, 27 Oct 96 16:55 PST
  89. From:    lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
  90. Subject: Postal "Change of Address" Issues on PRIVACY Forum Radio
  91.  
  92. Greetings.  The next installment of PRIVACY Forum Radio is now available for
  93. your listening pleasure.  This latest show features two interviews I
  94. recently conducted related to controversies surrounding U.S. mail "change of
  95. address" issues.  The first interview is with Mike Selnick of the United
  96. States Postal Service in Washington D.C, regarding commercial use of change
  97. of address data.  This is followed by John Brugger of the United States
  98. Postal Inspection Service (also in D.C.) on the topic of fraudulent
  99. activities related to change of address filings.  
  100.  
  101. The total running time of the show is approximately 30 minutes.
  102. As always, these interviews are accessible at the 
  103. PRIVACY Forum/PRIVACY Forum Radio links via:
  104.  
  105. http://www.vortex.com
  106.  
  107. --Lauren--
  108.  
  109. ------------------------------
  110.  
  111. Date:    Fri, 11 Oct 96 11:13 PDT
  112. From:    lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
  113. Subject: Web Search Service Exposes Searches to Public Viewing
  114.  
  115. In a new twist related to privacy problems, one of the more major Web search
  116. services, the "Magellan Internet Guide" from the Mckinley Group, Inc.
  117. (http://www.mckinley.com), has implemented a feature which allows anyone to
  118. "spy" on other people's searches.  Called the "Search Voyeur", the mechanism
  119. automatically shows the text of 20 current, randomly selected searches,
  120. refreshed every 20 seconds.  They certainly haven't been trying to hide it;
  121. it was prominently mentioned in one of their press releases.
  122.  
  123. While origin address information is not included, and they say they don't
  124. show searches that go beyond their "editorial guidelines" (presumably an
  125. obscenity filter), even a brief viewing of the searches flying by suggests a
  126. substantial privacy risk.  Search keywords often include individuals' names
  127. associated with various actions or activities.  While some of the searches
  128. can best be described as "amusing", it doesn't take too long to see others
  129. that are troubling at best and potentially significant privacy violations at
  130. worst.
  131.  
  132. While the "Search Voyeur" is listed (without explanation) as a link
  133. on their home page along with a search form box, there is no explicit
  134. statement warning users that their searches could potentially be
  135. viewed by anyone on the net.  
  136.  
  137. The entire concept seems ill-advised.  The PRIVACY Forum has made repeated
  138. email and telephone attempts to obtain any kind of statement or interview
  139. from McKinley (and their new owner, Excite, Inc.) about this issue.  These
  140. attempts have so far been completely unsuccessful; email has been
  141. ignored and promised return phone calls have not been forthcoming.
  142.  
  143. --Lauren--
  144.  
  145. ------------------------------
  146.  
  147. Date:    Sun, 27 Oct 96 15:15 PST
  148. From:    lauren@vortex.com (Lauren Weinstein; PRIVACY Forum Moderator)
  149. Subject: "Holographic" Full-Body Security Scanning
  150.  
  151. According to an article in the Oct-Nov 1996 issue of "Compressed Air"
  152. magazine (a wonderful Ingersoll-Rand publication that covers a very wide
  153. range of topics), the Federal Aviation Administration is planning to begin
  154. testing the use of a full-body "holographic" imaging system at a U.S.
  155. airport next year.  
  156.  
  157. The system (an earlier version of which was discussed previously in the
  158. PRIVACY Forum), actually uses millimeter waves (~30 Ghz) to quickly (within
  159. a few seconds) generate a "naked" image of the scannee.  The device has been
  160. under development for a number of years and appears to be evolving rapidly.
  161. The transmitted millimeter radiation passes through clothes but bounces off
  162. the body or other objects (e.g., everything from loose change to firearms,
  163. hidden money packets, etc.)
  164.  
  165. Outside of the rather obvious broader privacy implications of such a device,
  166. two special issues should also be considered.  First, even though the
  167. millimeter radiation used is non-ionizing (e.g. less energetic than x-rays),
  168. there is considerable controversy about the health risks of exposure to
  169. non-ionizing radiation at these wavelengths.  The statement is made that the
  170. system is similar in exposure to supermarket "door opener" microwave
  171. scanners, though this seems somewhat difficult to accept given the
  172. completely different scanning requirements of the two devices.
  173.  
  174. But another problem may be even more likely to concern the public at large
  175. about such equipment.  As the photographs included with the article show all
  176. too clearly, the device generates quite detailed "nude" images.  It is
  177. decidedly uncertain how people will feel about being required to pass
  178. through a system that creates instant 360 degree naked pictures, possibly
  179. archived to tape as well!  The promoters of the system suggest that using
  180. "same-sex" operators would alleviate these concerns.  Excuse me, but are we
  181. all living on the same planet?  Talk about needing a reality check...
  182.  
  183. I have no doubt that there might be special situations where such a device,
  184. as an alternative to "pat-downs" or other intrusive personal searches, could
  185. be useful.  But broadscale deployment of such systems in airports as a
  186. routine body scanning procedure seems unlikely to be acceptable to most of
  187. the public.
  188.  
  189. --Lauren--
  190.  
  191. ------------------------------
  192.  
  193. Date:    Tue, 15 Oct 96 10:28:11 PDT
  194. From:    joe@synaptics.com (Joe Decker)
  195. Subject: Re: Blood and Privacy?
  196.  
  197. John Levine wrote:
  198. > * The Red Cross seems to use a scheme where they accept blood from pretty
  199. > much anyone, but if your blood flunks a test they'll silently discard all
  200. > future donations from you.  I presume this is one of the main impetuses for
  201. > the SSN tagging.  Of course, since they make no attempt to verify the SSN you
  202. > provide, a bad guy who had contaminated blood and wanted to subvert their
  203. > system need only make up a different SSN on each visit.
  204.  
  205. Yes, it is my understanding as a long-time blood donator that the discarding
  206. process is the impetus for the SSN tagging.
  207.  
  208. One nit:  I don't believe that the Red Cross is trying to catch
  209. malicious people trying to subvert the blood supply.  I believe their
  210. primary concern is trying to minimize the risk of someone donating
  211. blood that has any chance of being (say) HIV-positive.  Even if told
  212. their blood had tested positive, a dontator might later decide their
  213. blood was safe on the basis of other tests, or their own faith, and
  214. work to donate their blood anyhow.  This is a distinct mindset from
  215. 'I'm trying to subvert the blood supply.', and without knowing numbers,
  216. many of the checks in the donation process seemed to be aimed at
  217. overcoming the ability of the donator to deny (to themselves or others)
  218. any risks their blood might contain.
  219.  
  220. (I do not speak for the Red Cross.)
  221.  
  222.     --joe
  223.  
  224. joe@synaptics.com  decker@alumni.caltech.edu  jdecker@pacbell.net        
  225.  
  226. ------------------------------
  227.  
  228. Date:    Tue, 22 Oct 1996 03:41:13 -0400
  229. From:    Monty Solomon <monty@roscom.COM>
  230. Subject: A new attack on DES 
  231.  
  232. Excerpt from RISKS DIGEST 18.54
  233.  
  234. Date: Fri, 18 Oct 1996 16:58:50 +0200
  235. From: Shamir Adi <shamir@wisdom.weizmann.ac.il>
  236. Subject: A new attack on DES 
  237.  
  238. You have recently referred in RISKS [18.50, 18.52] to the ingenious new
  239. attack against public key cryptosystems developed at Bellcore. All the
  240. published information on the subject (including Bellcore's press release)
  241. stress that the attack is not applicable to secret key cryptosystems.  Well,
  242. Eli Biham and I have just released a research announcement in which we show
  243. that an extension of the attack can, under the same realistic fault model,
  244. break almost any secret-key algorithm, including DES, multiple DES, IDEA,
  245. etc. The attack on DES was actually implemented on a PC, and it found the
  246. key by analysing fewer than 200 ciphertexts generated from unknown
  247. cleartexts.
  248.  
  249. Adi Shamir
  250.  
  251. = = = = = =
  252.  
  253. Research announcement: A new cryptanalytic attack on DES
  254.  
  255. Eli Biham                                 Adi Shamir
  256. Computer Science Dept.                    Applied Math Dept.
  257. The Technion                              The Weizmann Institute
  258. Israel                                    Israel
  259.  
  260.                  18 October 1996
  261.                      (DRAFT)
  262.  
  263. In September 96, Boneh Demillo and Lipton from Bellcore announced an
  264. ingenious new type of cryptanalytic attack which received widespread
  265. attention (see, e.g., John Markoff's 9/26/96 article in the New York Times).
  266. Their full paper had not been published so far, but Bellcore's press release
  267. and the authors' FAQ (available at
  268. http://www.bellcore.com/PRESS/ADVSRY96/medadv.html) specifically state that
  269. the attack is applicable only to public key cryptosystems such as RSA, and
  270. not to secret key algorithms such as the Data Encryption Standard (DES).
  271. According to Boneh, "The algorithm that we apply to the device's faulty
  272. computations works against the algebraic structure used in public key
  273. cryptography, and another algorithm will have to be devised to work against
  274. the nonalgebraic operations that are used in secret key techniques." In
  275. particular, the original Bellcore attack is based on specific algebraic
  276. properties of modular arithmetic, and cannot handle the complex bit
  277. manipulations which underly most secret key algorithms.
  278.  
  279. In this research announcement, we describe a related attack (which we call
  280. Differential Fault Analysis, or DFA), and show that it is applicable to
  281. almost any secret key cryptosystem proposed so far in the open literature.
  282. In particular, we have actually implemented DFA in the case of DES, and
  283. demonstrated that under the same hardware fault model used by the Bellcore
  284. researchers, we can extract the full DES key from a sealed tamperproof DES
  285. encryptor by analysing fewer than 200 ciphertexts generated from unknown
  286. cleartexts.  The power of Differential Fault Analysis is demonstrated by the
  287. fact that even if DES is replaced by triple DES (whose 168 bits of key were
  288. assumed to make it practically invulnerable), essentially the same attack
  289. can break it with essentially the same number of given ciphertexts.
  290.  
  291. We would like to greatfully acknowledge the pioneering contribution of Boneh
  292. Demillo and Lipton, whose ideas were the starting point of our new attack.
  293.  
  294. In the rest of this research announcement, we provide a short technical
  295. summary of our practical implementation of Differential Fault Analysis of 
  296.  
  297. DES. Similar attacks against a large number of other secret key cryptosystems
  298. will be described in the full version of our paper.
  299.  
  300. TECHNICAL DETAILS OF THE ATTACK
  301.  
  302. The attack follows the Bellcore fundamental assumption that by exposing a
  303. sealed tamperproof device such as a smart card to certain physical effects
  304. (e.g., ionizing or microwave radiation), one can induce with reasonable
  305. probability a fault at a random bit location in one of the registers at some
  306. random intermediate stage in the cryptographic computation. Both the bit
  307. location and the round number are unknown to the attacker.
  308.  
  309. We further assume that the attacker is in physical possession of the
  310. tamperproof device, so that he can repeat the experiment with the same
  311. cleartext and key but without applying the external physical effects. As a
  312. result, he obtains two ciphertexts derived from the same (unknown) cleartext
  313. and key, where one of the ciphertexts is correct and the other is the result
  314. of a computation corrupted by a single bit error during the computation. For
  315. the sake of simplicity, we assume that one bit of the right half of the data
  316. in one of the 16 rounds of DES is flipped from 0 to 1 or vice versa, and
  317. that both the bit position and the round number are uniformly distributed.
  318.  
  319. In the first step of the attack we identify the round in which the fault
  320. occurred.  This identification is very simple and effective: If the fault
  321. occurred in the right half of round 16, then only one bit in the right half
  322. of the ciphertext (before the final permutation) differs between the two
  323. ciphertexts. The left half of the ciphertext can differ only in output bits
  324. of the S box (or two S boxes) to which this single bit enters, and the
  325. difference must be related to non-zero entries in the difference
  326. distribution tables of these S boxes.  In such a case, we can guess the six
  327. key bit of each such S box in the last round, and discard any value which
  328. disagree with the expected differences of these S boxes (e.g., differential
  329. cryptanalysis). On average, about four possible 6-bit values of the key
  330. remain for each active S box.
  331.  
  332. If the faults occur in round 15, we can gain information on the key bits
  333. entering more than two S boxes in the last round: the difference of the
  334. right half of the ciphertext equals the output difference of the F function
  335. of round 15.  We guess the single bit fault in round 15, and verify whether
  336. it can cause the expected output difference, and also verify whether the
  337. difference of the right half of the ciphertext can cause the expected
  338. difference in the output of the F function in the last round (e.g., the
  339. difference of the left half of the ciphertext XOR the fault).  If
  340. successful, we can discard possible key values in the last round, according
  341. to the expected differences.  We can also analyse the faults in the 14'th
  342. round in a similar way.  We use counting methods in order to find the key.
  343. In this case, we count for each S box separately, and increase the counter
  344. by one for any pair which suggest the six-bit key value by at least one of
  345. its possible faults in either the 14'th, 15'th, or 16'th round.
  346.  
  347. We have implemented this attack on a personal computer.  Our analysis
  348. program found the whole last subkey given less than 200 ciphertexts,
  349. with random single-faults in all the rounds.
  350.  
  351. This attack finds the last subkey.  Once this subkey is known, we can
  352. proceed in two ways: We can use the fact that this subkey contains 48 out of
  353. the 56 key bits in order to guess the missing 8 bits in all the possible
  354. 2^8=256 ways. Alternatively, we can use our knowledge of the last subkey to
  355. peel up the last round (and remove faults that we already identified), and
  356. analyse the preceding rounds with the same data using the same attack. This
  357. latter approach makes it possible to attack triple DES (with 168 bit keys),
  358. or DES with independent subkeys (with 768 bit keys).
  359.  
  360. This attack still works even with more general assumptions on the fault
  361. locations, such as faults inside the function F, or even faults in the key
  362. scheduling algorithm.  We also expect that faults in round 13 (or even prior
  363. to round 13) might be useful for the analysis, thus reducing the number of
  364. required ciphertext for the full analysis.
  365.  
  366. OTHER VULNERABLE CIPHERS
  367.  
  368. Differential Fault Analysis can break many additional secret key
  369. cryptosystems, including IDEA, RC5 and Feal.  Some ciphers, such as Khufu,
  370. Khafre and Blowfish compute their S boxes from the key material.  In such
  371. ciphers, it may be even possible to extract the S boxes themselves, and the
  372. keys, using the techniques of Differential Fault Analysis.  Differential
  373. Fault Analysis can also be applied against stream ciphers, but the
  374. implementation might differ by some technical details from the
  375. implementation described above.
  376.  
  377. ------------------------------
  378.  
  379. Date:    Mon, 14 Oct 1996 10:50:00 -0400
  380. From:    Mary Ellen Zurko <zurko@osf.org>
  381. Subject: IEEE Symposium on Security and Privacy - call for papers
  382.  
  383.                            CALL FOR PAPERS
  384.    
  385. 1997 IEEE Symposium on                              May 4-7, 1997
  386. Security and Privacy                            Oakland, California
  387.   
  388.                              sponsored by
  389.   IEEE Computer Society Technical Committee on Security and Privacy
  390.                          in cooperation with
  391.     The International Association for Cryptologic Research (IACR)
  392.  
  393. The Symposium on Security and Privacy has, for 16 years, been the
  394. premier forum for the presentation of developments in computer
  395. security and for bringing together researchers and practitioners in the
  396. field.  We seek to build on this tradition of excellence by
  397. re-emphasizing work on engineering and applications while maintaining
  398. our interest in theoretical advances. 
  399.  
  400. We continue to seek to broaden the scope of the Symposium.  We want to
  401. hear not only about new theoretical results, but also about the design
  402. and implementation of secure systems in specific application areas and
  403. about policies relating to system security.  We are particularly
  404. interested in papers on policy and technical issues relating to privacy
  405. in the context of the information infrastructure, papers that relate
  406. software and system engineering technology to the design of secure
  407. systems and papers on hardware and architectural support for secure
  408. systems. Papers or Panels which discuss the application of theory to
  409. practice which describe not only the successes but the failures and
  410. the lessons learned are of special interest.
  411.  
  412. Topics on which papers and panel sessions proposals are invited
  413. include, but are not limited to, the following:
  414.  
  415.         Commercial and Industrial Security,
  416.         Security and other Critical System Properties,
  417.         Secure Systems,
  418.         Distributed Systems,
  419.         Network Security,
  420.         Database Security,
  421.         Data Integrity,
  422.         Access Controls,
  423.         Information Flow ,
  424.         Security Verification,
  425.         Viruses and Worms,
  426.         Security Protocols,
  427.         Authentication,
  428.         Biometrics,
  429.         Smartcards,
  430.         Auditing,
  431.         Intrusion Detection,
  432.         Privacy Issues,
  433.         Policy Modeling
  434.  
  435. A continuing feature of the symposium will be a session of 5-minute
  436. talks. We want to hear from people who are advancing the field in the
  437. areas of system design and implementation, but may lack the resources
  438. needed to prepare a full paper. Abstracts of these talks will be
  439. distributed at the Symposium. 
  440.  
  441. INSTRUCTIONS FOR AUTHORS: 
  442. This year we are instituting mechanisms for "electronic" submission
  443. of papers for the refereeing process. Final papers will still be
  444. submitted in hard copy. 
  445.  
  446. We will continue to accept papers submitted via various forms of mail,
  447. but not fax.  Papers should include an abstract, must not exceed 7500
  448. words, and must report original work that has not been published
  449. previously and is not under consideration for publication
  450. elsewhere. The names and affiliations of authors should appear on a
  451. separate cover page only, as "blind" refereeing is used. Authors must
  452. certify prior to December 27, 1996 that all necessary clearances for
  453. publication have been obtained. The committee strongly encourages
  454. authors to include archival sources as references (books, journal
  455. articles, etc.) and to include references to "WEB" or other "NET"
  456. sources only if they can be backed up by some archival source. In this
  457. way, we can ensure that people who read the paper 5 years from now
  458. will have access to the information used as background and
  459. justification of the arguments presented.
  460.  
  461. Panel proposals should include a title, an abstract which describes
  462. the topic(s) to be discussed, the names of all proposed participants
  463. and assurances that the participants agree to serve on the panel, a
  464. proposed length and format for the panel and any other information
  465. that the panel proposer thinks would support their proposal. We will
  466. publish the Panel Abstract in the Proceedings as well as any position
  467. papers submitted by the panelists in support of the panel proposal.
  468.  
  469. Those submitting papers via "hard copy" should send six copies of
  470. their paper or panel proposal to:
  471.  
  472. George W. Dinolt, Program Co-Chair 
  473. Lockheed Martin Western Development Laboratories, 
  474. Mail Stop X20, 
  475. 3200 Zanker Road, 
  476. San Jose, CA 95134. 
  477.  
  478. Please mark the envelope "IEEE Security and Privacy Symposium." 
  479.  
  480. The title, abstract and authors names should be on a separate cover
  481. page so that we can support the "blind refereeing process." We would
  482. also like to have an electronic, ascii text version of the abstract
  483. sent seperately to secprv97@wdl.lmco.com. The electronic version of
  484. the abstract should include the title and the abstract as it appears
  485. in the paper.
  486.  
  487. Authors who wish to submit an electronic version of a paper or panel proposal 
  488. for evaluation should follow the instructions that will be posted
  489. on our "Web" site at 
  490.  
  491. <a href=http://www.itd.nrl.navy.mil/ITD/5540/ieee>
  492. http://www.itd.nrl.navy.mil/ITD/5540/ieee</a>
  493.  
  494. or by sending mail to secprv97@wdl.lmco.com with the word
  495. "Instructions" in the Subject line. Instructions will be included in
  496. the reply.  Papers and panel proposals must be received (however sent)
  497. by 6:00 P.M. (PST) on Monday Dec. 2, 1996 (The deadline has been
  498. extended from the original call). Authors will be notified by
  499. mid-January about the status of their papers.
  500.  
  501. Authors who submit an abstract for a 5-minute talk should include a
  502. title, all authors names and their affiliations, where appropriate,
  503. and text. The whole should fit easily on one 8.5" by 11" page.
  504. Abstracts for 5-minute talks should be sent to George W. Dinolt at the
  505. above address U.S. Postal address to be received no later than Friday,
  506. April 19, 1997 at 6:00 P.M local time. We will review abstracts and
  507. accept as many as we can. Please mark the envelope
  508.  
  509. "IEEE Security and Privacy Symposium - 5 minute Abstracts"
  510.  
  511. General Chair: Steve Kent,  BBN, USA
  512. Vice Chair: Mike Reiter, AT&T Laboratories - Research, USA
  513. Program Co-Chairs: George Dinolt, Lockheed Martin WDL, USA
  514.            Paul Karger, IBM, USA
  515. Treasurer:    Charlie Payne, SCTC, USA
  516.  
  517. Program Committee:
  518. Deborah Cooper, The DMC Company
  519. Terry Vickers Benzel, Trusted Information Systems
  520. Lee Benzinger, Lockheed Martin WDL
  521. Yair Frankel, Sandia Labs
  522. Li Gong, Sun Microsystems
  523. Heather Hinton, Ryerson Polytechnic University Canada
  524. Cynthia Irvine, Naval Postgraduate School
  525. Suchil Jajodia, George Mason University
  526. Dale Johnson, MITRE
  527. Carl Landwehr, Naval Research Laboratory
  528. Teresa Lunt, DARPA/ITO 
  529. John McHugh, Portland State University
  530. John McLean, Naval Research Laboratory
  531. Catherine A. Meadows, Naval Research Laboratory
  532. Richard B. Neely, CTA
  533. Richard E. Newman-Wolfe, Univeristy of Florida
  534. Sylvan Pinsky, National Security Agency
  535. Sue Rho, Trusted Information Systems
  536. Mike Reiter,AT&T Laboratories --- Research 
  537. Peter Ryan, DRA Malvern, United Kingdom
  538. Pierangela Samarati, Universita' di Milano, Italy
  539. Tom Schubert, Portland State University
  540. Elisabeth Sullivan, Sequent
  541. Paul Syverson, Naval Reseach Laboratory
  542. Tom Van Vleck, CyberCash Inc. 
  543. Shyhtsun F. Wu, North Carolina State University
  544. Mary Ellen Zurko, OSF
  545.  
  546. ------------------------------
  547.  
  548. End of PRIVACY Forum Digest 05.20
  549. ************************
  550.