From mboxrd@z Thu Jan  1 00:00:00 1970
Message-Id: <200210122110.g9CLADi15807@augusta.math.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] Hmm, secstore KFS?
In-Reply-To: Your message of "Sat, 12 Oct 2002 16:30:47 EDT."
             <4b887734dcb91087cf86d3ef876b40ce@plan9.bell-labs.com>
From: Dan Cross <cross@math.psu.edu>
Date: Sat, 12 Oct 2002 17:10:13 -0400
Topicbox-Message-UUID: 045ee106-eacb-11e9-9e20-41e7f4b1d025

> > But what then is one to do when one doesn't have a secstore to store
> > things on?
>
> If you use a high-entropy password, then local storage is just fine.

Okay.

> > can't one mount a dictionary attack against data that's transmitted
> > across the network from the secstore?
>
> Like the hypothesized high-entropy password, the session key used for an ssl
> connection comes from such a large search space that brute force attack on
> sniffed data packets should not be a concern.
>
> My recommendation against local storage reflects the observation that in
> practice many people choose modest-entropy passwords that can be cracked
> with modern computers.  Running secstored locally (or, for that matter, on
> any machine where the bad guys can get to /adm/secstore/store/) is no help.
>
> Suppose instead that
> 1) you have a well-defended network server for secstore; and
> 2) some of the local users will choose less-than-superstrong passwords.
> Then the PAK protocol guarantees that none of the early protocol messages
> (before there is a session key) contributes to cracking the password, even
> if the bad guys launch a man-in-the-middle attack.

This is a great explanation.  I was confused as to whether you were
saying was that any dictionary against the crypto was an inherent
weakness, or just when used with a low-entropy key source.  I didn't
realize that you were presupposing a lame key as a prerequisite for
attack against a locally encrypted file.  Thanks a lot!

	- Dan C.