home *** CD-ROM | disk | FTP | other *** search
/ DP Tool Club 17 / CD_ASCQ_17_101194.iso / vrac / rsik1636.zip / RSIK1636.TXT < prev   
Text File  |  1994-09-11  |  31KB  |  655 lines

  1.          FORUM ON RISKS TO THE PUBLIC IN COMPUTERS AND RELATED SYSTEMS 
  2.    ACM Committee on Computers and Public Policy, Peter G. Neumann, moderator
  3.  
  4. ***** See last item for information on RISKS (comp.risks) *****
  5.  
  6.   Contents:
  7. Vandals Cut Cable, Slow MCI Service (Mich Kabay)
  8. Mexican election computers (John Sullivan)
  9. Attack of the killer spellcheckers... (Valdis Kletnieks)
  10. U.S. Mail causes ZIP-code problem (Al Stangenberger)
  11. Re: Bug in Microsoft Word (Dave Moore)
  12. Salt in wounds (Re: New Cray and Unix Passwords...) (Peter Wayner)
  13. Re: Fraud and Identity -- SCI-FI (Andrew Marchant-Shapiro)
  14. Politicians Join the Internet (Mich Kabay)
  15. Re: pi = 3 (Mark Stalzer, Rob Boudrie)
  16. System makes bank check forgery easy (Christopher Klaus)
  17. CFP: 2nd ACM Conference on Computer and Communications Security (Li Gong)
  18. Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.  
  19.  
  20. ----------------------------------------------------------------------
  21.  
  22. Date: 28 Aug 94 13:12:43 EDT
  23. From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
  24. Subject: Vandals Cut Cable, Slow MCI Service
  25.  
  26. >From the Washington Post newswire (94.08.27):
  27.  
  28. VANDALS CUT CABLE, SLOW MCI SERVICE
  29.  
  30.  By Elizabeth Corcoran 
  31.  Washington Post Staff Writer 
  32.  
  33.     "Telephone calls between New York City and Washington on the MCI network
  34. encountered traffic jams yesterday afternoon after vandals removed a segment
  35. of
  36. cable in Newark. The problems began just before 2 p.m. and lasted until 5:45
  37. p.m. 
  38.     "MCI Communications Corp. spokesman Jim Collins said vandals `neatly cut'
  39. out a 20-foot segment of fiber-optic cable that ran along a railroad overpass
  40. above a street in Newark. The cable, which was wrapped in a thin plastic
  41. casing, was not easy to reach."
  42.  
  43. The article continues with the following key points:
  44.  
  45. o Repairs took about an hour after the break was located.
  46.  
  47. o NJ residents, in particular, got many busy signals when alternative
  48. routes were saturated.
  49.  
  50. o Brokers on the NASDAQ exchange, including Dow Jones, were affected.
  51.  
  52. o Motives for the theft of 20 feet of fiber optic cable are unknown.
  53.  
  54. [Comments by MK:  could this be a dry run for a class-3 (international)
  55. information warfare attack?  "Let's see what happens when we deliberately
  56. interfere with one of the major carriers...."]
  57.  
  58. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn
  59.  
  60. ------------------------------
  61.  
  62. Date: Fri, 26 Aug 94 13:21:42 -0500
  63. From: sullivan@geom.umn.edu
  64. Subject: Mexican election computers
  65.  
  66. RISKS readers will recall that six years ago, the Mexican ruling party PRI
  67. evidently stole the presidential election through tricks with the
  68. vote-counting computer.
  69.  
  70. Last month, the Economist had an article about preparations for the elections
  71. this year in Mexico.  Their reporter interviewed a government official in
  72. charge of elections; when he asked about the computer irregularities six years
  73. ago, the interview was abruptly ended.
  74.  
  75. It seems that the elections this year were more open and fair than those six
  76. years ago.  But there have been some questions raised again about the computer
  77. system.  The IFE (Federal Electoral Institute) has delayed releasing the final
  78. vote totals.  PRI representatives say the delay is because the PRD (opposition
  79. party) is demanding recounts of each ballot box.  But, according to Reuters,
  80. PRD representatives to the IFE claim instead that the delays were "due to
  81. suspicious problems with the official computer system".  The Reuters report
  82. continues to say that:
  83.  
  84.        IFE officials denied Thursday there were any problems with
  85.     the computer system but said an investigation was continuing
  86.     into an apparent effort by unknown individuals to infiltrate a
  87.     computer virus into the main electoral computer.
  88.        Interior Minister Jorge Carpizo said Wednesday that
  89.     investigators had found some clues indicating who might have
  90.     been responsible for the effort but did not say who they were or
  91.     whether the effort was politically motivated or not.
  92.  
  93. John Sullivan     sullivan@geom.umn.edu
  94.  
  95. ------------------------------
  96.  
  97. Date: 26 Aug 1994 18:53:21 GMT
  98. From: valdis@black-ice.cc.vt.edu (Valdis Kletnieks)
  99. Subject: Attack of the killer spellcheckers...
  100.  
  101. Seen on page 2 of the New River Valley Current section of the
  102. Roanoke Times & World-News, Aug 24, 1994:
  103.  
  104. Corrections:
  105.  
  106.    Because of an overzealous computer spellchecker, a number of names in a
  107. story on Radford University sports in the Welcome Students section appeared
  108. incorrectly and were not caught by a sports-ignorant editor.
  109.  
  110.    Phil Leftwich is the former Highlander now in the pros.  Chris Connolly
  111. plays ball in WIlmington, Del., not Laminating, Del., and there's no such
  112. place as Educator, Ga. -- Eric Parker is from Decatur.  Chibi Johnson is not
  113. in the least bit Chubby, and Done Staley is legendary, not Don Stellae.
  114. Meanwhile, Paul Beckwith, who is no relation to Paul Backwash, departed for
  115. Cornell.
  116.  
  117.    Because of a reporter's error, a story in Saturday's New River Current
  118. incorrectly reported a July 20 vote by the Montgomery County Planning
  119. Commission on a Price Mountain tower proposal.  The vote only recommended the
  120. proposal for a public hearing.  But by a 5-4 vote, the commission recommended
  121. approval of the tower Monday.  The Board of Supervisors will consider it next
  122. month.
  123.  
  124. .....
  125.  
  126. The obvious first-order RISK is of course not keeping your spellchecker in
  127. line.  However, the following should also be noted:
  128.  
  129. 1) The correction contained the WIlmington with an upper-case 'I' - there's
  130. nothing like having a typo in an apology for an errant spellchecker.
  131.  
  132. 2) The first 2 paragraphs have an unusual amount of levity - the third is
  133. reprinted as a sample of their usual correction style.  One almost needs to
  134. wonder if in fact, the original error never happened, and that the retraction
  135. is itself a creation of an AI gone amuck... ;)
  136.  
  137. Valdis Kletnieks, Computer Systems Engineer
  138.  
  139. ------------------------------
  140.  
  141. Date: Sat, 27 Aug 1994 13:37:23 -0700
  142. From: Al Stangenberger <forags@nature.Berkeley.EDU>
  143. Subject: U.S. Mail causes ZIP-code problem
  144.  
  145. Residents of Oak Avenue in San Rafael, CA, are victims of a burgeoning mail
  146. problem caused when their street was "inadvertently" deleted from the Postal
  147. Service's national ZIP code database.  San Rafael has several ZIP codes for
  148. various areas;  two of these (94901 and 94904) have Oak Avenues with similar
  149. street numbers.  Somehow the Oak Avenue in 94901 was deleted from the master
  150. database of streets, and this deletion was propagated to all commercial 
  151. mailers in the USA who subscribe to the Post Office's ZIP code update service.
  152. The result of the deletion was that commercial mail programs automatically
  153. changed all Oak Avenue addresses in code 94901 to the Oak Avenue in 94904.
  154. The resulting flood of misdirected mail has caused the usual problems 
  155. associated with missing bills, mortgage statements, etc.  Further, any
  156. ZIP code changes back to 94901 requested when residents discovered this
  157. error were automatically "corrected" back to 94904 by the programs which
  158. relied on the Post Office's bad data.  This situation will persist until the
  159. next revision tapes for the national ZIP database are distributed.
  160.  
  161. The article I saw (Marin Independent-Journal, 12 August 1994) did not explain
  162. how a record was "inadvertently" deleted from the national database. I 
  163. checked a printed ZIP code directory for San Rafael, and saw at least four
  164. other pairs of streets which could also have fallen victim to the problem.
  165. Fortunately, they did not.
  166.  
  167. Until the problem is fixed, Oak Avenue mail is being manually sorted.
  168.  
  169. Al Stangenberger  Univ. of Calif Berkeley Dept. of Env. Sci., Policy, & Mgt.
  170. forags@nature.berkeley.edu            
  171.  
  172. ------------------------------
  173.  
  174. Date: Thu, 25 Aug 1994 14:20:37 -0400 (EDT)
  175. From: Dave Moore <davem@garnet.spawar.navy.mil>
  176. Subject: Re: Bug in Microsoft Word
  177.  
  178. >>Word has a summary info area, for each document, that cannot be turned off.
  179.  
  180. I wasn't aware of this specifically, but there is a much more substantial but
  181. similar feature that I encountered in version 4.x & 5.x of Word for the Mac.
  182. I suspect that it exists in the PC versions as well but have not checked.
  183. Fortunately, it's easy to test it yourself.  Just create a Word file.  Save it
  184. with "Fast Save".  Re-open the file, delete something and save again with
  185. fast-save.  Now use any external file viewer and look for your deleted text.
  186.  
  187. The following is an internal memo I sent out a couple of years ago:
  188.  
  189.                     --------------------------
  190.  
  191. Do you send WORD files via e-mail ?  If so, be aware that you may be
  192. accidentally sending out your underwear along with your intended message.
  193.  
  194.         <Dramatic pause for puzzlement and underwear checking>
  195.  
  196. The default configuration in WORD for file saving is "Fast Save".  The way
  197. this works is it only saves a list of edits and appends them to the existing
  198. file.  When this file is opened, only the end result is displayed. However
  199. when you send this file via e-mail, the entire file is sent.
  200.  
  201. So what does this mean ?  It means that if you use Word to delete stuff that
  202. you change or that you don't intend to send or be seen; the supposedly deleted
  203. stuff may still be present in the file.  The recipient of that file may be
  204. able to recover some or all of the deleted information.
  205.  
  206. Under ordinary usage, this is not a problem.  Recovery of deleted text by the
  207. recipient requires some specific knowledge and time.  For obvious reasons, I
  208. won't explain the method.
  209.  
  210. If you have some specific reason to be sure that no deleted text can be
  211. recovered, turn off Fast Save prior to saving for transmittal.  Otherwise,
  212. your underwear may be visible.
  213.  
  214.                           ---------------
  215.  
  216. Actually recovery is not difficult at all, but the above was intended for 
  217. a non-technical audience.
  218.  
  219. ------------------------------
  220.  
  221. Date: Fri, 26 Aug 1994 09:54:31 -0400
  222. From: pcw@access.digex.net (Peter Wayner)
  223. Subject: Salt in wounds (Followup to new Cray and Unix Passwords...)
  224.  
  225. One should be careful pushing the envelope while calculating on the back of
  226. it. I made one misstep in my piece in RISKS-16.34 when I stated that 1000
  227. passwords could be attacked as easily as one. I neglected to take account of
  228. the Salt, which is a neat part of the UNIX password system that effectively
  229. increases the size of the password space by a factor of 1024.
  230.  
  231. If you are attacking one password, then the time limits from the earlier
  232. piece still hold if you're able to guess the salt ahead of time. This
  233. may not be possible and it certainly isn't possible if you're trying
  234. to use the "neat" trick of compare 1000 passwords in one swell FLOP. 
  235.  
  236. There are additional weaknesses that should be pointed out. If people only use
  237. lower-case characters and numbers, then the size of the key space is even
  238. smaller. This is only 36^8 possible choices which is about 1/76th the size of
  239. the space made up of {A-Z,a-z,0-9}.
  240.  
  241. But who uses digits? Many don't. The number of 8 character passwords made
  242. up of just lower-case letters can be searched about 1026 times faster. That's
  243. less than an hour given the rough estimates. This pretty close to the 
  244. size of the salt so the two cancel each other out and the running times
  245. from the previous post would apply here. This emphasizes the need for
  246. using different cases, numbers and punctuation in the password. 
  247.  
  248. When people use DES manually, they often just type in the key like a password.
  249. (Many of the automatic systems choose keys randomly from the entire key
  250. space.)  If this is the case, then all of the estimates from the earlier piece
  251. in 16.34 also apply to this case without having to worry about the salt.
  252. Clearly, any new standard encryption algorithm should include a method for
  253. hashing a longer phrase down to a shorter key in such a way that the entire
  254. keyspace is covered.
  255.  
  256. Finally, some have asked about shadow password files, a common UNIX system
  257. hack that prevents ordinary users from access to the password file that used
  258. to be kept open for all to read. It is unclear how common these are, but this
  259. problem is really independent of the problem of attacking encrypted passwords.
  260. People can get at encrypted passwords by sniffing the network as well as a
  261. variety of other file system hacks. If the users could never get at encrypted
  262. passwords, we wouldn't need to encrypt the passwords anymore.
  263.  
  264. I should point out again that my estimates of about the Cray came from thin
  265. air. I have no direct knowledge of the exact architecture of the machine or
  266. many of the small and medium sized details that could impose factors of 2 or 4
  267. on the results.
  268.  
  269. There are several other details. Although most focus their paranoia on the
  270. NSA, there are many others who might come to own such a machine. The Cray
  271. computer eventually emerging from this project should be available on the open
  272. market. It will undoubtably have many uses in many arenas. The memory
  273. architecture may grow to be popular in desktop machines because it can be used
  274. to do ray tracing, CAD applications and many other computational projects.
  275. Other Cray innovations are now common on desktop machines. That may be well
  276. into the future, but concentrating on that is one way to keep from getting
  277. mired in the past.
  278.  
  279. ------------------------------
  280.  
  281. Date: 25 Aug 94 14:58:00 EST
  282. From: "MARCHANT-SHAPIRO, ANDREW" <MARCHANA@gar.union.edu>
  283. Subject:  Re: Fraud and Identity -- SCI-FI (Kabay, RISKS-16.35)
  284.  
  285. MK writes:
  286. >And will such tokens become valuable
  287. >commodities--valuable enough to steal and trade in the underworld?  Sounds
  288. >like the subject for an interesting science fiction novel.]
  289.  
  290. I recall at least once SciFi story in which eyeballs are removed to trick
  291. retinal scanners (that is, you remove someone ELSE's eyeball, and hold
  292. it up to the scanner...not at all nice!).
  293.  
  294. Andrew Marchant-Shapiro, Depts of Sociology and Political Science, Union
  295. College, Schenectady NY 12308   (518) 388-6225  marchana@gar.union.edu
  296.  
  297. ------------------------------
  298.  
  299. Date: 29 Aug 94 07:42:27 EDT
  300. From: "Mich Kabay [NCSA Sys_Op]" <75300.3232@compuserve.com>
  301. Subject: Politicians Join the Internet
  302.  
  303. The Washington Post newswire (94.08.29) reports on the growing use of Internet
  304. services by the US Congress and Senate:
  305.  
  306. "E-Mail Puts Congress At Voters' Fingertips; House, Senate Venturing Onto the
  307. Internet"
  308.  By Elizabeth Corcoran 
  309.  Washington Post Staff Writer 
  310.  
  311.     "When the House of Representatives was weighing an amendment to a bill on
  312. education earlier this year, constituents swamped Rep. Elizabeth Furse's
  313. office with questions and concerns.
  314.     "The Oregon Democrat took to the information highway: Along with
  315. conventional interviews, she posted soothing explanations on various computer
  316. bulletin boards. The uproar died down, and the bill passed."
  317.  
  318. The author makes the following key points:
  319.  
  320. o Growing use of Internet access throughout the US government, including
  321. legislators, support staff, and government employees.
  322.  
  323. o White House plans to put multimedia documents online by mid-September.
  324.  
  325. o "...about 40 representatives and 30 senators have acquired Internet
  326. addresses; about that many more members and committees in both houses have
  327. requested access."
  328.  
  329. o Enthusiasts praise the immediacy of the electronic communications
  330. channel.
  331.  
  332. o Voters can obtain detailed information online about legislation.
  333.  
  334. o Congressional staffers are working on security measures "to protect
  335. its paths onto the Internet from hackers bent on disrupting databases."
  336.  
  337. o Remote voting by legislators is a possibility under discussion for the
  338. long term.
  339.  
  340. [Comments by MK:
  341.  
  342. 1) Disproportionate weight
  343.  
  344. In social psychology, one of the observations about how people form judgements
  345. about issues ("social cognition") is that _salience_ influences judgement.
  346. That is, the unusual, the exceptional, the striking--these factors insensibly
  347. lead us to overestimate their importance.  In experimental work over many
  348. years, psychologists have found that anyone who is noticeably different in a
  349. group picture is assumed unconsciously by observers to have special
  350. importance.
  351.  
  352. Until Internet access becomes more widespread, anyone sending E-mail to a
  353. Congresscritter is likely to be considered with greater interest than someone
  354. sending snailmail--simply because of the novelty.
  355.  
  356. 2) Spoofs
  357.  
  358. Congresscritters naturally weigh public comments with an eye to voter
  359. preferences.  If there 20,000 messages supporting a particular initiative and
  360. 500 opposing it, the recipient may be influenced in favour of the proposal.
  361.  
  362. And how will the congressional staff judge how many people sent the 20,000
  363. messages if there is no authentication of the identity of the senders?  Yes,
  364. fraudsters could go to the trouble of generating thousands of printed messages
  365. and mailing them from the appropriate district (so the postmark would fit).
  366. Mind you, it would be quite a job, what with using different fonts, margins
  367. and wording to simulate the contributions of individual voters.
  368.  
  369. What a contrast with E-mail!  Without public key signatures, a computer
  370. program could generate thousands of E-mail messages using randomizers for the
  371. text and a list of fraudulent identifiers.  Even _with_ public keys, if the
  372. Bad Guys chose to certify thousands of their own pseudonyms, nobody could stop
  373. them--and it is unlikely that Congresscritters would know which keys had been
  374. certified by criminals.
  375.  
  376. 3) Representative democracy
  377.  
  378. Each letter and phone call to a legislative office is assumed to represent the
  379. opinions of many others who have not taken the time to communicate with their
  380. representatives.  The practice of allowing free mail to representatives is
  381. supposed to increase the availability of such communications.
  382.  
  383. What assumptions will legislators make about E-mail?  And what will be the
  384. demographic attributes of E-mail senders?  I think there's scope for some
  385. pretty intensive research here before anyone draws conclusions about the
  386. population sending political E-mail.
  387.  
  388. Legislators must analyze issues, not merely tally indices of popularity.  And
  389. with electronic communications, they must be especially wary of taking the
  390. easy path of vote-counting.  Some of those "voters" may be phantoms, and the
  391. rest may be very different from "normal" voters.
  392.  
  393. Many commentators have suggested that access to the Internet may widen the gap
  394. between the enfranchised intelligentsia and the disenfranchised masses.  As
  395. E-mail links to legislators increase, it will be important to monitor the gap.
  396. If it becomes intolerable, that gap will have to be closed by widening access
  397. to the proposed National Information Infrastructure.]
  398.  
  399. M.E.Kabay,Ph.D./DirEd/Natl Computer Security Assn
  400.  
  401. ------------------------------
  402.  
  403. Date: Thu, 25 Aug 1994 12:49:39 +0800
  404. From: stalzer@macaw.hrl.hac.com
  405. Subject: Re: pi = 3 (RISKS-16.34,35)
  406.  
  407. It doesn't take a law to make pi = 3. On some old versions of Basic for
  408. PDP-11s, you could assign any value to the "constant" pi.  The constant was
  409. contained in a shared run-time system (with write permission!), and changing
  410. it in one program changed it for all Basic programs (until the rts was
  411. reloaded).
  412.  
  413. Mark Stalzer, mas@acm.org
  414.  
  415. ------------------------------
  416.  
  417. Date: Thu, 25 Aug 94 14:39:41 EDT
  418. From: Rob Boudrie <rboudrie@chpc.org>
  419. Subject: More on Pi (RISKS-16.34,35)
  420.  
  421. [The Indiana Pi-throwing] is covered in detail in Peter Beckmann's book "A
  422. History of PI", in which he points out both the incomprehensibility of that
  423. Indiana law, as well as the difficulty in finding Pi=3 in it.  That volume
  424. (available in paperback) is absolute must reading for all of those who at one
  425. time knew Pi to over 200 digits.
  426.                                         rob boudrie
  427.  
  428.    [Also noted by Hal Lewis (hlewis@voodoo.physics.ucsb.edu):
  429.    the book "has lots of other great stories about this remarkable
  430.    number."  PGN]
  431.  
  432. ------------------------------
  433.  
  434. Date: Mon, 29 Aug 94 12:42:54 EDT
  435. From: Christopher Klaus <cklaus@shadow.net>
  436. Subject: system makes bank check forgery easy
  437.  
  438. Here's an obvious risk that I am not sure exists for all banks but here's the
  439. deal:
  440.  
  441. I use to live in dorms and when I opened an account with a local bank,
  442. they sent 3 or 4 packets of checks.  I put the extra packets in my desk.
  443. Unfortunately, my roommates were less than honest and forged a check
  444. for some pizza. I noticed 1 or 2 packets missing so I had the bank stop
  445. payment for all the packets of checks that were missing.  More than 6 months
  446. later, after I moved, I grabbed a packet of checks, and wanted to verify
  447. these were good ones and not ones I had previously stopped payment on.
  448.  
  449. I called up the bank and the lady told me , if the checks had been stopped
  450. payment for more than 6 months, it is automatically purged from the system ,
  451. and are good again.  I asked her, `If I stole a few packets of blank checks
  452. from someone, I could just wait 6 months for the stop payment to roll over in
  453. your system, and begin forging again?'  And she said, `Yea, but not a lot of
  454. people know that.'  Well, gee, that makes me feel safer.
  455.  
  456. I am not sure if this is true for most banks, but I wouldn't be surprised if
  457. it were so.
  458.  
  459. Christopher William Klaus  <cklaus@shadow.net>  <iss@shadow.net>
  460. Internet Security Systems, Inc.         Computer Security Consulting
  461. 2209 Summit Place Drive,              Penetration Analysis of Networks
  462. Atlanta,GA 30350-2430. (404)998-5871.
  463.  
  464. ------------------------------
  465.  
  466. Date: Thu, 25 Aug 94 12:18:21 -0700
  467. From: Li Gong <gong@csl.sri.com>
  468. Subject: CFP: 2nd ACM Conference on Computer and Communications Security
  469.  
  470. This is the first announcement of the upcoming ACM conference [RISKS-pruned].
  471. You can access the full registration information online by E-mail to
  472. acmccs2@isse.gmu.edu or by www file http://www.csl.sri.com/acm-ccs/ccs.html
  473.  
  474.                    Call For Participation
  475.    2nd ACM Conference on Computer and Communications Security
  476.                 Nov 2-4 1994, Fairfax, Virginia
  477.                     Sponsored by: ACM SIGSAC
  478.  
  479.       Hosted by: Bell Atlantic and George Mason University
  480.  
  481.              In cooperation and participation from
  482.         International Association of Cryptologic Research
  483. IEEE Communication Society TC on Network Operations and Management
  484.          IEEE Computer Society TC on Security and Privacy
  485.  
  486.                 Conference Highlights
  487.  
  488. Building on last year's highly successful inaugural conference, we are pleased
  489. to invite your participation in this year's conference. The purpose of the
  490. conference is to bring together researchers and practitioners of computer and
  491. communications security. As evidenced by the program, the conference offers a
  492. unique blend of cryptography and security, theory and practice, with emphasis
  493. on the practical. The conference will be held in the Holiday Inn, Fair Oaks,
  494. in Fairfax, Virginia; minutes from the Nation's Capital. We welcome you to
  495. enjoy an informative and invigorating program, and Washington's pleasant
  496. mid-fall sight-seeing weather.
  497.  
  498.                 Advance Technical Program
  499.                    (Subject to Change)
  500.  
  501. November 2
  502.  
  503. 8:45 - 9:00  Welcome, D. Denning and R. Pyle
  504.  
  505. 9:00 - 10:30  Applications, R. Sandhu
  506. - Support for the File System Security Requirements of Computational
  507.   E-Mail Systems, A. Prakash and T. Jaeger
  508. - Secure Wireless LANs, V. Bhargavan
  509. - The Design and Implementation of Tripwire: A File System Integrity
  510.   Checker, G. Kim and E. Spafford
  511.  
  512. 11:00 - 12:30 Emerging Areas, S. Lee
  513. - Exchange of Patient Records: Prototype Implementation of a Security 
  514.   Attribute Service in X.500, M. Jurecic and H. Bunz
  515. - A Process-Oriented Methodology for Assessing and Improving Software
  516.   Trustworthiness, E. Amoroso, C. Taylor, J.Watson and J. Weiss
  517. - Panel: To be announced
  518.  
  519. 2:00 - 4:00 Key Escrow, C. Neuman
  520. - Clipper Repair Kit - Towards Acceptable Key Escrow Systems,
  521.   T. Beth, H. Knobloch, M. Otten, G. Simmons and P. Wichmann
  522. - Protocol Failure in the Escrowed Encryption Standard, M. Blaze
  523. - Panel: Corporate Key Escrow, R. Ganesan
  524.  
  525. 4:30 - 6:00  Cryptography -1, J. Feigenbaum
  526. - Secure Agreement Protocols: Reliable and Atomic Group Multicast in
  527.   Rampart, M. Reiter
  528. - Key Distribution via True Broadcasting, M. Just, E. Kranakis, D.
  529.   Krizanc, P. Van Oorschot 
  530. - Conditionally Secure Secret Sharing Scheme with Disenrollment
  531.   Capability, C. Charnes and J. Pieprzyk 
  532. - Meta-ElGamal Signature Schemes, P. Horster, H. Petersen and M. Michels
  533. - Anonymous Credit Cards, S. Low, N. Maxemchuk and S. Paul 
  534.  
  535. November 3
  536.  
  537. 9:00 -10:30  Database Security, Carl Landwehr
  538. - An Efficient Multiversion Algorithm for Secure Servicing of
  539.   Transaction Reads, P. Ammann and S. Jajodia
  540. - A Temporal Authorization Model, E. Bertino, C. Bettini and P. Samarati
  541. - Propagation of Authorizations in Distributed Database Systems, P.
  542.   Samarati, P. Ammann and S. Jajodia
  543.  
  544. 11:00 - 12:30 Cryptography-2, J. Stern
  545. - Substitution-Permutation Networks Resistant to Differential and
  546.   Linear Cryptanalysis, H. Heys and S. Tavares
  547. - Information Leakage of Boolean Functions and its Relationship to
  548.   Other Cryptograpahic Criteria, M. Zhang, S. Tavares and L. Campbell
  549. - Authentication Codes that are r-fold Secure Against Spoofing,
  550.   R. Safavi-Naini
  551.  
  552. 2:00 - 4:00 Electronic Commerce Security - R. Ganesan
  553. - The Role of Licensing, Insurance and Endorsements in Evaluating
  554.   Trust of Distributed System Services,  C. Lai, G. Medvinsky and C. Neuman
  555. - To be announced
  556. - Panel: Security Issues in Electronic Commerce, C. Neuman
  557.  
  558. 4:30 - 6:00  Cryptographic Protocols, P. Van Oorschot
  559. - New Protocols for Third-Party-Based Authentication and Secure Broadcast,
  560.   L. Gong
  561. - How to Simultaneously Exchange Secrets by General Assumptions,
  562.   T. Okamoto and K. Ohta
  563. - A Key Distribution Method for Object-Based Protection, W. Ford and M. Wiener
  564.  
  565. November 4
  566.  
  567. 9:00 - 10:30 Cryptanalysis, L. Gong
  568. - On the difficulty of factoring, A. Lenstra
  569. - How to Break Gifford's Cipher, T. Cain and A. Sherman
  570. - Parallel Collision Search with Application to Hash Functions and
  571.   Discrete Logarithms, P. Van Oorschot and M. Wiener
  572.  
  573. 11:00 - 12:30  Firewalls, S. Bellovin
  574. - Application Access Control at Network Level, R. Molva and E. Rutsche 
  575. - Network Security Probe , P. Rolin, L. Toutain and S. Gombault 
  576. - Panel: Firewalls, S. Bellovin
  577.  
  578. 2:00 - 3:00  Experience, R.Graveman
  579. - Security Modelling for Organizations, A. Anderson, L. Kwok and D. Longley
  580. - Mainstreaming Automated Information Systems Security Engineering, 
  581.   J. Coyne and N. Kluksdahl
  582.  
  583. 3:30 - 5: 00  Multilevel Security, V. Gligor
  584. - The Compatibility of Composable Policies, H. Hinton and S. Lee
  585. - An Entropy Conservation Law for Testing the Completeness of Covert 
  586.   Channel Analysis, R. Browne
  587. - Prerequisite Confidentiality, J. Nestor and S. Lee
  588.  
  589. General Chairs: Dorothy Denning (Georgetown University), Raymond Pyle
  590.   (Bell Atlantic)
  591. Program Chairs: Ravi Ganesan (Bell Atlantic), Ravi Sandhu (George Mason Univ.)
  592. Treasurer and Local Arrangements: Richard Graveman (Bellcore)
  593. Proceedings: Jacques Stern (ENS/DMI)
  594. Publicity: Li Gong (SRI)
  595.  
  596. [Program Committee distinguished, but deleted for space, along with
  597.   registration info.  PGN]
  598.  
  599. ------------------------------
  600.  
  601. Date: 31 May 1994 (LAST-MODIFIED)
  602. From: RISKS-request@csl.sri.com
  603. Subject: Info on RISKS (comp.risks), contributions, subscriptions, FTP, etc.  
  604.  
  605.  The RISKS Forum is a moderated digest.  Its USENET equivalent is comp.risks.
  606.  Undigestifiers are available throughout the Internet, but not from RISKS.  
  607.  
  608.  SUBSCRIPTIONS: PLEASE read RISKS as a newsgroup (comp.risks or equivalent) on
  609.  your system, if possible and convenient for you.  BITNET folks may use a 
  610.  LISTSERV (e.g., LISTSERV@UGA): SUBSCRIBE RISKS or UNSUBSCRIBE RISKS.  U.S.
  611.  users on .mil or .gov domains should contact <risks-request@pica.army.mil> 
  612.  (Dennis Rears <drears@pica.army.mil>).  UK subscribers please contact 
  613.  <Lindsay.Marshall@newcastle.ac.uk>.  Local redistribution services are 
  614.  provided at many other sites as well.  Check FIRST with your local system or 
  615.  netnews wizards.  If that does not work, THEN please send requests to 
  616.  <risks-request@csl.sri.com> (which is not automated).  
  617.  
  618.  CONTRIBUTIONS: to risks@csl.sri.com, with appropriate,  substantive Subject:
  619.  line, otherwise they may be ignored.  Must be relevant, sound, in good taste,
  620.  objective, cogent, coherent, concise, and nonrepetitious.  Diversity is 
  621.  welcome, but not personal attacks.  PLEASE DO NOT INCLUDE ENTIRE PREVIOUS
  622.  MESSAGES in responses to them.  Contributions will not be ACKed; the load is 
  623.  too great.  **PLEASE** include your name & legitimate Internet FROM: address,
  624.  especially from .UUCP and .BITNET folks.  Anonymized mail is not accepted.
  625.  ALL CONTRIBUTIONS CONSIDERED AS PERSONAL COMMENTS; USUAL DISCLAIMERS APPLY.
  626.  Relevant contributions may appear in the RISKS section of regular issues
  627.  of ACM SIGSOFT's SOFTWARE ENGINEERING NOTES, unless you state otherwise.
  628.  All other reuses of RISKS material should respect stated copyright notices,
  629.  and should cite the sources explicitly; as a courtesy, publications using
  630.  RISKS material should obtain permission from the contributors.  
  631.  
  632.  ARCHIVES: "ftp crvax.sri.com<CR>login anonymous<CR>YourName<CR> cd risks:<CR>
  633.  Issue j of volume 16 is in that directory: "get risks-16.j<CR>".  For issues
  634.  of earlier volumes, "get [.i]risks-i.j<CR>" (where i=1 to 15, j always TWO 
  635.  digits) for Vol i Issue j.  Vol i summaries in j=00, in both main directory
  636.  and [.i] subdirectory; "dir" (or "dir [.i]") lists (sub)directory; "bye<CR>" 
  637.  logs out.  CRVAX.SRI.COM = [128.18.30.65]; <CR>=CarriageReturn; FTPs may 
  638.  differ; UNIX prompts for username, password; bitftp@pucc.Princeton.EDU and
  639.  WAIS are alternative repositories.  See risks-15.75 for WAIS info.  
  640.    To search back issues with WAIS, use risks-digest.src.
  641.    With Mosaic, use http://www.wais.com/wais-dbs/risks-digest.html.
  642.  
  643.  FAX: ONLY IF YOU CANNOT GET RISKS ON-LINE, you may be interested in receiving
  644.  
  645.  it via fax; phone +1 (818) 225-2800, or fax +1 (818) 225-7203 for info
  646.  regarding fax delivery.  PLEASE DO NOT USE THOSE NUMBERS FOR GENERAL 
  647.  RISKS COMMUNICATIONS; as a last resort you may try phone PGN at 
  648.  +1 (415) 859-2375 if you cannot E-mail risks-request@CSL.SRI.COM .
  649.  
  650. ------------------------------
  651.  
  652. End of RISKS-FORUM Digest 16.36 
  653. ************************
  654.  
  655.