Re: Validation flaw addressed in version 2.14

On 11/25/05, Rony Shapiro <[email protected]> wrote:

> The question of how many iterations to use is a tradeoff between slowing
> down brute-force attacks and not making users wait too long on slow
> machines.

The solution we used at Entrust was to make the # of hashes
configurable.  The password database could contain an unencrypted
field that states how many iterations of the hash were used for that
database.  A reasonable default could be chosen and the user could
increase/decrease the number to trade off authentication speed vs
brute force speed.  The group making the PDA version of PasswordSafe
could choose a smaller default # of iterations that work well for
their range of processors.  This way, the PDA people are happy without
holding back the desktop people.

> Since we're doing a compatability break, I'm considering changing the cipher
> and hash algorithms to twofish (mainly because of the bigger blocksize - 128
> bits v.s. 64 for blowfish) and SHA-256 (mainly to get a 256 bit cipher key
> (v.s. 160 for SHA-1), but also to avoid the stigma associated with recent
> attacks on SHA-1 - although the attacks are totally irrelevant to the way
> SHA-1 is used in PasswordSafe). So benchmarks with these algorithms would be
> really useful.

That sounds reasonable to me.  If you are changing the cipher, is
there a reason you are selecting TwoFish over say AES?   I don't have
access to any PDAs for benchmarking but I can try and do some SHA-256
when I get the chance.

Jeff.


-------------------------------------------------------
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://ads.osdn.com/?ad_idv37&alloc_id865&op=click