RE: PasswordSafe format v3 - discussion

Hi Frank,

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.

	Rony

> -----Original Message-----
> From: Frank Pilhofer [mailto:[email protected]] 
> Sent: Friday, December 02, 2005 2:51 PM
> To: Rony Shapiro; [email protected]
> Subject: Re: [Passwordsafe-devel] PasswordSafe format v3 - discussion
> 
> Hi,
> 
> On Thu, 01 Dec 2005 15:25:20 -0500, Rony Shapiro 
> <[email protected]> wrote:
> >
> > Dave Collins:
> >> I believe we need a MAC to autheticate the data. I propose 
> HMAC-SHA256
> >
> > 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?
> > (2) there should be a special "End of Records" block in the 
> file before
> > the MAC, to assist parsing.
> >
> 
> The end of records block is sufficient to detect truncated files. The
> MAC is only needed if an attacker were able to break the 
> encryption, on
> the assumption that the attacker might be able to defeat Twofish but
> unable to defeat the MAC. But if there are attacks on Twofish, we're
> probably screwed anyway.
> 
> >
> >> 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.
> >
> 
> IMHO, file extensions are overrated.
> 
> What I would like to see instead/in addition is a "magic" tag at the
> beginning of the file, i.e. a well-defined string or value 
> that uniquely
> identifies the password safe format and version. (Popular "magic" tags
> are "GIF87" or "JPEG", or even "<?xml".) We could use a 
> 32-bit tag such
> as "PWS3", or the 64-bit tag "PWSafe30". With this magic value,  
> applications
> can quickly check whether a file is a Password Safe database 
> or not. And it
> allows format updates in the future to be less painful, by 
> not requiring
> the app to cycle through all known formats.
> 
> As for the fields in a database, I suggest adding a stand-alone "URL"
> field, rather than the hack of having the URL among the notes.
> 
> Also, this is a good opportunity to change the default character set
> to UTF-8 or UTF-16.
> 
> 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