RE: [Passwordsafe-devel] redesign and XML
Popular easy-to-use and secure password manager
Brought to you by:
ronys
From: Rony S. <ro...@gm...> - 2003-05-01 19:13:35
|
Graham, Sounds reasonable - I'd extend your suggestion to encryption of all the fields, not just the password. We're still exposing considerably more information than the current format, though. The ideal format, IMHO, would look like what you've described, however, everything between <PWList> and </PWList> would be stored in encrypted format, so that the attacker wouldn't be able to see where one field ends and the other starts. This probably means diving into the parser a bit, ideally overriding a virtual "ReadList" function, replacing it with a decrypting one, for example. FirstObject's code looks interesting, from their web page. They even have an STL version, which might address my portability concerns. However, their license explicitly states that the code may not be redistributed or republished, which makes it impossible to put the source on SF's site. A problem, this. Any other XML parsers available? Regarding your previous suggestion to replace the standard random() with Yarrow (http://www.counterpane.com/yarrow.html) - I like the idea, but mainly for the "marketing" value. The property you described (repeating a sequence when seeded with the same seed) isn't a flaw, but an intrinsic property of all PRNGs, including Yarrow. The "classic" solution is to seed the PRNG with the system time when the application is started. At any rate, this isn't too much of a flaw - it theoretically makes the generated passwords predictable. (I always change the generated passwords a bit, for this reason, but mainly to remove zeros, capital O's, ones and lowercase ells). There are ways to get a truly random seed, but I don't think it should be a high priority feature. [BTW, I'm not a professional cryptographer, but have taken an undergrad introductory course, and, more importantly, I've been working on IPSec VPN implementations for the past few years, so I have a good working knowledge of applied crypto. At least, I think I do :-)] Rony -----Original Message----- From: pas...@li... [mailto:pas...@li...]On Behalf Of Graham Ullrich Sent: Wednesday, April 30, 2003 7:02 PM To: pas...@li... Subject: RE: [Passwordsafe-devel] redesign and XML Rony, I believe that we could work around your issue #1. Perhaps one of the other guys thought of this; I would recommend converting the CItemData encrypted password to ASCII hex encoding and putting that in the <password> element. In that manner the password is never exposed except during display. I'll defer judgement of issue #2 to experts in the field. Perhaps you are an expert in which case I defer to you. :-) As for database size, a fairly standard ~240 record database used 28K in v1.9x format and 46K in my XML format. The XML version included about twenty application options. Graham > -----Original Message----- > From: pas...@li... > [mailto:pas...@li...]On Behalf Of Rony > Shapiro > Sent: Wednesday, April 30, 2003 11:12 AM > To: pas...@li... > Subject: RE: [Passwordsafe-devel] redesign and XML > > > Hmm, > > This scheme does have some disadvantages relative to the existing format: > > 1. All the passwords exist in unencrypted form in memory during > reading (and > writing) of the file. The current format encrypts (decrypts) the record on > by one, so that no more than a single password is exposed at a given > instant. > 2. Having so much plaintext of known and repetitive strings makes the > ciphertext more vulnerable to known-plaintext attacks. > 3. The database would be significatly larger for a given set of > entries than > the existing format. While the difference is totally > insignificant on a 40G > hard disk, this could be a problem on PDAs. > > The first and last issues are my main concerns. Also, the availability and > footprint of an XML parser for non-Windows platforms. > > Suggestions? > > Rony > > -----Original Message----- > From: pas...@li... > [mailto:pas...@li...]On Behalf Of Graham > Ullrich > Sent: Wednesday, April 30, 2003 4:51 PM > To: pas...@li... > Subject: RE: [Passwordsafe-devel] redesign and XML > > > Andrew, > > No I don't put encrypted CItemData directly into the XML doc. I get the > fields of each CItem Data record in textual form and create the XML doc in > human-readable form. The entire XML document is then encrypted during the > file write. Here is an example 3-record XML document: > > <PWSafe> > <PWList> > <Item> > <Title>first record</Title> > <Username>david</Username> > <Password>ad;sflja</Password> > <Extra/> > <Notes>first note</Notes> > </Item> > <Item> > <Title>new item</Title> > <Username>user</Username> > <Password>a;dslfj</Password> > <Extra/> > <Notes>a;ldfskja; > hello</Notes> > </Item> > <Item> > <Title>another</Title> > <Username>aaa</Username> > <Password>aaa</Password> > <Extra/> > <Notes>another > note > </Notes> > </Item> > </PWList> > </PWSafe> > > > > -----Original Message----- > > From: Andrew Mullican [mailto:mul...@in...] > > Sent: Wednesday, April 30, 2003 8:41 AM > > To: Graham Ullrich > > Cc: pas...@li... > > Subject: Re: [Passwordsafe-devel] redesign and XML > > > > > > Graham Ullrich writes: > > > > > > > > >XML En/Decryption Practices > > >My implementation of XML encryption and decryption may not be > > the best. When > > >writing the file I create an entire XML document in plaintext > > and then call > > >_writecbc() on the entire block. The reverse applies to reads. > > This may not > > >be optimal. CMarkup uses CStrings, but we are allowed to change > > the CMarkup > > >source code and could easily change that to CMyString or > > whatever class we > > >desired. After decryption each record is saved as encrypted > elements of a > > >CItemData object just like we use now. > > > > Do you mean you create an XML document with all of the accounts > > in it, then > > encrypt the entire thing? It sounds like you stick encrypted CItemData > > objects into the XML document, then encrypt the entire thing. Is > > that right? > > > > I'd be curious to see the format of the XML document. > > > > -Andy > > > > > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Passwordsafe-devel mailing list > Pas...@li... > https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Passwordsafe-devel mailing list > Pas...@li... > https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel > > ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Passwordsafe-devel mailing list Pas...@li... https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel |