RE: Variable Key Stretching for v3

Er, what I meant about "the weak link" was: I wonder if in the future we'll
find ourselves increasing the number of iterations as Frank has anticipated,
or if there will be something else, such as a weakness in Twofish or
SHA-256, that will force us to make an incompatible change in the format...

So, there'll be another 32-bit (little-endian) value with the number of
iterations in the database, not less than 2048, after the SALT.

Anyway, since the cost/benefit of this looks very good, I've implemented it
and updated the format document as well - Thanks, Frank!

I think we're getting close to a first beta for 3.0.

	Cheers,

		Rony

> -----Original Message-----
> From: Frank Pilhofer [mailto:[email protected]] 
> Sent: Monday, February 20, 2006 7:09 PM
> To: Rony Shapiro; 'Password Safe Development'
> Subject: Re: [Passwordsafe-devel] Variable Key Stretching for v3
> 
> On Mon, 20 Feb 2006 02:14:07 -0500, Rony Shapiro 
> <[email protected]> wrote:
> >
> > Interesting idea. I wonder if this will be the weak link of 
> the scheme or
> > not.
> >
> 
> It doesn't weaken the scheme at all, as long as 
> implementations of Password
> Safe enforce a certain minimum number of iterations.
> 
> >
> > A nice property of your suggestion is that it allows a time/security
> > trade-off. PDA versions of PasswordSafe might, for example, 
> set the  
> > number of iterations to a lower value.
> >
> 
> Right. You could imagine tuning the number of iterations so 
> that testing
> the password takes a certain amount of time.
> 
> >
> > The number of iterations used should of course be in 
> plaintext, since
> > without it the key-stretch algorithm doesn't "know" when to stop.
> >
> 
> It could be a 32-bit integer between the SALT and H(P').
> 
> >
> > Hm. Another option might be to not put the number in the 
> database at all,
> > and let the aplication test all values after a minimum 
> threshold up to an
> > insane maximum. This has the nice property that wrong 
> passphrases would  
> > take *much* longer to be rejected than for correct passphrases to be
> > accepted.
> >
> 
> I agree with Philip that this is probably not the best idea. The  
> implementation
> has no way of stopping at any threshold of n, because the 
> file may have  
> been
> generated by a future version of Password Safe with a 
> threshold of n+1.  
> And it
> is a bit cruel to the user to block indefinitely, or to tell 
> the user that  
> the
> passphrase is wrong when it fact it is not.
> 
> Frank
> 
> -- 
> Frank Pilhofer, [email protected]
> 
> 




-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642