🚀 go-pugleaf

In <9208182108.AA09132@news.cis.ohio-state.edu>
Marc.Ringuette@daisy.learning.cs.cmu.edu writes:

> The basic technique ... is a two-stage news distribution process, where first
> the news is distributed to the entire set of receiving machines, 
> then signatures are collected from all receivers and distributed in the same
> way as a regular news article. ... when signatures from at least half the
> newsreading machines have been received, will a receiver be assured that the
> article is authentic, and the article is given the next number in the 
> sequence of accepted articles.

Please note that Marc seems to be making an assumption that I can trust my own
machine.  I think this is a reasonable assumption, but I recognize that it may
not be true in every case.

In <1992Aug18.221506.13535@Princeton.EDU>
dla@raven (Don Alvarez) writes:

+ Gaping holes?  *YES*

+ Any subscriber can fraudulently "authenticate" any posting simply by
+ greping through the list of subscribers and announcing "subscriber foo
+ received article 754", "subscriber bar received article 754", etc.

+ There is no way to defend against this because there is no way to prove
+ who sent the message stating that machine foo has received an article.

Why not use a public key encryption system to provide digital signatures?
Whether or not you agree with RSA's policies on use of their techniques, the
techniques are reasonably secure (certainly secure enough for this use,
although possibly not secure enough for financial systems).



+ Worse, there is no way for any machine even to know that it has a complete
+ or accurate list of subscribers because there is no way to distribute
+ such a list in a trusted manner.

Horsefeathers.  The same public key encryption system used for digital 
signatures, be it RSA or something else, can be used to authenticate the
contents of any message sent by a trusted machine.  Read RSA's public
documents on features of their system.



+ Providing a centralized server for doing the authentication wouldn't
+ help, because there is no way for it to know who is sending the
+ subscription messages or who is sending the receipt messages.  There
+ would also be no way for the individual subscribers to know who sent
+ the "article 754 authenticated" message.

Providing a centralized authentication server is not adequate and is not 
necessary.  The individual subscribers can authenticate the "article
received" messages using public key encryption.



+ If you had a mechanism that allowed you to prove who sent a message,
+ then you could solve not only the secure newsfeed problem but a whole
+ host of more serious problems.  Unfortunately, such a mechanism doesn't
+ exist.

Prove, as used here, is a very tricky term.  There are very involved 
discussions of just what it means going on within a large number of
interested groups, including NSA, the Federal Reserve System and the legal
community.  However, to the extent that a public key encryption system can
successfully protect the value of each and every user's private key, a
digital signature using that system may reasonably be said to "prove" that
a message came from the purported user and a digital authentication using
that system may reasonably be said to "prove" that the message received is
the message that was sent.  The threat model against which the public key
encryption system must protect includes:  compromise within the user's own
system; compromise via cryptanalytic attacks against the public key data
base; compromise via cryptanalytic attacks against authenticated messages
and digital signatures.



+ Note that any proposed solution to the above problem which claims to
+ find an answer using any of the words DES, RSA, public-key encryption,
+ or private-key encryption is a non-solution.  Those are all encryption
+ techniques.

Yes, Don, these are all encryption techniques.  But why do you assume that
encryption techniques CAN NOT be a part of a solution to the system Marc is
proposing.



+ The problem here has nothing to do with encryption
+ techniques.  The problem here has to do with cryptographic protocols,
+ or more importantly with the lack thereof.

Let's define some terms.  I suggest "cryptographic protocol" refers to those
rules by which various participants in an encryption method exchange the
information needed to encrypt and decrypt "messages."  I suggest "security 
protocol" refers to those rules by which various participants in some security
process, such as ensuring all nodes see the same news articles, exchange the 
information needed to complete the process.  Security protocols may or may not 
involve cryptographic methods.  I agree that one part of the solution to the 
system Marc is proposing is development of an appropriate security protocol.



+ It [referring back to what Don called cryptographic protocols] is a 
+ fundamentally unsolved and (I believe) unsolveable problem. 
+ There is no way to propagate trust across the entire network.

Very often, the way one states, or formulates, a problem has a lot to do with
how easy it is to solve the problem.  Some formulations lead us, more or less
directly, to a solution, while other formulations offer no assistance at all.
I agree that there is no way (I see no way) to propagate trust across the
entire network.  But why would you want to (mis)state the problem this way.
The problem, as stated by Marc (and he gets to state it anyway he wants to,
it's HIS problem), is how could we implement a news system that:
  1) lets each subscribing system determine that it is seeing "the same" 
     articles as other systems 
  2) does not let a (small) group of cooperating machines spoof the system
     into accepting un-authenticated articles.
The problem is trusted counting of messages from identifiable sources.  The
identification is provided by digital signatures.  The trusted counting is
provided by my own, I hope trusted, machine.  If my machine isn't trusted, I
have MUCH bigger problems than netnews.




-- 
	   _   _
    /_    / ) / ) Jeff Hull          hull@den.mmc.com
   //_) -/- -/-   1544 S. Vaughn Cir
/_/ \_/ /   /	  Aurora, CO 80012   303-977-1061