RE: Validation flaw addressed in version 2.14

Hi Jeff,

Nice solution. However, I see one potential and two practical problems with
this appraoch. 

1. You mentioned that this solution was used in Entrust. For me, this means
that there's a possibility that Entrust patented this idea (don't laugh -
patents have been granted on far more trivial things). Without a patent
search, or explicit written permission, I'm afraid that we can't use this
solution (another possibility would be to find a public domain
implementation of this idea pre-dating Entrust's implementation).

2. I've no idea what the target audience was for the solution that allowed
this to be user-configurable, but believe me, the user-base of PasswordSafe
is about as non-technical as you can imagine... I shudder to think of the
questions I'll see on the support forum with such a feature. Of course, a
nice twist on this idea would be to let the application or the installation
procedure determine this value automatically depending on the target CPU,
but this brings up objection #3, which is, IMHO, the showstopper.

3. The common use-case for PDA owners is to share the same database file
with a PC. Now, the number of hashes cannot be changed without recalculating
the hashed value, which means that a simple copy is infeasible...

	Cheers,

		Rony

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Jeff Gilchrist
> Sent: Friday, November 25, 2005 5:01 PM
> To: Rony Shapiro
> Cc: [email protected]
> Subject: Re: [Passwordsafe-devel] 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=ick
> _______________________________________________
> 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://ads.osdn.com/?ad_idv37&alloc_id865&op=click