[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: intent of package seti@home



John Hasler <john@dhh.gt.org> writes:

> Kevin Dalley writes:
> > SETI@Home wants to know whether a given piece of data has been analyzed.
> > You don't need a Cray to send billions of "nobody's home message".
> 
> You also don't need a Cray to reverse-engineer the client and figure out
> the protocol.  seti@home is very naive if they think that witholding the
> source will protect them.  They are using an unreliable network of
> unreliable and untrustworthy computers.  The sensible defense against this
> sort of attack as well as other false negatives is to send each piece of
> data to several clients, and only consider it analyzed when they receive
> several sets of identical results back.

Yes, though fewer people are likely to fake an executable only program
than a program which includes source code.  Sending data to multiple
sources reduces the processing power substantially.  Perhaps
occasional false data with a fake signal would help.

A second problem with source code is that people may try making
changes and analyzing the SETI@Home data anyway.  The speed would not
be as fast, but the results would not be dependable.  Sending data to
multiple clients usually protects against this problem, though a
widely distributed modification may still create problems.  False data 
would only help a little, depending upon the bug introduced in the
changed code.

> > My old 486 could send back many possibly false negatives, downloading new
> > data and immediately turning it around with negative results.
> 
> And if their software is any good that client will be marked bad and all
> its results ignored.  Time stamping each piece of data and rejecting
> clients that produce impossibly quick results is an obvious and easy bit of
> validation.

And if I know their definition of impossibly quick, then I slow down
my forging.


Reply to: