Re: Validation flaw addressed in version 2.14

James,
	If you have unencrypted timestamps and guid's an attacher (Eve i guess) 
could change some of the timestamps and guids and this would cause them 
to over ride you correct data.


James Curran/MVP wrote:
>>>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
> _______________________________________________
> 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_id=7637&alloc_id=16865&op=click