Re: intent of package seti@home
> The algorithm would need to be a bit more complicated than that to
> protect against malicious attacks. The malicious cracker could just
> return an md5sum of the approved binary, which is kept nearby for
> occasions like this. For the non-malicious hacker, this algorithm
> would work fine.
well, then, an md5sum of (the binary appended to the data being sent) would
make it impossible to forge with just a known md5sum (although of course
having a copy of a known good binary would do the trick).
or if you're quite concerned you could keep a binary of the analysis on your
site for each supported architecture (java bytecode might work better for
this but in practice it has just as many portability issues as c), and
change it in some unpredictable but functionally meaningless way (like
changing a static string designed explicitly for this purpose, possibly make
it a pgp signature of the data being sent plus the date/time of sending, and
do something funky to locate it in a random -- and unfindable by normal
means -- part of the data segment of the binary each time), and also include
the data in the binary so it could only be used once, and have the signature
along with the analyzed data. then you could release the code, which
wouldn't actually be useful for sending back seti data (because the chances
of returning a correct signature with a non-seti binary is almost certainly
smaller than the chance that seti's own analysis software will generate a
false negative) but could be hacked on to produce patches, which would be
sent back to seti for examination and possible deployment.
the above may have some fatal flaw i'm missing, but the gist of it is that
untrusted distributed computing can be made *far* more secure than merely
human-unreadable (which provides no protection whatever -- it merely delays
the inevitable and simultaneously makes it more inevitable by providing a
challenge).
--phouchg
"For a price I'd do about anything, except pull the trigger: for that I'd
need a pretty good cause" -- Queensryche, "Revolution Calling"
PGP 5.0 key (0xE024447449) at http://cif.rochester.edu/~jpt/pubkey.txt
Reply to: