[rc5] SOURCE CODE AND REQUESTS FOR OTHER PLATFORMS

David Sowder davids at cosmic.swau.edu
Sun Jun 22 01:44:50 EDT 1997


On Sun, 22 Jun 1997, Seth D. Schoen wrote:
> David Sowder wrote:
> >Like I said in my last post, the personal proxy could be placed on a
> >machine that did nothing else (I.e. a 286 or 386 that's just lying around)
> >and would be restricted to only communicate on the RC5 ports.  In this
> >way, the worse thing the untrusted code could do would be to send bogus
> >information to the RC5 servers and/or clients, which would be a stupid
> >thing for the RC5 organizers to program into _their_ personal proxy code,
> >or to erase everything on the personal proxy machine's hard drive, which
> >again would be a stupid thing for the RC5 organizers to put in their code.
> 
> >This arrangement would in effect be the same as someone else running the
> >v1/v2 gateway, just that it would be running on your machine.
> 
> I think that once again there is a problem satisfying conditions which
> all seem to be required by the projects' organizers:
> 
> (1) Any published source code cannot be trusted, in the sense that
> protocols that it implements can be compromised by modifying the source
> code.
> (2) Only trusted code (and coders) can know the v2 protocol.
> (3) Only code written by someone who knows the v2 protocol can implement
> a v1/v2 gateway.
> (4) A trusted coder would not want to allow untrusted code to submit
> blocks to the project [this one, as I said, I'm not sure of, but it seems
> to be the rationale for expiring protocol v1]
> 
> Then, I conclude:
> 
> Everyone trusted the knowledge to create a gateway will be unwilling to
> to create a gateway which will interoperate with published source code.
> 
> (Ironically, someone breaking the security-through-obscurity of the
> new protocol could actually launch a "spoofing attack" to submit
> valid data: they could make a functional v1 client illegitimately
> pretend to be a v2 client by using the v2 protocol, which they had
> reverse-engineered, in order to permit the v1 client to submit its
> (accurate) data to the keyserver.  I would find it very humorous
> if somebody actually did that -- like breaking into a bank vault to
> make a deposit after the bank is closed.)

Equally ironic is the fact that everyone using a precompiled binary is
placing trust in the person who compiled that binary.  In the case of a VMS
binary, that is currently only myself, though that may change if binaries
are need for VMS platforms I can't compile for.  The OS/2 porter is trusted
for his binary as is the MacOS porter.  The organizers have equally placed
trust in these porters to not release the source code of the v2 clients.  As
has been already mentioned on this list, reverse-engineering of the v2
protocol is currently a difficult task because of the lack of strong
authenication, etc.

--
David R. Sowder           sowderd at swau.edu                  davids at hpnc.com
Assistant Director of Information Services           Chief Network Engineer
Southwestern Adventist University              Hypernet Communications Inc.
http://www.swau.edu/~sowderd/                   http://www.jci.net/~davids/

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



More information about the rc5 mailing list