Re: Rarity: Crypto question enclosed

["David K. Merriman" <merriman@amaonline.com>]

-----BEGIN PGP SIGNED MESSAGE-----

Mime-Version: 1.0
Content-Type: text/plain
Content-Transfer-Encoding: 7bit

To: mianigand@outlook.net, cypherpunks@toad.com
Date: Mon Nov 11 12:31:25 1996
> > My simple question is regarding key/certificate distribution:
> >
> >         Is there any particular reason that such can't be
> accomplished via
> > on-line lists, and made available via a service on a port, using
> standard
> > (textual) commands, like mail and such are now?
>
> It's possible to have a key-server listen on a port and accept
> requests, then it would
> fork a process, process the result, and return an answer set.
> 
> But how many CPU cycles would it take for a machine to process a
> request, ie going through
> 1000 of keys?  I am not exactly sure, it took a long while on my
> pentium.
> 
> In my opinion, if I were to run a key server as a service, with
> clients connecting and requesting a key
> it shouldn't take more than a minute to get a responce.
> 

Agreed - a proper search algorithm should yield an answer in a few seconds, 
at most.

> >         The things that come to mind are a 'client' request for a
> key, a
> > 'client' submission of a key, an external host requesting a key
> exchange,
> > and the host itself requesting a key exchange with another system
> (only
> > new/changed keys being swapped).
> 
> Had the exact same idea, but came up with an interesting concept. When
> a person submits a key, a PGP process is spawned yeilding the
> following information 1.) The name (peponmc@cris.com) 2.) The real
> name (Michael Peponis) 3.) The key size 4.) Creation date of the key
> 5.) Key finger print
> 
> This information, along with the acutal key would be inserted into a
> SQL Database table
> 
> With a structure similar to this

... <deletia> ...

The reason I brought the idea up here was in the hope that others on the CP 
list could help work out the fussy details of the protocol: what info would 
need to be included for what types of exchanges, what port(s) would be good 
to work with, etc. Platform/implementation would be subject to considerable 
variation - but the idea would survive (hopefully :-)

> 
> It's not that hard, it's performance that's more of an issue.  The
> beauty of my approch would be that initially, there would be alot of
> "Add" requests, resulting in many PGP processes running on the box,
> but eventually, they would tapper off.

Again, implementation on any particular platform using any particular OS 
would be up to the afficionados of said platforms/OS's. I'm more interested 
in the CP list coming up with the protocol/standards.

Dave


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2

iQCVAwUBMoasIsVrTvyYOzAZAQEkTAP+JQtMdr5x+Wz4s6SXchgA4ow3+P9WLpzs
JpjXRbNeHspJ2btlAe4pSgRqSp9oygqJ6Nxpa6DFOC4uB6sl3NaOw8tzcVVJm8GN
+QsGP3KBoeTtRh1xE5yUsFoWmGWSqtDLLhu7bU34TaryLBU/Hvj2mOQXqwXhQlvE
FhE5VETJJ2o=
=LG7t
-----END PGP SIGNATURE-----