Re: First draft of PasswordSafe format v3

Rony,

I would not use a file extension to make any decisions on content!

There is no need to have any special value.  PWS will open any file you give 
it.  Some people may even change the extension so that no one would know 
that it was a PWS database - why not masquerade a PWS database as a 
spreadsheet ("xls")?

I think simple logic prevails.

Try V3 - OK use it
Call Conversion utility (which is a completely separate program and must 
verify passphrase in order to open any V1 or V2 database):
 - try V2 - OK: convert it to <old filename>.ps3; set good return code
 - try V1 - OK: convert it to <old filename>.ps3; set good return code
else set bad return code.
Return to PWS V3
If bad return code - none worked - tell user can't be opened - exit or ask 
whether to create a new V3 database.
If good return code - open converted file (asking for passphrase of 
course!).

Note: the Conversion utility could even be a command line program with one 
parameter - the file concerned.  Could even be used stand alone.  There is 
no need for every program to have a GUI!

David

----- Original Message ----- 
From: "Rony Shapiro" <[email protected]>
To: "'DK'" <[email protected]>
Cc: <[email protected]>
Sent: Wednesday, November 30, 2005 8:06 PM
Subject: RE: [Passwordsafe-devel] First draft of PasswordSafe format v3


> Hi David,
>
>>
>> 1. Can I question your statement "An implementation supporting this 
>> format
>
>> SHALL be capable of importing from and exporting to the previous (2.x)
> format."?
>>
>
> Sure you can - that's why I posted a draft :-)
>
> Seriously, I like the idea of cleaning out old code from the application,
> and a conversion utility is certainly a valid means for achieving the 
> above
> requirement AND cleaning up the main application. There are some 
> interesting
> implementation issues, but probably nothing insurmountable, especially if
> the conversion utility can prompt directly for the passphrase.
>
> I also thought about differentiating between old & new databases via the
> filename suffix, e.g., v3 databases will have the suffix '.ps3', which 
> would
> allow the application to automatically determine whether or not conversion
> is required.
>
>>
>> 2. Why pick SHA-256 and not SHA-512?  I make an assumption (not proved)
> that SHA-512 would have a longer lifespan than SHA-256 - therefore 
> delaying
> yet
>> another change (to V4?) when a problem is found with SHA-256 (assuming
> again that it does not also affect SHA-512).
>>
>
> Hm. The published weaknesses in SHA-1 are actually irrelevant to the
> security of passwordsafe. The weakness is in the collision-proofness of 
> the
> hash function. PasswordSafe does not rely in any way on this property. The
> move to SHA-256 is primarily motivated by the fact that it makes it easier
> to move to a 256-bit encryption key, and also in recognition of the fact
> that (as Bruce Schneier is fond of saying), aattacks only improve with 
> time.
> I think that SHA-256 is enough for the forseeable future. Admittedly,
> though, it's a judgement call. By the time an attack is found, there will
> probably be other reaons to move to v4....
>
>> 3. I am still against Twofish on the basis that more people, especially
> those not particularly knowledgeable on ciphers, have heard
>> for AES and have never heard of Twofish.  If you want to "sell" the
> product, you must use
>> something that the "punter" recognises as "good".  Also, as Thomas Brooke
>> has said, there are standard libraries available for AES on many 
>> platforms
> which can be used.
>
> Again, this is a judgement call. Here are my reasons for preferring 
> Twofish
> over AES (Rijndael): (a) AES is a *much* larger target, attracting a lot 
> of
> effort to attack it. Since Twofish was also an AES finalist, and since it
> did not lose for reasons of security, I can assume that it's strength is 
> at
> least comparable to Rijndael. Given these facts, Twofish seems the safer
> choice. (b) people are probably ignorant of either AES, Blowfish, Twofish 
> or
> any specific cryptographic algorithm. If you'll take a look at the
> PasswordSafe download stats (roughly 1000 downloads a *day*), you'll see
> that this is not a concern. Given the amount of time I spend on supporting
> users, I'm not even sure that I *want* passwordsafe to get much more 
> popular
> than it already is - 0.5:-) (c) Since the crypto implementation is
> compiled-in, and performance was *never* raised as an issue by users, I
> don't see that the availability of ready-made libraries or even hardware
> acceleration makes a difference. One would have to write (and maintain!) a
> special version to take advantage of said hardware...
>>
>> 4. Finally, a relatively minor point, if this is a "major update", can we
>> have some well defined coding standards published?  I admit that I 
>> haven't
>
>> look for them if they have already been published.   I have submitted a
> few
>> updates (most, but not all, accepted - no problem there) and I have taken
>> advantage of your good offices in "massaging" my code to fit your
> standards.
>> However, I have found it difficult to fit in with the different coding
>> preferences & practices and even formatting around the code.
>> Some code reeks of the "standard example" - like CMyString, CMyTreeCtrl
>> - they work (and they work well) but they could be more expressive of
>> their context and function - it would certainly aid enhancement and bug
> fixing.
>>
>
> Good point, but I'd really like to concentrate on the cryptography, format
> and scheme at this stage. Cleanup will be part of the implementation.
>
> Cheers,
>
> Rony
>
>
>
>
>
>
> -------------------------------------------------------
> 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