Re: [GNUnet-developers] Other way to updateable content

[Christian Grothoff]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 27 January 2003 06:36 am, you wrote:
> On Sun, 26 Jan 2003, Christian Grothoff wrote:
> > A more major problem with these 'arbitrary' updates is that how would a
> > peer know that he actually got "the latest" version from the network? If
> > I get version 4, how can I be sure that there is no version 235252 out
> > there? How do you ensure that malicious peers actually do the update and
> > do not keep old versions around and forward those? The existing proposal
> > gives you the guarantee that you get any one version of the content and
> > can from there compute (!) the version that will be the latest at any
> > given time in the future, and nobody can cheat.
>
> What makes you think a malicious node, in the old proposal, couldn't just
> flatly refuse to transfer arbitrary blocks w.r.t the defined geometric
> function and increment, which can be assumed to be known to anybody who
> wants to attack the particular entry point?

If you assume that the malicious node knows the entry-point, yes, that is 
possible. The only difference here is that the version information is 
propagated in plaintext in the 'increment counter' scenario and thus the
comparisson/prediction is trivial even without any knowledge about the 
entrypoint, whereas the geometric computation in the existing proposal is in 
the encrypted portion of the RootNode and thus only accessible to peers that 
got the 'secret' of this entry point. 
But yes, in both cases peers can supress content that they deem inappropriate, 
but while in the versioning case the receiver can not tell if the version 
that was received is 'recent' or up-to-date, this can be verified in the 
fixed-publication period case. If the receiver can detect that outdated 
content was received, counter-measures (like re-issue request to route around 
problems until up-to-date content is found) can be taken. In the increment 
counter case, the receiver would never know when to stop re-issuing requests.

> Then the user, though he could
> know that what he's got is not the latest (possibly having to revert to an
> old version), but he still couldn't know if a later edition has been
> published - the author could've been shot, the network can have been
> split, or the nodes can refuse to transfer the data for reason or
> another. Primarily, there's no guarantee anyway of availability, only of
> validity, when we get the data. If, on the other hand, the new style
> was used, the blocks could always be allowed to be timestamped (perhaps
> only roughly, and/or allowing the author to fake the dates), so the user
> could measure if the edition he gets is recent or not. The author
> could cheat, yes, but so he can insert future editions beforehand.
> Also, the timestamping wouldn't be much of a problem, it could
> be something on the lines of 'posted on week 42' or 'next
> edition expected in january', and the reliability of the timestamp
> would be measured by users personal trust on that pseudonym
> who has done the signing.

Very true, though I am less concerned with potential authors faking timestamps 
(they may want to do a little-bit to throw of timing attacks, but there is no 
incentive to do so much that they throw of their readers :-)

> So the answer to your question is that no, the user can't
> exactly know, but how tragic is that? Timestamping could give
> some measure, and the malicious nodes couldn't gain more
> than 'unit of credit' by this mechanism per a node requesting
> the entry point: once user gets edition i, he starts requesting
> with #serial>=i+1, where only valid matches are those newer than
> the edition he's already got. Incorrect answers can naturally
> be discarded and not awarded any trust. And we assume that
> the nodes can not forge the serials. Thus a malicious node
> can cheat only once. I assume here that the client software
> can keep on looking for a newer version and perhaps replacing
> the shown content on the fly, until user tells it to stop looking.
>
> Ok, that was mostly thinking aloud too, but the purpose here imo
> is to get the thoughts and arguments honed to a good
> proposition that is worth implementation and doesn't have
> to be radically tweaked after its there.

Certainly. I think the idea of increment-counter + timestamp as an alternative 
update-scheme is definitely valid and will be very useful for publications 
that are not as strictly periodical as --- periodicals :-)

> > Thus the existing proposal is much better for periodically updated
> > content. It may be worse of irregularly updated content with "weak"
> > security requirements because it forces the author to re-publish an
> > update in every period to keep the content available at all times and it
> > is impossible to publish updates at points in time where no update is
> > scheduled.
> > But why could we not have both?
>
> I didn't say we'd have to remove the other options. I'm just
> noticing that many publishers might not feel comfortable being
> forced to regular updating and that we could/should have a
> simple, transparent, perhaps a bit less secure alternative. Also,
> different types pointers could be published to the same content,
> say the publisher first thinks he'll do periodicals (a
> geometric query works well), then he gets bored (a rewriting
> mechanism gives the most recent, because periodic insert
> hasn't been done, and the resp. query can't work), gets
> active again, etc...

I agree, there is a need for this form of updateable content that was not 
addressed in the existing proposal. Are you going to update the HTML text to 
reflect this new idea?

Christian
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE+NZGf9tNtMeXQLkIRAo6rAKCfuBxWLq4KLgZkMfMRTB8vzZi3YQCeLTZp
mizd4SJolrKaq6lIh5d33bQ=
=YdNJ
-----END PGP SIGNATURE-----