PasswordSafe format v3 - discussion

Hi,

Thanks to all for reviewing and posting comments ot the draft.

In order to save bandwidth, I'll respond to all comments in this single
post. My responses are in the order the comments were received, except where
the contents overlap:

Bruce Schneier wrote:

> I like it.
>
> Are there any changes that should be made to the database format, as long
as compatibility is being broken? 

My reply:

Thanks! I don't see any reason to change the basic record format - a
collection of tagged fields, terminated by a special "end-of-record" field.
Dave Collins suggested adding a MAC to authenticate (verify integrity) the
data, discussed below:

Dave Collins:

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

This is, in principle, a Good Idea. It can certainly protect a database
against cut&paste attacks. The question is, how vulnerable is the database
to such attacks in practice? IIRC, cut&paste attacks can succeed if a single
corrupted block is acceptable (e.g., can be attributed to a garbled packet)
- this is not the case in PasswordSafe. Note also that a "recover corrupted
database" method seems to defeat the purpose of the MAC. Implementation
notes: (1) The MAC key should be randomly generated and stored in a similar
manner as the encrytion key, i.e., B3 and B4. (2) there should be a special
"End of Records" block in the file before the MAC, to assist parsing.
Summary: I'm leaning towards implementing this, even though it entails some
more work, unless someone can convince me that it's really unnecessary in
the context of the application. Any input on the list greatly appreciated!

Davis also suggests some administrative data in the header, which I've no
problem with. Also, Monty Python Rocks!

DK:

> I would not use a file extension to make any decisions on content!

That was not my intent: A different suffix would merely be a useful
convention for managing versions. The logic DK outlined can be used in any
case.

Nigel Pentland, OTOH, points out that a distinctive suffix makes it easier
to launch PasswordSafe by association, by double-clicking the database.
Also, ".ps3" is apparently "taken", so ".psafe3" seems more reasonable.

One point about the conversion utility: Under no circumstances should
PasswordSafe pass the passphrase to it as a parameter! Doing so would make
it trivailly easy to intercept a password. This means that the utility
should prompt the user for the passphrase.


	Cheers,

		Rony




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