RE: Validation flaw addressed in version 2.14

Hi James!

I'm afraid the "small string are as secure as long strings" theory doesn't
hold. By encrypting the database as one monolithic object, we deny the
attacker much information that she can (theoretically, at least) use to
mount an attack. Basically, the more the attacker knows about the contents
being protected, the easier the attack is. Also, by providing cleartext
information per-record in the database, we potentially allow an attacker to
identify a record of particular interest, and concentrate effort on that.

Now, I'm not saying that it's impossible to design a system where each
record is individually encrypted yet the attacker cannot use this fact to
mount an attack more effective than the whole database encrypted, but I'm
afraid I do not have the resources to design such a system, and I'm not
aware of any off-the-shelf or textbook solution.

BTW - the data is indeed encrypted in blocks of eight bytes, but there is a
strong dependency between blocks - "chaining" - which greatly increases the
security of the system.

As to syncing - there are several ways this might be addressed, but Id' be
very happy to first see a PDA version, other than the 1.9.2c port, which is
over two years old...

	Cheers,

		Rony

> -----Original Message-----
> From: [email protected] 
> [mailto:[email protected]] On 
> Behalf Of James Curran/MVP
> Sent: Thursday, November 24, 2005 9:53 AM
> To: [email protected]
> Subject: RE: [Passwordsafe-devel] Validation flaw addressed 
> in version 2.14
> 
> >> It also raises the opportunity to think about putting in structure
> that encrypts each record individually. That, coupled with a
> timestamp, would allow records to be sync'ed to a PDA without
> prompting the user for the Safe combination. <<
> 
> 	I've been advocating exactly that for a while, for exactly that
> reason.  However, a unencrypted timestamp by itself is not 
> good enough -- We
> also need some way of knowing which entry is which.  I'd 
> recommend adding a
> unencrypted GUID to each record.  The GUID has the advantage 
> of (a) being
> unique and (b) been obscure -- even unencrypted, it provides 
> no information
> about the encrypted data.
> 
> So, to expand upon Greg diagram:
> 
> <unencrypted>[Record 1 length][GUID1][Timestamp
> 1]</unencrypted><encrypted>[Name 1]|[Password
> 1]|[Notes 1]</encrypted>
> <unencrypted>[Record 2 length][GUID2][Timestamp
> 2]</unencrypted><encrypted>[Name 2]|[Password
> 2]|[Notes 2]</encrypted>
> 
> 
> Now, this design brings up a big question (which I don't know 
> the answer to,
> but I'm sure some who actual know about encryption does..)  
> "Is a collection
> of short encrypted string any more or less secure than one 
> big encrypted
> string of approx the same total bytes?"   As I was going through the code
> some time ago, it appeared that encryption was done 8 bytes 
> at a time, in
> isolation (ie, the big string was actually, in effect, a collection of
> 8-byte string, each encrypted independently).  If that is 
> true, it renders
> my previous question moot.
> 
> For my last suggestion, let's go for something radical.... Why are we
> reinventing the database? Why not make the new PasswordSafe 
> file format a
> simple MSAccess file.  Here the structure would be:
> 
> ID		ReplicationID    (PrimaryKey)
> ModTime	DateTime
> Data		Memo		(Holds Name/Password/Notes in encrypted
> form)
> 
> In fact, if the "small string are as secure as long strings" 
> theory is true,
> we can make it:
> ID		ReplicationID    (PrimaryKey)
> ModTime	DateTime
> Name		Text			(Encrypted)
> Password	Text			(Encrypted)
> Notes		Text			(Encrypted)
> 
> That should trivialize all database functions of the 
> application, leaving
> just UI & Encryption.  
> 
> The down side of this is that it loses file-compatibility 
> with non-Windows
> systems, although I wonder how large the need for cross-platform file
> compatibility is.
> 
> The plus side is that it greatly simplifies tools like a sync-er (or a
> conversion tool for those other platforms).  It also prepares 
> the way for
> the next step -- utilizing the build-in database in Windows Vista.
> 
> 
> 
>     Truth, 
>      James Curran
> 




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