Re: [Passwordsafe-devel] First draft of PasswordSafe format v3
Popular easy-to-use and secure password manager
Brought to you by:
ronys
From: DK <dk...@ds...> - 2005-11-29 22:19:58
|
Rony, I have a number of points: 1. Can I question your statement "An implementation supporting this format SHALL be capable of importing from and exporting to the previous (2.x) format."? Is this not a good opportunity to remove all the old code (V1 and V2 support, Blowfish, etc. etc.)? Why not a small "conversion" utility instead? It would be fixed (i.e. last V1 and current V2.14 database -> V3.0 database) on the assumption that V3.nn can also read V3.0. If necessary, the new PWS V3 could call this utility (assume in the same directory as the new program) if it found it was unable to read the database as a V3 database and hence try to convert from V2 and/or V1. This keeps legacy code within PWS to the minimum (i.e. zero)! 2. Why pick SHA-256 and not SHA-512? I make an assumption (not proved) that SHA-512 would have a longer lifespan than SHA-256 - therefore delaying yet another change (to V4?) when a problem is found with SHA-256 (assuming again that it does not also affect SHA-512). 3. I am still against Twofish on the basis that more people, especially those not particularly knowledgeable on ciphers, have heard for AES and have never heard of Twofish. If you want to "sell" the product, you must use something that the "punter" recognises as "good". Also, as Thomas Brooke has said, there are standard libraries available for AES on many platforms which can be used. 4. Finally, a relatively minor point, if this is a "major update", can we have some well defined coding standards published? I admit that I haven't look for them if they have already been published. I have submitted a few updates (most, but not all, accepted - no problem there) and I have taken advantage of your good offices in "massaging" my code to fit your standards. However, I have found it difficult to fit in with the different coding preferences & practices and even formatting around the code. Some code reeks of the "standard example" - like CMyString, CMyTreeCtrl - they work (and they work well) but they could be more expressive of their context and function - it would certainly aid enhancement and bug fixing. Regards, David ----- Original Message ----- From: "Rony Shapiro" <ro...@gm...> To: <pas...@li...> Sent: Tuesday, November 29, 2005 9:32 PM Subject: [Passwordsafe-devel] First draft of PasswordSafe format v3 > Hi, > > First, thanks to all for interesting comments and discussion on this, both > on and off-list. > > Following is my proposal for the new format. Comments and constructive > criticism welcome. > > Cheers, > > Rony > > The format described below has two goals: > 1. To fix a minor design flaw in previous versions of the PasswordSafe > database format. > 2. To replace the underlying cryptographic functions with more advanced > versions. > > Meeting these goals is impossible without breaking compatibility: The new > format will NOT be compatible with existing implementations. An > implementation supporting this format SHALL be capable of importing from > and exporting to the previous (2.x) format. > > A V3 format PasswordSafe will be structured as follows: > > SALT|H(P')|B1|B2|IV|HDR|R1|R2|...|Rn > > Where: > > SALT is a 256 bit random value, generated at file creation time. > > P' is the "stretched key" of the user's passphrase and the SALT, as > defined > by the hash-function-based key stretching algorithm in > http://www.schneier.com/paper-low-entropy.pdf (Section 4.1), with SHA-256 > as the hash function, and 2048 iterations (i.e., t = 11). > > H(P') is SHA-256(P'), and is used to verify that the user has the correct > passphrase. > > B1 and B2 are two 128-bit blocks encrypted with Twofish using P' as the > key, in ECB mode. These blocks contain the 256 bit random key K that is > used > to encrypt the actual records. (This has the property that there is no > known > or guessable > information on the plaintext encrypted with the passphrase-derived key > that > allows an attacker to mount an attack that bypasses the key stretching > algorithm.) > > IV is the 128-bit random Initial Value for CBC mode. > > All the following records are encrypted using Twofish in CBC mode, with K > as the encryption key. > > HDR: The database header, containing the version number, non-default user > preferences, and perhaps other housekeeping information. > > R1..Rn: The actual password entries, in the format described in the V2 > document, with possible additional fields. > > END OF DRAFT > > > > > > ------------------------------------------------------- > 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 > _______________________________________________ > Passwordsafe-devel mailing list > Pas...@li... > https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel |