[rc5] Blocks

Marc Sissom msissom at dnaent.com
Thu Oct 9 16:33:31 EDT 1997

David McNett wrote:
I understand that you have accepted the responsibilities and
results of being the "point man" for the bovine crew, but you
gotta admit that some of the stuff you spilled out here is
some really rosy colored hindsight.

> 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.

Righto, we've seen this before.
> 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.

Good point and I'm glad that you've finally thought of it.
> In fact, we have gone to great lengths to ensure that V1 clients are
> and will always be supported.

Huh? If you change your mind, v1 support could be turned off
with the flip of a bit!
> 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.

Three? Only three? Perhaps three major ones that were getting
attention from users. Several of us were developing, and dropped
our efforts when we saw the limits of the utility.

>  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.

Confusing? Bah! All you had to do was survey the situation, try
out the clients and then select the one that worked best for
our particular situation. This is how our society and economy
is supposed to work. Those that make poor choices get poor results.

The point is, choices. As it turned out, the bovine product
was not the best choice for anybody. The "other" clients were
faster, had better features, were more stable...that's how they
got incorporated into the "coding team". Before users started
making use of the "enhanced" v1 code, the other coders were

> 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.

Indeed, this has occurred _because_ of the unpublished v2 code.

>  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.

Big deal. Most of us are used to combing web sites anyway. Those
that want the best results typically are willing to spend more
time "shopping".

> 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
> information.
> >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...

Righto, what about those that would like to penetrate firewalls?
It sure would be nice if the code was available so we could fix
our problems.
> >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.

Hah! Contact the coding crew. What a laugh.
The only coders that have ever responded to me were those that
were not on the bovine team. Even such simple things as bug
reports on the web pages get no response.

I'll stick this one in here: On the "current rate" page, the link
to "executive summary" still produces this:

    The page you have selected is no longer available

BTW, the new-history(oxymoron?) feature is nice.

> 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.

Interesting. You claim that there are existant, working Java
clients? Why can we not download, run, and experiment with them.
We would only waste our time, not yours.

>  Still, if you insisted, they would have helped you
> port
> the client to Java and offered you assistance in any way possible.

Highly unlikely considering that the Java clients have not been
released. Especially since they are so intent on not wasting their
time. Why would they suddenly perform an about face and provide
support for another waste?

> To reiterate:
> 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
>   is necessary.

How does one type the sound of flapping lips with fingers?
> 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.

Statements to not establish reality. Java is ideal for the network
communications and protocol functions of the code. No doubt that
hand tuned assembly will produce better key rates. That part can
be confined to the RC5 core. Producing working network, keybuffer,
UI/feature, and protocol components in Java would be productive.

See, my statement contradicts yours. Now, how do we decide which
best represents reality?

> Thank you in advance for your thoughtful and intelligent reply.

I hope that you got one.

To unsubscribe, send email to majordomo at llamas.net with 'unsubscribe rc5' in the body.

More information about the rc5 mailing list