[rc5] Security, Java, and Source
David M. Putzolu
dputzolu at ideal.jf.intel.com
Thu Oct 9 12:25:05 EDT 1997
David McNett <nugget at slacker.com> wrote:
>"David M. Putzolu" <dputzolu at ideal.jf.intel.com> says:
>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.
I'm glad that the Bovine team doesn't think that the source
decision doesn't make a measurable different in terms of
protection against adversarial key-checkers. WRT other reasons
for hiding the source, it seems to me that the "cohesive and talented"
development team is free to build a canonical source if they want
to. What isn't clear is how this team would become fragmented
and incompetent if they made their source available to all. Other
people could write clients, but such clients would obviously be
crappy compared to the ones produced by the main team.
There is an multibillion dollar industry (the "software industry")
based on the idea of competing products that interoperate
due to published protocols and standards. It seems pretty
odd to me that the Bovine team thinks that a closed shop
model is better in the face of such overwhelming evidence.
I suppose that if IBM was the only company allowed to write
software we would have much better software, and the fact that
Microsoft is starting to dominate will lead to better and
better software as other ISVs die off.
>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.
Why? The Bovine team could maintain a single web site,
given their coherence and talent. Their fine clients
would still be available to all.
>>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 posting is in response to Daniel Carter's of Thu, 09 Oct 97 18:12:39,
where he wrote:
>However the number of people who find assembler hacking a trivial task
>is a far far smaller number, than the number of people who find making
>a change in C code trivial.
>Thus not releasing source code, greatly reduces the number of people
>able to spam the servers.
Clearly, I didn't just invent the idea in my head - it was floating around
the list. I saw Darrell Fuhriman arguing against it and chimed in.
The Bovine team's lack of response on the issue until my admittedly
flippant article appeared justifies my posting - by not disputing Mr. Carter,
despite Darrell's disagreement, it appeared that the Bovine team's
position was being represented. Now that you've provided an
"official" response, the matter is cleared up, and for that I thank
you. However, if Fuhriman and I hadn't posted out arguments,
would it have been cleared up?
>Perhaps a better approach would have been to contact one of the coding
>team and expressing your interest in porting the client to Java.
>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.
Actually, I did send email to the client team during the discussion
about V3 clients. In this email I discussed the idea of Java clients,
along with how such clients would solve security issues. I also
pointed out that the native code method was fairly unsafe and would
lead to a reduction of the potential client population. I didn't save
that email, but I did get an email from Michael Driscoll (fenris at frob.ml.org)
on September 26 at 2:52 PM saying, essentially,
"Don't worry about it." So I did approach the team, and from
the response I got it appeared that Java was being ignored,
>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.
Will a client I write now be compatible with V3 servers?
If not, then this suggestion is worthless, considering that
whatever I write would be quickly end-of-lifed.
>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.
I'll reiterate my original Java points, because there most
definitely appears to be a misunderstanding of them given
what you write:
* A certain number of people, X, will run native code. These
people are participating.
* A certain number of people, Z, will not run native code due
to security risks. Some of these people might be willing to
run Java code.
* As long as Z is non-zero and a Java implementation is able
to crack any keys at all, then X + Z > X. So, there is *some*
benefit to having a Java client.
* Beyond this, a Java client would provide a good, clean codebase
(given a good programmer, which the Bovine team has several of)
for reference when building native clients. Java is a very
readable language - much more than straight C.
* By using Java's native methods capability, it would be possible
to get ALL the performance benefits of "native, targeted,
hand-tuned assembly code." Furthermore, it would NOT be necessary
to re-write all the supporting infrastructure code (network,
GUI, etc.) for every platform.
So, why not use Java?
P.S. Sorry about the stupid MIME crap at the end of my
last message. Microsoft software in action. I think
I've managed to turn it off this time.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 5330 bytes
Desc: not available
Url : http://lists.distributed.net/pipermail/rc5/attachments/19971009/92ff793d/attachment-0001.bin
More information about the rc5