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