nugget at slacker.com
Thu Oct 9 11:49:53 EDT 1997
"David M. Putzolu" <dputzolu at ideal.jf.intel.com> says:
>Hear hear! Look people, please TRUST the Bovine people and
>accept their opaque binaries. All of you people out there
>can't be trusted with the source. Let's ignore the fact that
>a motivated person can ignore their security measures and use
>assembly to get around them.
There are many reasons why we are reluctant to release the source
to the V2 code. One of these reasons is that, yes, maintaining
controls on the source code does improve security slightly.
This, however, is not the only reason we're controlling the
source distribution. In fact, it's not even our primary reason.
If we were as concerned with source availibility as a method of
security like you seem to think, do you really expect that we
would have gone to the effort of retaining support for the V1
clients? Let me remind you that the V1 client source code is
quite available and that these V1 clients are still perfectly
valid vehicles for participating in the Bovine effort. Certainly
security through obscurity were our goal, we would have ripped out
support for V1 clients months ago.
In fact, we have gone to great lengths to ensure that V1 clients are
and will always be supported.
For those new to the effort, who do not have the benefit of having
been around when we made the move to the V2 protocol, let me fill
you in on the details and issues that were involved in that decision.
The pre-V2 Bovine community was a very confusing and disjointed
effort. There were, at that point, three seperate development efforts
under way in building clients. None of these efforts was a perfect
solution, however. One was fast, the other had better features, and
neither was as stable as the third. This was a horribly confusing
situation for both experienced crackers and potential crackers as well.
This was why we drew everyone together into a single V2 development
team. May I politely point out that were it not for the cohesive
and very talented coding team and the single code base, there is no
way we would be able to have the divirsity of platform support that
we have, nor a consistant versioning scheme. These are all Good Things
and are far more important to the effort than any unmeasurable security
benefit brought about by the lack of code availability.
Take a moment to imagine how confusing and less effective we would be
now if there were four or five current clients for each platform, each
with a barely-portable and non-integrated code base. None of the
platforms would have compatible buffer files, making the management of
a mixed-platform site much more difficult. Some clients, of course,
would be no longer supported, the author having lost interest in RC5
and moved on to spend his time playing Ultima Online. There wouldn't
even be a single distribution site, and keeping track of the current
versions for all you machines would rely on combing web sites and
following the mailing list traffic. This is exactly where we were headed
(and fast) prior to the consolodation of the development effort.
None of us are foolish enough to believe that the obscurity surrounding
the protocol/source are in any way an impediment to the persistant hacker.
The guts of the client/keyserver communication are really focused on
authentication and not obfuscation. The protocol was changed not as a
security measure, but rather because we now transfer more and better
information as each packet is transmitted, such as CPU/OS/Version
>I'm also tempted to reverse engineer the server communication
>protocol. And of course, I wouldn't keep any secrets and would
>publish the protocol, which would promptly blow away this
>foolish security-through-obscurity scheme.
...which only exists in your head...
>My motivation to do this is to be able to write a Java client
Perhaps a better approach would have been to contact one of the coding
team and expressing your interest in porting the client to Java.
Certainly that would have garnered a far better response that spewing your
half-cocked suspicions regarding some issues that are quite clear. Ten
minutes of browsing the list archives would have provided you with more
than enough assurance that your suspicions are baseless and unfounded.
Regardless, I fail to understand how the lack of public access to the V2
source has prevented you from doing this.
>...and prove that the hacker-mentality focus on native code is
btw, had you contacted the coding team, I'm sure their first step would
have been to provide you with both the independant Java ports that have
been done by members of the Bovine community that prove, beyond the
shadow of a doubt, that java is more than worthless for doing brute-force
attacks on RC5. These real-world examples, of course, and not some
non-existant mentality, are why we do not waste our time with Java ports
of the client. Still, if you insisted, they would have helped you port
the client to Java and offered you assistance in any way possible.
o Your brash and baseless accusations are founded in the misconception
that the source is not available. Feel free to download the V1 client
source from our ftp site. We'll even help you figure it out if that
o Your *assumptions* as to why the V2 source is not publically available
are simply incorrect. I would just like to take this opportunity to
set the record straight. I realize that many readers were not around
the first time we hashed through all this and perhaps it's an
appropriate time to revisit the issue.
o Irrespective of any hacker mentality you may perceive (and I find it
very difficult to attach any "mentality" to a group as diverse and
varied as the Bovine Effort), Java is a wholly inappropriate platform
for this specific task which is best accomplished by native, targeted,
hand-tuned assembly code.
Thank you in advance for your thoughtful and intelligent reply.
|David McNett |To ensure privacy and data integrity this message has|
|nugget at slacker.com|been encrypted using dual rounds of ROT-13 encryption|
|Birmingham, AL USA|Please encrypt all important correspondence with PGP!|
To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.
More information about the rc5