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


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Greg
Thomas
Sent: Wednesday, November 23, 2005 6:51 PM
To: Rony Shapiro
Cc: [email protected]
Subject: Re: [Passwordsafe-devel] Validation flaw addressed in version 2.14


On 11/23/05, Rony Shapiro <[email protected]> wrote:

> I'd like to ask this list for suggestions for (1) a better solution that
> would keep compatability with previous versions (that is, that previous
> versions 2.x of PasswordSafe will be able to read the new database, and
(2)
> a complete solution, unencumbered by backwards-compatability (that is, a
new
> version of the database format).

I'm afraid I have suggestions for neither; however, wrt. (2) I wonder
if any new proposed solution should be opened up far wider for review
in the appropriate communities. Hopefully, that should  mean that any
new database format won't hit the current problem.

That said, a new database format would be the ideal time to move away
from SHA1 which, although still secure, is perhaps best not used for
new applications.

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. That said, I recognise
that this may decrease the effort required to brute force the Safe as
there are now have a number of different locks each with the same
combination. Maybe with something like AES with a big enough key that
is no longer an issue - I don't know, but then I'm not an expert in
that arena.

This would leave a DB structure along the lines of
[Record 1 length][Timestamp 1][Stuff for encryption][Name 1]|[Password
1]|[Notes 1]
[Record 2 length][Timestamp 2][Stuff for encryption][Name 2]|[Password
2]|[Notes 2]
...
which would mean that [Record n length] and [Timestamp n] were
unencrypted - but the rest of the fields in the record could be copied
independently when syncing databases without a password.

That said, I wouldn't like to hazard a guess as to what would go in
[Stuff for encyption] !

My 2p,

Greg


-------------------------------------------------------
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_idv37&alloc_id865&op=ick
_______________________________________________
Passwordsafe-devel mailing list
[email protected]
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_idv37&alloc_id865&op=click