[Passwordsafe-devel] Twofish / Rijndael

[Wolfgang K. <91...@gm...>]

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

Of course not little of your intent to use Twofish goes to respect Bruce 
Schneier who is of the party here - this seems fair enough to me! :)

But still, at this occasion I'ld like to ask about a possible comparison 
between those two AES "finalists". I once searched the NIST pages and 
elsewhere for a technical or practical justification of the "winner" 
choice, but found none. Is there anything that can be said on proof 
grounds about weaknesses and strengths of both algorithms in respect to 
security in application cases or in general? - Are both held as 
equivalent or is Rijndael clearly the better?

- Wolfgang

P.S.  Please give me note if this smail causes list administrative 
problems. I walk from the assumption that I am currently using my 
registered address.

Rony Shapiro wrote:

>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
>_______________________________________________
>Passwordsafe-devel mailing list
>Pas...@li...
>https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
>
>
>  
>