On Wed, Aug 20, 2008 at 8:09 AM, Jonathan Schleifer <[EMAIL PROTECTED]> wrote: > Peter Saint-Andre <[EMAIL PROTECTED]> wrote: > >> Please do some research about TLS. It is not limited to using keys >> (e.g., read RFC 5054). > > Then why are we only talking about keys and verifiying keys here, and > not about secrets and verifiying secrets?
Category errors? At a high level, we have Alice and Bob. They would like to establish a secure connection so that Alice knows she's talking to Bob and vice versa. Each side can locally generate an arbitrary amount of keying material but that doesn't give you authentication. We're assuming that Alice and Bob are going to engage in one out-of-band authentication transaction (fingerprint reading, SAS, SRP, etc.) but would like to have to only do that once. That means that Alice needs to locally store some value that she can use to authenticate Bob in the future and vice versa. To a first order, that value can be one of two things: - A secret shared by Alice and Bob, and established through the initial connection. - The other side's public key (or a digest of the public key). Either of these allows Alice in the future to connect to Bob and verify Bob's identity without another out-of-band transaction. The traditional approach (used by SSH) is to store the public key. This has a number of advantages: - It's directly compatible with fingerprint mechanisms. - It doesn't require confidential storage, just authenticated storage. - It doesn't require special protocol accomodation if your protocol already supports public keys at all. That said, the secret storing schemes work as well. In TLS we'd call this "session caching". -Ekr
