RE: Twofish / Rijndael

"Rony Shapiro" <[email protected]>
Newsgroups gmane.comp.security.passwordsafe.devel
Message-ID <[email protected]>
Hi Wolfgang,
 
From the NIST's report in which they announce their selection of Rijndael
(http://csrc.nist.gov/CryptoToolkit/aes/round2/r2report.pdf), p.91
 
"Each of the finalist algorithms appears to offer adequate security, and
each offers a considerable number of advantages. Any of the finalists could
serve admirably as the AES."
 
The full report has a fairly detailed description of the analysis
methodology and results.
 
    enjoy,
 
        Rony


  _____  

From: [email protected]
[mailto:[email protected]] On Behalf Of
Wolfgang Keller
Sent: Thursday, December 01, 2005 7:46 AM
To: [email protected]
Subject: [Passwordsafe-devel] Twofish / Rijndael



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
<http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click>
&alloc_id=16865&op=click

_______________________________________________

Passwordsafe-devel mailing list

[email protected]

https://lists.sourceforge.net/lists/listinfo/passwordsafe-devel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.