[RC5] eEye and d.net
bwilson at distributed.net
Tue Dec 10 15:10:32 EST 2002
As stated elsewhere, Security Through Obscurity is not perfect
security, but it does help. If I were to attempt to crack an RSA
message myself, the first hurdle to cross would be to determine the
algorithm used. Until I know that algorithm, I still face a STO
problem. The difference with RSA is that I have more work to do after
STO isn't perfect, but it provides more security than plaintext. Just
because we don't have a perfect solution doesn't mean we shouldn't use
what solutions we have at our disposal. While STO won't stop all
attempts, in our experience it lowers the frequency enough to make the
remaining problems rare and manageable.
We have ideas in the works to increase the security of the client, but
the problem is not a simple one. It is difficult to imagine a
solution which is perfectly secure when installed on systems we do not
In most security scenarios, [A] and [B] are trying to exchange
information securely, protecting against hostile others. In our case,
we [A] have to distribute software and data to [B] who must be able to
read the actual data (not just a token or signature), verify it came
from us (so it needs to know how we calculated our checksum), then
send it back to us [A] in a form that we can verify it came from us
originally, that [B] actually did the work (to prevent a hacked client
from reporting results without doing the work), and the identity of
[B] to give stats credit. Finally, we must do this without
significantly increasing the workload of our proxies and master, which
are already quite busy.
Unlike most scenarios, we are actually distributing executables to
potentially untrusted users. Anything the client can do in code can
be reverse engineered, and the compiled code is readily available.
Public key encryption is too CPU intensive on both the client and
server side - using PKE would cut significantly into our keyrate.
While STO isn't necessarily secure, providing open-source of this
project would make it trivial to abuse and defeat our projects.
Bovine has more detailed (and interesting) reading on the subject at
the bottom of http://www.distributed.net/source/ and especially
Bruce Wilson <bwilson at distributed.net>
PGP KeyID: 5430B995, http://www.toomuchblue.com/
"I want to move to Theory. Everything works in Theory."
--John Cash, id Software
| -----Original Message-----
| From: owner-rc5 at lists.distributed.net
| [mailto:owner-rc5 at lists.distributed.net] On Behalf Of
| Gustav_Schaffter at capgroup.com
| Sent: Tuesday, December 10, 2002 07:23
| To: rc5 at lists.distributed.net
| Subject: Re: [RC5] eEye and d.net
| I believe and sincerely hope that the reasons for dnet to
| keep the source
| code closed is *not* to protect the project from potential attempts
| security breaches.
| It is (or should be?) widely known by now that "security
| through obscurity"
| is the worst kind of "security". It gives the owner of the
| product a false
| sense of security which makes him/her relax on the security
| side, while
| making the cracker curious and challenged.
| Only the "good guys" (who wouldn't do any harm anyway) are kept out
| "security through obscurity". The "bad guys" are just more
| "proud" when the
| system is cracked. Popular software is often cracked within a
| few days of
| the latest release. (BTW, almost any modern debugger will do.)
| I seem to remember having read other reasons for the closed
| source nature
| of dnet, where the main reasons were based upon the hope of
| keeping abreast
| of the competitors, which would normally hesitate very much
| to create a
| public project out of reverse engineered copyrighted code.
| zorbathut at uswest.net wrote:
| > Out of curiosity, are there any open-source distributed computing
| > out there? How did they get around the security problems?
| To unsubscribe, send 'unsubscribe rc5' to
| majordomo at lists.distributed.net
| rc5-digest subscribers replace rc5 with rc5-digest
To unsubscribe, send 'unsubscribe rc5' to majordomo at lists.distributed.net
rc5-digest subscribers replace rc5 with rc5-digest
More information about the rc5