RE: Variable Key Stretching for v3
"Rony Shapiro" <[email protected]>
| Newsgroups | gmane.comp.security.passwordsafe.devel |
|---|---|
| Message-ID | <[email protected]> |
Hm, Interesting idea. I wonder if this will be the weak link of the scheme or not. 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. The number of iterations used should of course be in plaintext, since without it the key-stretch algorithm doesn't "know" when to stop. 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. What say? Rony > -----Original Message----- > From: [email protected] > [mailto:[email protected]] On > Behalf Of Frank Pilhofer > Sent: Saturday, February 18, 2006 7:34 PM > To: Password Safe Development > Subject: [Passwordsafe-devel] Variable Key Stretching for v3 > > Hi, > > the v3 database format uses key stretching to make brute force attacks > against the password harder. The current proposal stretches the key > using 2048 iterations of SHA-256. > > The other day, I was reading Linux Weekly News article on OpenBSD's > crypt_blowfish module, see http://lwn.net/Articles/170248/ > > The major point of the article is, > > "[I]n order to have a future-proof password hashing algorithm, > one must be able to dial up the computational cost of that > algorithm over time. If the cost can be provided as a parameter > - and stored with the hashed password - then password hashing > can be made more expensive [...] while maintaining compatibility > with currently-hashed passwords." > > So I was wondering if we wanted to apply the same idea to Password > Safe. > > We could easily add the number of iterations for the key stretching > algorithm to the file header, instead of using the constant 2048. > Even if that value is not exposed to the user, future versions of > Password Safe could crank up the iterations in a both forward and > backward compatible manner. > > 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 _______________________________________________ Passwordsafe-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel ------------------------------------------------------- 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