Bill Frantz (frantz@netcom.com)
Mon, 18 Jan 1999 23:50:16 -0700
At 5:11 AM -0700 1/14/99, Ben Laurie wrote:
>James A. Donald wrote:
>> It appears to me that you could cut this crap if whenever you
>> registered with someone, whenever you subscribed to someone,
>> your browser remembered their DH key, and their server
>> remembered your DH key in the manner described by Schneier,
>> chap 22, "Key exchange without exchanging keys.", thus
>> eliminating all public key operations and all the preliminary
>> operations needed to open a channel.
>
>SSL uses "session IDs" for this purpose. However, the server does
>actually have to implement them, and not time them out too quickly. They
>make HTTPS pages nearly as quick as HTTP (after the first one).
If the problem is that it is slow to connect once a week when you log on to
pay your bills, I don't think session caching with session IDs will help.
What might help, particularly if you are verifying certificates on a
relativity slow personal machine is what SPKI calls a certificate result
certificate (CRC).
A CRC is generated to collapse a chain of certificates. In the case of a
browser, it could bypass many public key operations if it just saved the
server's public key and the closest of the expiration dates in the
certificate chain it used to verify the key. The only public key
operations needed then would be those used to establish the session key.
(Yea, I know such a database is susceptible to being hacked by a Trojan. A
Trojan could also install it's own root certificate, or patch the browser.)
-------------------------------------------------------------------------
Bill Frantz | Macintosh: Didn't do every-| Periwinkle -- Consulting
(408)356-8506 | thing right, but did know | 16345 Englewood Ave.
frantz@netcom.com | the century would end. | Los Gatos, CA 95032, USA
The following archive was created by hippie-mail 7.98617-22 on Sat Apr 10 1999 - 01:18:04