[RC5] Possible solution to open source problem.

Mark Nejedlo nejedlo at cae.wisc.edu
Tue Dec 1 12:08:47 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.

don't over trivialize the danger of people returning untested blocks to
try and sabotage the contest.  That is _WHY_ the source is closed.

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

in order to distribute the code freely, any code written in the US would
have to be <=56 bit, and so it wouldn't be excessivly difficult to crack.
Difficult, yes, but anyone who wanted it bad enough and had access to
sufficient computing power could do it.  or could reverse engineer the
code (later).

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

why waste the overhead?  The code may be of academic intrest, but infinite
monkies <http://www.upl.cs.wisc.edu> made their code available after
RC5-56 ended, and you can still get it from them.  follow the links
projects->oldprojects->infinite monkeys.  it is right there for
whomever feels the need, and keeps the bovine source secure.

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

people who need to compile thier own code might (I don't know) be able to
get the source if they were decided to be trustworthy, but dealing with an
encryption scheme would make things less safe.  Encripting would make
special permission a less viable option because it involves tossing an
encription key around, where it can be sniffed, or have more copies as
hacking targets.

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

no figures, but on something where time=money, the academic interest in's
worth slowing down the clients or servers.

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

see above

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

reverse engineering would be a significand danger, because while it may be
possible to sniff or otherwise break the current client security, reverse
engineering would be destructive _AND_ interesting to whomever chose to
try.  Being interesting is what makes it a greater danger.  Again, being
less than 56 bit, reverse engineering probably wouldn't take excessivly
long for someone who new what they were doing.


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