Re: 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