At 11:23 AM 3/1/96 -0500, you wrote:
At the same time am trying to set up a secure mailing system for 80,000 mailboxes (soon to be over 200,000) and the last time I put together a 6,000 key ring on a 386 it took three days & several Mb.
Fortunately, on a site this big, you can afford to use a Pentium or Sparcstation and 32-bit code :-) However, if it took you that long (as opposed to, say 4 hours), you probably were short of RAM and were paging a lot.
This will require a "different" mechanism.
Yup. You may be able to do it within the structure of the current PGP, by dyamically managing keys in separate files (e.g. 80,000 files, or condensations into keyrings of say 100 keys) though it would help immensely to hack the key retrieval code. Under PGP 3.0, you'll have libraries to let you do this stuff; until then it's probably not too hard to build a front-end (stealing the non-RSA portions of PGP) that looks at the keys in a file and calls PGP with a request to use the correct keyring file, or some such hackery. Or, of course, you can license RSAREF and integrate the code yourself. Depending on the email volume, it may be cheaper to just license RSA, so you can use better bignum packages like some of the European PGP flavors. #-- # Thanks; Bill # Bill Stewart, stewarts@ix.netcom.com / billstewart@attmail.com +1-415-442-2215 # http://www.idiom.com/~wcs Pager +1-408-787-1281
the last time I put together a 6,000 key ring on a 386 it took three days & several Mb.
The MIT PGP keyserver now has new non-PGP based code to manage it's keyring of 20,000+ keys. Not sure if you can get the code, or how easy it'd be to adapt to a deployed usage, but presumably it's much more efficient.
the last time I put together a 6,000 key ring on a 386 it took three days & several Mb.
The MIT PGP keyserver now has new non-PGP based code to manage it's keyring of 20,000+ keys. Not sure if you can get the code, or how easy it'd be to adapt to a deployed usage, but presumably it's much more efficient.
How about code that goes out & fetches keys upon demand, al-la DNS? [1st pass thinking is there are too many holes in such a method, even if MIT's server could handle the real-time load...] -- A host is a host from coast to coast.................wb8foz@nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433
David Lesher wrote: | How about code that goes out & fetches keys upon demand, al-la DNS? This works with procmail to get keys for all mail I receive. I discovered the problem is your keyrings get unmanageably large when you do this. # auto key retreival # # I have an elm alias, pgp, points to a keyserver :0BW * -----BEGIN PGP *!^FROM_DAEMON KEYID=|/home/adam/bin/sender_unknown :0 ahc # added h 8 jan 95 * ! ^X-Loop: Adams akr | formail -a"X-Loop: Adams akr" |elm -s"mget $KEYID" pgp # add the incoming keys to the ring :0 * From bal@swissnet.ai.mit.edu { # if we accidentally get the whole thing. :0 h * >10000 /dev/null :0 h *^Subject:.*no keys match /dev/null :0: *Subject: Your command, ADD $DEFAULT :0E | pgp +batchmode -fka } sender_unknown: #!/bin/sh # unknown returns a keyid, exits 1 if the key is known # $output is to get the exit status. Othierwise, this would be a one liner. OUTPUT=`pgp -f +VERBOSE=0 +batchmode -o /dev/null` echo $OUTPUT | egrep -s 'not found in file' EV=$? if [ $EV -eq 0 ]; then echo $OUTPUT | awk '{print $6}' fi exit $EV -- "It is seldom that liberty of any kind is lost all at once." -Hume
| How about code that goes out & fetches keys upon demand, al-la DNS?
That's what the next generation of Distributed Key Server stuff will do.
This works with procmail to get keys for all mail I receive.
As you say, fetching keys for all keys you ever receive will cause your keyring to become excessive ... I prefer to be able to fetch a key in real time when I want to send to it. As such, I wrote a reasonably defined command such that "if the exit code is 0, then stdout is the armoured key for the KeyID or UserID specified on the command line". In future, it'll use the new Distributed Key Server, but until then, it uses a "fast" server (a perl daemon which loads the whole keyring into a DBM backed ASSOC array) or WWW servers. [ Former takes about 500mS locally, but as Sprint appear only to have been making one attempt per week to get the greatly overdue Fat Pipe upgrade going it'll be somewhat more for anyone outside the UK :-(( ] See http://www.pgp.net/pgpnet/#krem if you're interested ... [ Any offers to provide pgp.net services are likley to be greatfully accepted ]
participants (5)
-
Adam Shostack -
Bill Stewart -
David Lesher -
Nelson Minar -
Piete Brooks