home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / sci / crypt / 2967 < prev    next >
Encoding:
Internet Message Format  |  1992-08-19  |  6.6 KB
  1. Path: sparky!uunet!zephyr.ens.tek.com!uw-beaver!ubc-cs!destroyer!gumby!yale!yale.edu!qt.cs.utexas.edu!cs.utexas.edu!asuvax!ncar!csn!news.den.mmc.com!mercury!jhull
  2. From: jhull@mercury.NoSubdomain.NoDomain (   Joseph F. Hull)
  3. Newsgroups: sci.crypt
  4. Subject: Re: Secure netnews
  5. Message-ID: <1992Aug19.214819.13955@den.mmc.com>
  6. Date: 19 Aug 92 21:48:19 GMT
  7. References: <9208182108.AA09132@news.cis.ohio-state.edu> <1992Aug18.221506.13535@Princeton.EDU>
  8. Sender: jhull@mercury (   Joseph F. Hull)
  9. Organization: Martin Marietta Astronautics, Denver
  10. Lines: 132
  11. Nntp-Posting-Host: 137.41.19.5
  12.  
  13. In <9208182108.AA09132@news.cis.ohio-state.edu>
  14. Marc.Ringuette@daisy.learning.cs.cmu.edu writes:
  15.  
  16. > The basic technique ... is a two-stage news distribution process, where first
  17. > the news is distributed to the entire set of receiving machines, 
  18. > then signatures are collected from all receivers and distributed in the same
  19. > way as a regular news article. ... when signatures from at least half the
  20. > newsreading machines have been received, will a receiver be assured that the
  21. > article is authentic, and the article is given the next number in the 
  22. > sequence of accepted articles.
  23.  
  24. Please note that Marc seems to be making an assumption that I can trust my own
  25. machine.  I think this is a reasonable assumption, but I recognize that it may
  26. not be true in every case.
  27.  
  28. In <1992Aug18.221506.13535@Princeton.EDU>
  29. dla@raven (Don Alvarez) writes:
  30.  
  31. + Gaping holes?  *YES*
  32.  
  33. + Any subscriber can fraudulently "authenticate" any posting simply by
  34. + greping through the list of subscribers and announcing "subscriber foo
  35. + received article 754", "subscriber bar received article 754", etc.
  36.  
  37. + There is no way to defend against this because there is no way to prove
  38. + who sent the message stating that machine foo has received an article.
  39.  
  40. Why not use a public key encryption system to provide digital signatures?
  41. Whether or not you agree with RSA's policies on use of their techniques, the
  42. techniques are reasonably secure (certainly secure enough for this use,
  43. although possibly not secure enough for financial systems).
  44.  
  45.  
  46.  
  47. + Worse, there is no way for any machine even to know that it has a complete
  48. + or accurate list of subscribers because there is no way to distribute
  49. + such a list in a trusted manner.
  50.  
  51. Horsefeathers.  The same public key encryption system used for digital 
  52. signatures, be it RSA or something else, can be used to authenticate the
  53. contents of any message sent by a trusted machine.  Read RSA's public
  54. documents on features of their system.
  55.  
  56.  
  57.  
  58. + Providing a centralized server for doing the authentication wouldn't
  59. + help, because there is no way for it to know who is sending the
  60. + subscription messages or who is sending the receipt messages.  There
  61. + would also be no way for the individual subscribers to know who sent
  62. + the "article 754 authenticated" message.
  63.  
  64. Providing a centralized authentication server is not adequate and is not 
  65. necessary.  The individual subscribers can authenticate the "article
  66. received" messages using public key encryption.
  67.  
  68.  
  69.  
  70. + If you had a mechanism that allowed you to prove who sent a message,
  71. + then you could solve not only the secure newsfeed problem but a whole
  72. + host of more serious problems.  Unfortunately, such a mechanism doesn't
  73. + exist.
  74.  
  75. Prove, as used here, is a very tricky term.  There are very involved 
  76. discussions of just what it means going on within a large number of
  77. interested groups, including NSA, the Federal Reserve System and the legal
  78. community.  However, to the extent that a public key encryption system can
  79. successfully protect the value of each and every user's private key, a
  80. digital signature using that system may reasonably be said to "prove" that
  81. a message came from the purported user and a digital authentication using
  82. that system may reasonably be said to "prove" that the message received is
  83. the message that was sent.  The threat model against which the public key
  84. encryption system must protect includes:  compromise within the user's own
  85. system; compromise via cryptanalytic attacks against the public key data
  86. base; compromise via cryptanalytic attacks against authenticated messages
  87. and digital signatures.
  88.  
  89.  
  90.  
  91. + Note that any proposed solution to the above problem which claims to
  92. + find an answer using any of the words DES, RSA, public-key encryption,
  93. + or private-key encryption is a non-solution.  Those are all encryption
  94. + techniques.
  95.  
  96. Yes, Don, these are all encryption techniques.  But why do you assume that
  97. encryption techniques CAN NOT be a part of a solution to the system Marc is
  98. proposing.
  99.  
  100.  
  101.  
  102. + The problem here has nothing to do with encryption
  103. + techniques.  The problem here has to do with cryptographic protocols,
  104. + or more importantly with the lack thereof.
  105.  
  106. Let's define some terms.  I suggest "cryptographic protocol" refers to those
  107. rules by which various participants in an encryption method exchange the
  108. information needed to encrypt and decrypt "messages."  I suggest "security 
  109. protocol" refers to those rules by which various participants in some security
  110. process, such as ensuring all nodes see the same news articles, exchange the 
  111. information needed to complete the process.  Security protocols may or may not 
  112. involve cryptographic methods.  I agree that one part of the solution to the 
  113. system Marc is proposing is development of an appropriate security protocol.
  114.  
  115.  
  116.  
  117. + It [referring back to what Don called cryptographic protocols] is a 
  118. + fundamentally unsolved and (I believe) unsolveable problem. 
  119. + There is no way to propagate trust across the entire network.
  120.  
  121. Very often, the way one states, or formulates, a problem has a lot to do with
  122. how easy it is to solve the problem.  Some formulations lead us, more or less
  123. directly, to a solution, while other formulations offer no assistance at all.
  124. I agree that there is no way (I see no way) to propagate trust across the
  125. entire network.  But why would you want to (mis)state the problem this way.
  126. The problem, as stated by Marc (and he gets to state it anyway he wants to,
  127. it's HIS problem), is how could we implement a news system that:
  128.   1) lets each subscribing system determine that it is seeing "the same" 
  129.      articles as other systems 
  130.   2) does not let a (small) group of cooperating machines spoof the system
  131.      into accepting un-authenticated articles.
  132. The problem is trusted counting of messages from identifiable sources.  The
  133. identification is provided by digital signatures.  The trusted counting is
  134. provided by my own, I hope trusted, machine.  If my machine isn't trusted, I
  135. have MUCH bigger problems than netnews.
  136.  
  137.  
  138.  
  139.  
  140. -- 
  141.        _   _
  142.     /_    / ) / ) Jeff Hull          hull@den.mmc.com
  143.    //_) -/- -/-   1544 S. Vaughn Cir
  144. /_/ \_/ /   /      Aurora, CO 80012   303-977-1061
  145.