home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2942 < prev    next >
Encoding:
Text File  |  1992-08-18  |  3.0 KB  |  68 lines
  1. Newsgroups: sci.crypt
  2. Path: sparky!uunet!usc!zaphod.mps.ohio-state.edu!darwin.sura.net!jvnc.net!princeton!raven!dla
  3. From: dla@raven (Don Alvarez)
  4. Subject: Re: Secure netnews
  5. Message-ID: <1992Aug18.221506.13535@Princeton.EDU>
  6. Originator: news@nimaster
  7. Sender: news@Princeton.EDU (USENET News System)
  8. Nntp-Posting-Host: raven.princeton.edu
  9. Organization: Princeton University
  10. References: <9208182108.AA09132@news.cis.ohio-state.edu>
  11. Date: Tue, 18 Aug 1992 22:15:06 GMT
  12. Lines: 54
  13.  
  14. In article <9208182108.AA09132@news.cis.ohio-state.edu> Marc.Ringuette@daisy.learning.cs.cmu.edu writes:
  15. >
  16. >The basic technique I propose in order to achieve this is a two-stage news
  17. >distribution process, where first the news is distributed to the entire set
  18. >of receiving machines, then signatures are collected from all receivers and
  19. >distributed in the same way as a regular news article.  
  20. >
  21. >Machines must register themselves by posting to the newsgroup, and must agree
  22. >to respond to signature requests within a reasonable window, or they will be
  23. >removed from the set of participating hosts.  
  24. >
  25. >What do you think?  See any gaping holes?  Want to flesh it out and 
  26. >give it a try?
  27. >
  28. >    --Marc Ringuette, mnr@cs.cmu.edu
  29.  
  30. Gaping holes?  *YES*
  31.  
  32. There is no central authentication server, so every subscriber must be
  33. able to determine authentication themselves.  That means every
  34. subscriber needs a list of the names of all of the other subscribers.
  35.  
  36. Any subscriber can fraudulently "authenticate" any posting simply by
  37. greping through the list of subscribers and announcing "subscriber foo
  38. received article 754", "subscriber bar received article 754", etc.
  39.  
  40. There is no way to defend against this because there is no way to prove
  41. who sent the message stating that machine foo has received an article.
  42.  
  43. Worse, there is no way for any machine even to know that it has a complete
  44. or accurate list of subscribers because there is no way to distribute
  45. such a list in a trusted manner.
  46.  
  47. Providing a centralized server for doing the authentication wouldn't
  48. help, because there is no way for it to know who is sending the
  49. subscription messages or who is sending the receipt messages.  There
  50. would also be no way for the individual subscribers to know who sent
  51. the "article 754 authenticated" message.
  52.  
  53. If you had a mechanism that allowed you to prove who sent a message,
  54. then you could solve not only the secure newsfeed problem but a whole
  55. host of more serious problems.  Unfortunately, such a mechanism doesn't
  56. exist.
  57.  
  58. Note that any proposed solution to the above problem which claims to
  59. find an answer using any of the words DES, RSA, public-key encryption,
  60. or private-key encryption is a non-solution.  Those are all encryption
  61. techniques.  The problem here has nothing to do with encryption
  62. techniques.  The problem here has to do with cryptographic protocols,
  63. or more importantly with the lack thereof.  It is a fundamentally unsolved
  64. and (I believe) unsolveable problem.  There is no way to propagate trust
  65. across the entire network.
  66.  
  67. -don
  68.