-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
(hmmm. This isn't good etiquette, start reading a list one minute
and posting the next - but hopefully you'll all agree this is
'on-topic' for this list?).
First a mesage I sent (earlier today to the PGP-Users mailing
list):
It has previously been mentioned that Twofish would be added to
PGP before completion of the AES process. I think everyone would
agree that the move to a 128-bit block, 128/192/256-bit key
cipher is a Good Thing, but the point of this message is to ask
"why the choice of Twofish?"
Is strength (or "expected strength" at this stage) the criteria?
If you're going to select a cipher from the x candidates (many of
which, including Twofish, have only had 8 months peer-review)
then surely you would go for the most ultra-conservative design?
Even better, wouldn't you select a cipher which has been analysed
for a longer period?
Is speed a selection criteria for block ciphers in PGP (if so why
3DES <g>)?
Is heritage the criteria? If so, there are other candidates with
a similar heritage: MARS (Coppersmith) , RC6 (Rivest), Serpent
(Anderson, Biham & Knudsen), Rijndael (Daemen & Rijmen), DFC
(Vaudenay), CAST-256 (Adams) etc.
Are patent issues part of the criteria? We would expect so (in
view of IETF views on this matter and the OpenPGP standard).
This potentially discounts RC6 & MARS and one or two others.
Are some of the more obscure (and of little practical importance
in PGP?) criteria being considered? For example: key agility,
resistance to timing / power analysis, smart card / hardware
implementation, scalability to 64-bit architectures.
I am a great fan of Bruce Schneier (and Twofish actually) - but
isn't it to soon jump on the bandwagon? One notes that Twofish
has received some criticism in AES Conference II papers:
1) "Report on the AES Candidates" by Vaudenay et al. Points
out that S-Boxes should "no longer be called key-dependant". Also
says "consists of a collection of patches" & "we do not think
this design comes from deep investigation". Of course, this
paper is written by the authors of another AES candidate.
2) "An observation on the Key Schedule of Twofish" by Mirza &
Murphy (RHBNC), points out several deficiencies with the key
schedule. Implications unknown, but it does directly contradict
implicit claims in the original Twofish paper.
*None* of the candidates escaped criticism from a "cryptographic
security" point of view, but if one wanted to objectively select
an AES candidate by any combination of the above criteria, would
we logically select Twofish at the moment?
My main concern is that naive users will see "Twofish" &
"Schneier" and create keys specifying this algorithm. Sure, the
User Manual will no doubt state "Twofish is new blah blah blah"
but, in my experience, users never RTFM anyway.
I hope NAI employees don't see this is as a criticism of them (I
have nothing but respect for you guys). Rather, I suspect I'm
missing something quite obvious...
Then someone pointed me to your archives and I had a read through
the posts referring to Twofish.... So my follow-up is:
I'm even less convinced now. The Twofish topic seems to have
started with the comment "because Twofish is one of most
promising candidates for AES". People don't seem to have
challenged this statement (or even discussed it!). Is Twofish
one of the most promising? By what metric? Is it that much
better than all of the other candidates that you should run with
it now? Really? Even after the recent AES Conference II papers?
Even worse there was the comment (I'm not going to publish e-mail
addresses to save embarrassment!): "I suggest *replacing*
Blowfish with Twofish. If you trust one, why not the other?"
Extremely naive! Blowfish and Twofish are radically different
(ok - they are both BFN etc and the key schedule consists of
iterations of a function used in encryption, but come on!).
Years of analysis and faith in Blowfish certainly does not carry
forward to Twofish.
Small changes in block ciphers can move a cipher from "thought to
be secure" to "trivially" broken.
I don't want to "throw a Sternlight" on this point - but frankly
I am concerned.
Please be gentle with replies :-)
Sam Simpson
Communications Analyst
- -- http://www.scramdisk.clara.net/ for ScramDisk hard-drive
encryption & Delphi Crypto Components. PGP Keys available at the
same site.
-----BEGIN PGP SIGNATURE-----
Version: PGP 6.0.2
iQA/AwUBNuP/cO0ty8FDP9tPEQKoqwCeIfOWlbKgecjIQ0U+cR/n9jDaGxAAoPTY
QobcM6dKr6xkAsClFyybjMI4
=ELZ2
-----END PGP SIGNATURE-----