[RC5] Possible solution to open source problem.

dan carter motion at es.co.nz
Tue Dec 1 21:24:16 EST 1998


OK, now we'd all love to have the distributed.net code open sourced to
a nice CVS server so that we can all have a hack at the code. The
problem is that such a move opens the project to sabotage in that
people could
return to the servers blocks without testing them etc.

Now, the present system is that only trusted coders have access to the
source.  However i had a thought last night of an alternative approach.
This seems too obvious to me, so i'm guessing there's big security
holes
that i've missed so feel free to shoot me down.

The idea is that the code be made freely available, but only binaries
produced by trusted coders be allowed to return blocks.
Simple eh? But how to enforce it:

Using an asymetric (public key) encryption algorithm each block is
encrypted using a private key.  The private key is obviously not
included in the public source but is something added by 'trusted
coders' before compiling official binaries. The proxies decode the
blocks sent by clients.  If the blocks decode correctly using the
public key then they are authenticated as produced by official clients.

Clients produced by others won't decrypt with the public key and can be
discarded by the proxies. (Actually a symmettric algorithm might
suffice?)

For reduced proxy overhead all the trusted coders can share the one
key.  For a more flexible approach each coder has their own key, and
the proxies maintain an updateable list of trusted public keys.

Now the negatives of this approach seem acceptable to me:
1) Doesn't meet the needs of those who (for security reasons or
whatever) only run code they've compiled themselves.

2) The encryption will add extra overhead slowing down the clients
operation.  But the encryption is only for each block, not for each
key, and i'm guessing would thus be a very small slowdown (can any
produce some figures here?)

3) Added overhead for the proxies, however no added overhead for the
master keyserver which seems to be where the performance problems lie.

4) It's probably possible to reverse engineer the official clients to
extract the private key from them. 
However it's far easier in the present system to reverse engineer
buffer files, or
reverse engineer the network protocol through network sniffing, so the
risk is still reduced while adding open source benefits.


I'm also thinking the lessons learnt in the SHTTP, S/MIME, and SSL
camps could be applicable, but i've had no involvement in those fields
myself.

So, whatd'ya think?

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