Re: Revised formatv3 description

"Frank Pilhofer" <[email protected]>
Newsgroups gmane.comp.security.passwordsafe.devel
Message-ID <[email protected]>
On Mon, 16 Jan 2006 16:01:25 -0500, Rony Shapiro <[email protected]> wrote:
>
> In light of Frank's comments and some experience I've gained from actual
> implementation, here's a revised version of the format description.
>

Hi Rony,

thanks for the work you're putting into this. The document is shaping up
quite nicely. Three more comments:

>
> 2.8.1 HDR: The database header. All data in the header is written in
> fields, as defined in Section 3. The first field contains the version
> number of the database format. For this version, the value is 0x0300
> (stored in little-endian format, that is, 0x0003).
>

Personally, I find the "0x0003" confusing. Maybe "0x00 0x03" would be
clearer.

>
> 2.10 HMAC: The 256-bit keyed-hash MAC, as described in RFC2104. The value
> is calculated over all of the plaintext fields, that is, over all the  
> data
> stored in all fields (starting from the version number in the header,
> ending with the last field of the last record). The key L as stored in B3
> and B4 is used as the hash key value.
>

Reading RFC2104, I find that it requires a separate definition of the hash
function that is used:

    This document specifies HMAC using a generic cryptographic hash
    function (denoted by H). Specific instantiations of HMAC need to
    define a particular hash function.

So you should say something like

   2.10 HMAC-SHA256: The 256-bit keyed-hash MAC, as described in RFC2104,
   using SHA256 as its hash function.

>
> 3.1 Field types (based on the v2 format):
>

Please add, from formatV2.txt:

    Timestamps are stored as 32 bit, little endian, unsigned integers,
    representing the number of seconds since Midnight, January 1, 1970,	
    GMT. (This is equivalent to the time_t type on Windows and POSIX.
    On the Macintosh, the value needs to be adjusted by the constant
    value 2082844800 to account for the different epoch of its time_t
    type.)

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
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.