// COMPLETE THREAD

Re: A brief comparison of email encryption protocols

2 expanded posts ยท every known parent and child

NODE fa56cb01Re: A brief comparison of email encryption protocols
At 12:01 2/29/96, Laurence Lundblade wrote:
>I think a problem occurs when you have 20 billion of
>these certs (two for every person in the year 2010 or such).  A simple hash
>into a table isn't going to cut it because you a single database (with
>replication?) isn't going to be possible.

BTW, at the rate that memory gets cheaper and smaller, it might be quite
reasonable to have that single database fit alongside your daily appointments
in your shirt-pocket daily organizer and e-mail terminal, in 2010.


+--------------------------------------------------------------------------+
|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091      Tel: (703) 620-4200                                 |
+--------------------------------------------------------------------------+
NODE 70701576Re: A brief comparison of email encryption protocols
The database size is really only half the problem I think.  The bigger
problem is managing the database.  I can't quite see it being possible to
have one organization serve as a distribution point for all keys. With
millions of billions of certs, you're going to have having thousands or
millions of database updates on a daily basis.

It does seem though that if you can truly eliminate revocations then things
get a lot easier.  You never have to go back a check with the issuer about
anything. This will probably work for some applications, but there's
certainly others for which it won't.

LL

At 2:21 PM 2/29/96, Carl Ellison wrote:
>At 12:01 2/29/96, Laurence Lundblade wrote:
>>I think a problem occurs when you have 20 billion of
>>these certs (two for every person in the year 2010 or such).  A simple hash
>>into a table isn't going to cut it because you a single database (with
>>replication?) isn't going to be possible.
>
>BTW, at the rate that memory gets cheaper and smaller, it might be quite
>reasonable to have that single database fit alongside your daily appointments
>in your shirt-pocket daily organizer and e-mail terminal, in 2010.
>
>
>+--------------------------------------------------------------------------+
>|Carl M. Ellison          cme@cybercash.com   http://www.clark.net/pub/cme |
>|CyberCash, Inc., Suite 430                   http://www.cybercash.com/    |
>|2100 Reston Parkway           PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
>|Reston, VA 22091      Tel: (703) 620-4200                                 |
>+--------------------------------------------------------------------------+