Re: V3 Format Comments

Frank,

I haven't read the document you reference but one thing that I believed was 
agreed with V3 was that all the old clutter relating to previous versions was 
to be removed from the code e.g. no more Blowfish etc. etc.  It was also agreed 
(again I believe) that V3, as it wouldn't "know" anything about prior versions, 
would also not be able to read in previous versions and convert them to V3.  In 
fact, in order to open a non-V3 database, it would call a standalone program 
(that would also prompt for the passphrase) to try and convert it for it.

If all this was agreed, then as you indicate, all V3 documentation must be 
totally stand-alone in their own right and not refer to previous versions.

I have added "I believe" a couple of times above as it is my interpretation of 
the discussion.  I could have mis-understood.

I had better look at this documentation, although I am not conversant with CVS, 
it would be nice if they were available just to be downloaded from the website 
(e.g. as current executable and source code).

Regards,

Davd

Quoting Frank Pilhofer <[email protected]>:

> Hi Rony,
> 
> I just read over the formatV3.txt file that is in CVS, and have a few
> comments, issues and suggestions.
> 
> The document is a bit vague on the HDR (header) field. Is the header
> encoded in the same format as a record, i.e., as a number of fields?
> Please clarify the information and field types for the header. Also,
> what is the "major and minor version number"? IMHO, in light of other
> software that reads and writes Password Safe data files, it does not
> make sense to store the Password Safe version number, but more to have
> a separate version number for the database (which would be incremented
> whenever the database format changes, such as added fields).
> 
> Could you please be more specific about what fields factor into the
> HMAC? The document says that "the value is calculated over all of the
> plaintext fields." IMHO it makes sense to have an explicit list of
> field types. Also, with plain text there is the question of its
> format (i.e., character set: UTF-8, Unicode, local code page; and
> whether it includes the null character or not). You probably want
> to say that the HMAC is computed over the decrypted raw data. Also,
> I wonder why you want to consider plaintext fields only. Aren't the
> other (UUID, timestamp) fields deserving of the same protection?
> And, now that I think of it, the restriction on plaintext fields
> is a concern for future upgrades. If a new version added a plaintext
> field, older versions would not know that its value needed to be
> factored into the HMAC.
> 
> So I suggest to change the paragraph to
> 
>    HMAC: The 256-bit keyed-hash MAC, as described in RFC2104. The
>    value is calculated over the decrypted raw data in all record
>    fields R1...Rn. The key L as stored in B3 and B4 is used as the
>    hash key value.
> 
> Twofish uses 16 byte blocks, rather than Blowfish's 8 byte blocks.
> On this basis, I propose to refine the paragraph that talks about
> the password entries to:
> 
>    R1..Rn: The actual password entries, in the format described in
>    the V2 document (with possible additional fields), but using a
>    block size of 16 bytes.
> 
> A while back, you agreed to introduce a stand-alone "URL" field,
> but it's not documented yet. I think the new format is the perfect
> opportunity for this change, and it would be awkward to add the
> field after the release of 3.0. Could you please add it, e.g., by
> adding a paragraph to the formatV3.txt file like:
> 
>    Added fields for each record for version 3.0 are as follows:
> 
>    Name    Type byte value  Type   Implemented  Comments
>    ------------------------------------------------------
>    URL     0xd              Text   Y            [1]
> 
>    [1] When exporting to V2 format, the URL should be appended
>    or prepended to the "Notes" field.
> 
> Considering that the V3 format makes normative references to the
> V2 format, I also note three inconsistencies that remain in the V2
> document:
> 
>    - Section 3 of the V2 document says that the type byte for the
>      "!!! Version 2 File Format !!!"	is zero. That is incorrect as
>      of Password Safe 2.14, when you decided to make that value
>      "less predictable". I grudgingly note that this change in
>      implementation broke Password Gorilla, which validated the
>      type byte to be zero (and then concluded that the file was
>      not in V2 format).
>    - Section 4 of the V2 document incorrectly states that "textual
>      data will be stored in Unicode". In fact, textual data is
>      stored in the current code page (locale) unless the "IsUTF8"
>      preference is true.
>    - Section 4 of the V2 document incorrectly states that "numerical
>      data will be stored in network byte order". In fact, numerical
>      data is always stored in little endian byte order.
> 
> As a side note, I think it would be useful to have a stand-alone
> documentation for the V3 file format. At the moment, V3 normatively
> references V2, and V2 normatively references V1. (With "normatively",
> I mean that it is not possible to implement V3 without knowledge of
> V2.)
> 
> I hope that you don't consider some of the above "ranting." It's
> just that I value concise specifications. For V2, it basically was
> not possible to understand the file format without reverse
> engineering Password Safe. While this is easy to do considering
> Password Safe's Open Source nature, I get disappointed about having
> to reverse engineer over interpretation issues, and I get frustrated
> when implementations disagree with specifications. We have the
> opportunity to set the bar higher for the new format, so that we
> have less interpretation/compatibility issues going forward.
> 
> Frank
> 
> 
> -- 
> Frank Pilhofer, [email protected]
> 
> 
> -------------------------------------------------------
> 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