Re: PasswordSafe format v3 - discussion

All,
	Taking a lead from Rony Here are a number of responses in one.

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

In my experiment I had 4 records in my database. I could visually see 
that one was missing. If I had say 20+ records I might not notice.

If we use the end of record field to detect the end of database then an 
attacher could remove a whole record with a propabillity of success 
something like 1 in 20.

So at minimum we need an end of database indicator and a record count in 
the header.

Rony wrote:
> For detection of truncated files, you're certainly correct - a special
> "end-of-records" marker is sufficient. However, I was considering cut&paste
> attecks as described, for example, in
> http://www.cs.columbia.edu/~smb/papers/badesp.pdf (Section 2.2 and 3). If an
> attacker can, for example, splice and old password file with a new one
> encrypted with the same password, then he can force a user, for example, to
> use an old password instead of a new one.

> I'm not entirely convinced that this is a relaistic threat scenario, though.
> Also, it might be easier to protect against this by using a different B1B2
> key each time the database is saved.

This is leaving it to the implementer. Of which we have about 3 or 4 
different teams at the moment.  We should authericate the database 
against it self rather than relying on correct usage by implementers.


BTW Here in Australia we have a pair of childrens characters called The 
Banana's in Pyjamas. They are called B1 and B2.
http://www.abc.net.au/children/bananas/characters/b1b2.htm


David wrote
 >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 know that data might not be recovered.

The reason we need this functionallity is that if PWS deteched a 
corupted database it should alert the user. I don't think we need a 
seperate tool however we need a method for the user to know the database 
might/is corupt and a way of seeing what is missing. (ie number of 
records missing, view of the part record, etc) The user could then 
decide if the what to proceed with resaving this copy of the database, 
restoring a backup etc.

David wrote
 >
 > 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"?

Yes.  We should apply the "Horton Principle" and authenticate what we 
mean not what we say.  For a beter explaination of horton principle you 
should google or read Practical Cryptography.

The problem with MACing the ENcrypted data is that someone could change 
the ENcypted data and then recalucate the MAC without the user being 
able to detect the change using the MAC. (obviously if the Attacher 
corupted the data the user would notice that).


Bruce what do you think?


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