Re: [9fans] Hmm, secstore KFS?

Re: [9fans] Hmm, secstore KFS?

[Charles Forsyth]

>>Btw, one thing that's always confused me about secstore; can't one
>>mount a dictionary attack against data that's transmitted across the
>>network from the secstore?  Granted, that's harder, since the attacker
>>would have to snif it and couldn't simply pursue it at his or her
>>leasure, but still possible, or no?

the connection itself is separately encrypted, with digests.

Re: [9fans] Hmm, secstore KFS?

[Dan Cross]

> the connection itself is separately encrypted, with digests.

Granted, but that just raises the bar, it doesn't provide perfect
forward secrecy.

	- Dan C.

Re: [9fans] Hmm, secstore KFS?

[Dan Cross]

> > 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.

Re: [9fans] Hmm, secstore KFS?

[Eric Grosse]

> 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.

> 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.

Eric