[RC5] Possible solution to open source problem.

Christophe Dupre duprec at risq.qc.ca
Tue Dec 1 14:49:49 EST 1998


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

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

This is exactly what is (was?) done by the NetTrek Paradise coding team - the 
source was freely avallable, but some servers allowed only "blessed" binaries, 
where all players used the same unmodified client.

I don't think this would be feasible with d.net, because before "blessing" a 
binary, a coder must review the code to make sure there's no glitch - an 
outside coder could have put a small subroutine that leave some blocks 
unchecked under certain conditions.

Or else, free the code, but do not allow code submission from outsiders, which 
is kind of pointless...

(original message follows)

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


-- 

Christophe Dupre
Analyste de systemes, 
RISQ inc.
550 Sherbrooke ouest, suite 250-ouest    Tel: (514) 845-7181, ext 237
Montreal, QC CANADA                      FAX: (514) 845-8083

"Nous ne sommes pas libres de ne pas etre libres, nous sommes obliges de 
l'etre"  -  Fernando Savater


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