RE: First draft of PasswordSafe format v3

Hi David, 

> 
> 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."?
> 

Sure you can - that's why I posted a draft :-)

Seriously, I like the idea of cleaning out old code from the application,
and a conversion utility is certainly a valid means for achieving the above
requirement AND cleaning up the main application. There are some interesting
implementation issues, but probably nothing insurmountable, especially if
the conversion utility can prompt directly for the passphrase.

I also thought about differentiating between old & new databases via the
filename suffix, e.g., v3 databases will have the suffix '.ps3', which would
allow the application to automatically determine whether or not conversion
is required.

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

Hm. The published weaknesses in SHA-1 are actually irrelevant to the
security of passwordsafe. The weakness is in the collision-proofness of the
hash function. PasswordSafe does not rely in any way on this property. The
move to SHA-256 is primarily motivated by the fact that it makes it easier
to move to a 256-bit encryption key, and also in recognition of the fact
that (as Bruce Schneier is fond of saying), aattacks only improve with time.
I think that SHA-256 is enough for the forseeable future. Admittedly,
though, it's a judgement call. By the time an attack is found, there will
probably be other reaons to move to v4....

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

Again, this is a judgement call. Here are my reasons for preferring Twofish
over AES (Rijndael): (a) AES is a *much* larger target, attracting a lot of
effort to attack it. Since Twofish was also an AES finalist, and since it
did not lose for reasons of security, I can assume that it's strength is at
least comparable to Rijndael. Given these facts, Twofish seems the safer
choice. (b) people are probably ignorant of either AES, Blowfish, Twofish or
any specific cryptographic algorithm. If you'll take a look at the
PasswordSafe download stats (roughly 1000 downloads a *day*), you'll see
that this is not a concern. Given the amount of time I spend on supporting
users, I'm not even sure that I *want* passwordsafe to get much more popular
than it already is - 0.5:-) (c) Since the crypto implementation is
compiled-in, and performance was *never* raised as an issue by users, I
don't see that the availability of ready-made libraries or even hardware
acceleration makes a difference. One would have to write (and maintain!) a
special version to take advantage of said hardware...
> 
> 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.
> 

Good point, but I'd really like to concentrate on the cryptography, format
and scheme at this stage. Cleanup will be part of the implementation.

	Cheers,

		Rony






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