Re: Validation flaw addressed in version 2.14

David,
	I agree that more work in the future is likely to be directed as AES. 
However since Twofish went though the same competition as rijndael/AES 
it was analysis by may respected cryptographers so it has been attacked 
and so far found to be resilient.

Dave

[email protected] wrote:
> Rony,
> 
> Re: Preferences - I am surprised, as whenever I have added a function/property 
> to PWS using the standard PWSpref (GetPref & SetPref functions), they have 
> always gone into the Registry!  I must look at the code again.  Maybe my 
> additions have always been more "global" than "database specific" but I do not 
> remember having the option to add (or not) the values to the database nor to 
> signify global vs. local?
> 
> Re: Ciphers - Mainly "marketing".  However, the reason Twofish "has no known 
> attacks as of now" could be because it isn't used much, so why bother trying to 
> attack it? ;-)
> 
> Regards,
> 
> David
> 
> Quoting Rony Shapiro <[email protected]>:
> 
>> Hi David,
>>
>>- The preferences have been moved to the database quite a while ago! They're
>>stored in the Notes field of the header record (actually, only the values
>>that are != default are stored - a minor spca optimization).
>>
>>- I'm currently leaning towards Twofish as the more "natural" evolution,
>>since it is directly derived from Blowfish (main difference being larger
>>block size), and has no known attacks as of now. Any particular reason to
>>prefer AES (aside from "marketing")? I really don't want to offer both and
>>put the onus of choice on the user, who typically has even less of an idea
>>than we do as to which is better...
>>
>>	Cheers,
>>
>>		Rony
>>
>>
>>>-----Original Message-----
>>>From: [email protected] 
>>>[mailto:[email protected]] On 
>>>Behalf Of DK
>>>Sent: Saturday, November 26, 2005 1:56 PM
>>>To: [email protected]
>>>Subject: Re: [Passwordsafe-devel] Validation flaw addressed 
>>>in version 2.14
>>>
>>>Sometime in the past, there was a thought of moving values 
>>>currently stored 
>>>in the Windows registry into the PWS database (things relating to that 
>>>particular database rather than across many - I see another discussion 
>>>ensuing of which values should be included and which should not!).
>>>
>>>If we are redesigning the database and losing backwards 
>>>compatibility, would 
>>>this be a good time to add one or more such records to the 
>>>database after 
>>>any new "header record" and before the "data records"?  Note: 
>>>these must 
>>>allow for the addition of many additional fields as PWS is 
>>>expanded and 
>>>enhanced and allow for prior (new) PWS versions to be able to 
>>>ignore any new 
>>>ones introduced e.g. V3.2 would understand, say, 10 fields; 
>>>V3.5 would 
>>>understand, say, 20 fields but V3.2 could still open a V3.5 database 
>>>successfully by ignoring the extra 10 fields added since it 
>>>was released, 
>>>irrespective of the order of these fields in the record(s).
>>>
>>>I notice that I have assumed that we would be going to V3 
>>>with this new 
>>>format!
>>>
>>>David
>>>
>>>PS. If there was a vote, I would vote for AES rather than Twofish.
>>>
>>>----- Original Message ----- 
>>>From: "Dave Collins" <[email protected]>
>>>To: <[email protected]>
>>>Sent: Saturday, November 26, 2005 12:43 AM
>>>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