[RC5] eEye and d.net

N. Parr nparr at usa.net
Wed Dec 11 16:38:05 EST 2002

Oh BOO FREAKING HOO!  Who cares, lets get crackin.  If you agree then don't
waist your cycles responding.

-----Original Message-----
From: owner-rc5 at lists.distributed.net
[mailto:owner-rc5 at lists.distributed.net]On Behalf Of Fyodor
Sent: Wednesday, December 11, 2002 3:45 PM
To: rc5 at lists.distributed.net
Subject: Re: [RC5] eEye and d.net

Dave Huang wrote:

> Heh, I dunno... they probably just want the source code to dnet's
> network-related stuff. nmap has similarly snide comments:

Those (admittedly) snide remarks reflect my opinion that a project
like Distributed.net should provide source code access so that it can
be reviewed by those of us who do look for vulnerabilities in software
before running it on important machines.  In particular, I was hoping
to at least review the communication routines to determine exactly
what data was being transferred between my servers and theirs.  That
source code is unavailable, and the network traffic appears to be
intentionally obfuscated or encrypted to defy analysis.  Even those of
you who have no interest in reviewing the source code could still
benefit from the findings of those of us who do.  I sent my concerns
to distributed.net, but the first sentence of David McNett's 10/26/98
response was "You sir, are an idiot" and then he got even nastier.

That being said, even I can't hold much of a grudge for four years
:).  So the next version of Nmap will  use the following:

dnet-keyproxy     2064/tcp  # A closed-source client for solving the RSA
cryptographic challenge. This is the keyblock proxy port.
dnet-tstproxy     3064/tcp   # distributed.net (a closed source
crypto-cracking project) proxy test port

I hope Dnet users find these descriptions more agreeable.  eEye uses
the Nmap service DB with my permission and some of their own changes.
So they may pick these up eventually.

I still find it a shame that DNet has decided to go with the lazy
obfuscation route to authenticate their client.  Their own "source"
page [1] even admits that "it is relatively easy for any knowledgeable
person to disasemble [SIC] or patch binaries. This is actually quite a
trivial task, so we urge you not to try. Indeed, security through
obscurity is actually not secure at all, and we do not claim it to be
such."  In other words, they are trading off their user's security and
privacy in exchange for a perceived security benefit that is "a trivial
task" to defeat.  And even someone who lacks that reverse-engineering
competence can obtain the source by writing help at distributed.net and
pretending to be a new platform porter.  Instead, I feel they
should either trust their users or design in security mechanisms that
actually work.  For example, the server could occasionally benchmark
the client by asking it to solve given problems in an amount of time
commensurate with the client's claimed keyblock cracking speed.  No,
it isn't a perfect solution.  Nor is it trivial to implement, and
there are many details to work out.  But it sure beats this
security-by-obscurity approach!

Anyway, DNet has apparently made their decision on this matter, and I
have better things to do than try to argue or fight it.  I simply
won't use their software.  Other than that I have no (more) hard
feelings.  Please CC me on any responses you wish me to read, as I
don't follow this list.  Further information on this matter is
available at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=172618 .


[1] http://www.distributed.net/source/
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 mailing list