Re: Validation flaw addressed in version 2.14

Dave,

I agree but more and more people have heard about AES than Twofish.

"We" (i.e. those interested in encryption, security etc.)  know both were in 
the running for the new US standard but all sorts of people are learning 
more about encryption and there AES is mentioned as the latest & more secure 
alternative (whether it is or it isn't).

Buy any Wireless Router and they talk about poor WEP, better WPA and even 
better WPA2 (using AES) etc. etc.....

David

----- Original Message ----- 
From: "Dave Collins" <[email protected]>
To: <[email protected]>
Cc: "Rony Shapiro" <[email protected]>; 
<[email protected]>
Sent: Saturday, November 26, 2005 11:27 PM
Subject: Re: [Passwordsafe-devel] 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
> _______________________________________________
> 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