RE: Validation flaw addressed in version 2.14

Hi Dave,

Your suggestions are definitely along the lines I've been thinking. Having a
random first block, however, isn't sufficient to address the weakness that
was reported, since that block just serves as the IV for the next block. 

OTOH, using x[r] as the encryption key might make this irrelevant, and is
worth thinking about a bit further.

Moving autotype and URL to their own fields is also a good idea. Converting
existing databases to this should be no problem.

	Thanks!

		Rony 

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of Dave Collins
> Sent: Saturday, November 26, 2005 2:43 AM
> To: [email protected]
> Subject: Re: [Passwordsafe-devel] Validation flaw addressed 
> in version 2.14
> 
> Rony,
> 	I have thought for a few days about trying to make the db backwards 
> compatible and disprove Bruce's comment, however I now think 
> he is right.
> 
> As a starting point for a new format I propose:
> 
> 	Random "Stretching" Salt 256 bits
> 	Salt 256 bits ?
> 	IV 256 bits ?
> 	Header record
> 	Data Record 1
> 	...
> 	Data Record N
> 	MAC
> 
> 	Where the encryption key is computed using the 
> algorithm from page 351 
> of Practical Cryptography.
> 
> x[0] = 0
> x[i] = h(x[i-1] || passphrase || salt)
> Key = x[r]
> 
> Where the number of rounds is to be choosen after further discussion 
> about performance,  r=1000,10000, etc
> 
> The Header record would replace v2 first data record that had 
> "!!!Version 2 File Format!!!" as its name.
> I would say this should have a random block, a version 
> number, followed 
> by preference in a simpler format to the data records.
> 
> To verify the passphrase passwordsafe would generate the key 
> and decrypt 
> the header record. If the header block does parse then we know the 
> password is incorrect.
> 
> The data records would remain unchanged however I would like 
> to propose 
> that autotype text and URL type bytes get added to the type 
> list so we 
> can move them out of the notes field.
> 
> The MAC would enable verification that nobody has tampered with your 
> password safe. I guess this should be HMAC using the hash 
> alogirthm of 
> choice.
> 
> As for algorithms I would obviously choose SHA-256 or SHA-512 
> for hash. 
>   As for block cyphers I think I would like to use Twofish as its the 
> little sister of blowfish.  However I think AES would could be 'sold' 
> easier to potential users.
> 
> Rony Shapiro wrote:
> > Hi,
> > 
> > The good folks at elcomsoft have posted an item regarding a 
> flaw in the
> > passphrase validation for all versions of PasswordSafe.
> > (http://seclists.org/lists/vulnwatch/2005/Oct-Dec/0046.html)
> > 
> > Briefly, it's possible to take advantage of the database 
> structure to bypass
> > the deliberately slow "key stretching" method used to 
> verify the user's
> > passphrase, enabling a faster brute-force dictionary attack than was
> > intended by the designers.
> > 
> > In release 2.14, I've implemented a partial fix to this, 
> basically replacing
> > fixed data with randomness wherever possible in the first 
> block. This is a
> > partial fix, but it's the most I can do without breaking backwards
> > compatability with existing implementations (and it seems 
> that I've already
> > broken compatability with the Java version...).
> > 
> > I'd like to ask this list for suggestions for (1) a better 
> solution that
> > would keep compatability with previous versions (that is, 
> that previous
> > versions 2.x of PasswordSafe will be able to read the new 
> database, and (2)
> > a complete solution, unencumbered by 
> backwards-compatability (that is, a new
> > version of the database format).
> > 
> > Thanks to Jeff & Hagai for bringing the vulnwatch posting 
> to my attention.
> > 
> > 	Cheers,
> > 
> > 		Rony
> > 
> > P.S. - I've decided not to announce this to the user's 
> mailing list for two
> > reasons: 1. The issue is a bit subtle and therefore 
> difficult to explain.
> > Conversely, it's *very* easy to misunderstand as 
> "passwordsafe's security
> > is/was broken". 2. The fix isn't a complete solution to the 
> problem (yet).
> > Of course, 
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > 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_id=7637&alloc_id=16865&op=click
> > _______________________________________________
> > 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_id=7637&alloc_id=16865&op=click
> _______________________________________________
> 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_id=7637&alloc_id=16865&op=click