Re: PGP 3.0/4.0

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 ]