V3 Format Comments

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