Dave,
I am not sure that it needs a MAC to detect loss of data. As you found,
loss of data only means that some records are missing from the end and/or
the last record in the database is damaged. This could be detected without
a MAC. The only recovery tool needed is to say we could only retrieve the
first N records - all others that may have been there are lost!
I assume that no record in the database file could be changed without PWS
detecting it, when it tries to open it. Maybe this means we need a MAC per
record (including the header) to detect unauthorised changes? Not sure if
this is actually appropriate or necessary.
Assuming we do add a MAC to the end of the file, does it matter if the MAC
is of the UNENcrypted or the ENcrypted "data & header"?
Trying to be practical, from an implementation point of view, I would
suggest that a MAC of the ENcrypted data would be easier and would only need
to be performed when saving the database i.e. get the new key (we already
have the information), write the data and work out the MAC at the same time,
append the MAC.
I wouldn't think that this was a security exposure as the passphrase would
have to be known to obtain the MACing key.
David
----- Original Message -----
From: "Dave Collins" <TheDaveCollins@...>
To: <passwordsafe-devel@...>
Sent: Thursday, December 01, 2005 11:18 AM
Subject: [Fwd: Re: [Passwordsafe-devel] First draft of PasswordSafe format
v3]
> Forgot to send this to the list.
> Sorry All
>
> -------- Original Message --------
> Subject: Re: [Passwordsafe-devel] First draft of PasswordSafe format v3
> Date: Thu, 01 Dec 2005 07:27:04 +1100
> From: Dave Collins <TheDaveCollins@...>
> To: Rony Shapiro <ronys@...>
> References: <003101c5f52c$75499590$2800640a@...>
>
> Rony,
> This draft of V3 does not have a MAC. I tested v 2.14 last night and i
> could remove bytes from the end of the file and it would still open and
> read in most of the records.
>
> I believe we need a MAC to autheticate the data. I propose HMAC-SHA256
> of the unecrypted records and header. This would then be appended to
> the end of the data and encrypted. This should have a different key
> derived from the B1,B2 or similar.
>
> We would however need to add a "recover a corupted database" method.
>
> I would also propose breaking the perference stored in the header into
> applicaiton preferences and data relating to the current database only.
>
> An example of current database information might be a UUID for the
> database and some information regarding how it is sycronized with other
> databases (master/slave or member of an anarcho-syndicalist commune)
>
> Obligory monty python quote.
> DENNIS: I told you. We're an anarcho-syndicalist commune. We
> take it in turns to act as a sort of executive officer for the
> week.
>
>
> Rony Shapiro wrote:
>> 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
>> Passwordsafe-devel@...
>> 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
> _______________________________________________
> Passwordsafe-devel mailing list
> Passwordsafe-devel@...
> https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
|