home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2949 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  2.8 KB

  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!mips!sdd.hp.com!usc!orion.oac.uci.edu!beckman.com!dn66!a_rubin
  2. Newsgroups: sci.crypt
  3. Subject: Re: Secure netnews
  4. Message-ID: <a_rubin.714242242@dn66>
  5. From: a_rubin@dsg4.dse.beckman.com (Arthur Rubin)
  6. Date: 19 Aug 92 16:37:22 GMT
  7. References: <9208182108.AA09132@news.cis.ohio-state.edu> <1992Aug18.221506.13535@Princeton.EDU>
  8. Nntp-Posting-Host: dn66.dse.beckman.com
  9. Lines: 56
  10.  
  11. In <1992Aug18.221506.13535@Princeton.EDU> dla@raven (Don Alvarez) writes:
  12.  
  13. >In article <9208182108.AA09132@news.cis.ohio-state.edu> Marc.Ringuette@daisy.learning.cs.cmu.edu writes:
  14. >>
  15. >>The basic technique I propose in order to achieve this is a two-stage news
  16. >>distribution process, where first the news is distributed to the entire set
  17. >>of receiving machines, then signatures are collected from all receivers and
  18. >>distributed in the same way as a regular news article.  
  19. >>
  20. >>Machines must register themselves by posting to the newsgroup, and must agree
  21. >>to respond to signature requests within a reasonable window, or they will be
  22. >>removed from the set of participating hosts.  
  23. >>
  24. >>What do you think?  See any gaping holes?  Want to flesh it out and 
  25. >>give it a try?
  26. >>
  27. >>    --Marc Ringuette, mnr@cs.cmu.edu
  28.  
  29. >Gaping holes?  *YES*
  30.  
  31. >There is no central authentication server, so every subscriber must be
  32. >able to determine authentication themselves.  That means every
  33. >subscriber needs a list of the names of all of the other subscribers.
  34.  
  35. >Any subscriber can fraudulently "authenticate" any posting simply by
  36. >greping through the list of subscribers and announcing "subscriber foo
  37. >received article 754", "subscriber bar received article 754", etc.
  38.  
  39. Actually, if the "signatures" are cryptographic, there may be a solution to that.
  40. You have to define "subscribers" as key-holders rather than as machines,
  41. but it seems somewhat reasonable.
  42.  
  43. ...
  44.  
  45. >Worse, there is no way for any machine even to know that it has a complete
  46. >or accurate list of subscribers because there is no way to distribute
  47. >such a list in a trusted manner.
  48.  
  49. That's true.
  50.  
  51. >Providing a centralized server for doing the authentication wouldn't
  52. >help, because there is no way for it to know who is sending the
  53. >subscription messages or who is sending the receipt messages.  There
  54. >would also be no way for the individual subscribers to know who sent
  55. >the "article 754 authenticated" message.
  56.  
  57. That's not correct.  If you believe public key signature systems can be
  58. secure, then a message can be posted which has the effect that "someone
  59. with key K1 posted message M1".
  60.  
  61.  
  62. --
  63. Arthur L. Rubin: a_rubin@dsg4.dse.beckman.com (work) Beckman Instruments/Brea
  64. 216-5888@mcimail.com 70707.453@compuserve.com arthur@pnet01.cts.com (personal)
  65. My opinions are my own, and do not represent those of my employer.
  66. My interaction with our news system is unstable; if you want to be sure I see a post, mail it.
  67.