Re: First draft of PasswordSafe format v3

Rony,

I have a number of points:

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."?

Is this not a good opportunity to remove all the old code (V1 and V2 
support, Blowfish, etc. etc.)?

Why not a small "conversion" utility instead?  It would be fixed (i.e. last 
V1 and current V2.14 database -> V3.0 database) on the assumption that V3.nn 
can also read V3.0.  If necessary, the new PWS V3 could call this utility 
(assume in the same directory as the new program) if it found it was unable 
to read the database as a V3 database and hence try to convert from V2 
and/or V1.

This keeps legacy code within PWS to the minimum (i.e. zero)!

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).

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.

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.

Regards,

David

----- Original Message ----- 
From: "Rony Shapiro" <[email protected]>
To: <[email protected]>
Sent: Tuesday, November 29, 2005 9:32 PM
Subject: [Passwordsafe-devel] First draft of PasswordSafe format v3


> Hi,
>
> First, thanks to all for interesting comments and discussion on this, both
> on and off-list.
>
> Following is my proposal for the new format. Comments and constructive
> criticism welcome.
>
> Cheers,
>
> Rony
>
> The format described below has two goals:
> 1. To fix a minor design flaw in previous versions of the PasswordSafe
> database format.
> 2. To replace the underlying cryptographic functions with more advanced
> versions.
>
> Meeting these goals is impossible without breaking compatibility: The new
> format will NOT be compatible with existing implementations. An
> implementation supporting this format SHALL be capable of importing from
> and exporting to the previous (2.x) format.
>
> A V3 format PasswordSafe will be structured as follows:
>
> SALT|H(P')|B1|B2|IV|HDR|R1|R2|...|Rn
>
> Where:
>
> SALT is a 256 bit random value, generated at file creation time.
>
> P' is the "stretched key" of the user's passphrase and the SALT, as 
> defined
> by the hash-function-based key stretching algorithm in
> http://www.schneier.com/paper-low-entropy.pdf (Section 4.1), with SHA-256
> as the hash function, and 2048 iterations (i.e., t = 11).
>
> H(P') is SHA-256(P'), and is used to verify that the user has the correct
> passphrase.
>
> B1 and B2 are two 128-bit blocks encrypted with Twofish using P' as the
> key, in ECB mode. These blocks contain the 256 bit random key K that is 
> used
> to encrypt the actual records. (This has the property that there is no 
> known
> or guessable
> information on the plaintext encrypted with the passphrase-derived key 
> that
> allows an attacker to mount an attack that bypasses the key stretching
> algorithm.)
>
> IV is the 128-bit random Initial Value for CBC mode.
>
> All the following records are encrypted using Twofish in CBC mode, with K
> as the encryption key.
>
> HDR: The database header, containing the version number, non-default user
> preferences, and perhaps other housekeeping information.
>
> R1..Rn: The actual password entries, in the format described in the V2
> document, with possible additional fields.
>
> END OF DRAFT
>
>
>
>
>
> -------------------------------------------------------
> 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