Subject: Re: Twofish

From: [email-masked]
Date: Tue, 12 Jan 1999 17:10:13 -0800

One question is key size.  PGP key algorithm values have defined key
sizes.  Twofish, like the other AES candidates, can be used with key
sizes of 128, 192, or 256 bits.  (Actually the cipher allows use of any
smaller size key as well.)

In some contexts where symmetric key algorithm values are used, the
key size can be determined from the message format.  For example,
Public-Key Encrypted Session Key Packets use PKCS-1 encoding for the
encrypted session key, and that encoding implicitly determines the
key size (at least to a multiple of eight bytes).

However, this is not always the case.  Symmetric-Key ESK packets
encrypt one key with another, and the two keys' lengths are allowed
to be different.  Only the encrypted key has its length determined by
context, not the encrypting key.  Symmetric key algorithm values are
also used in secret key packets, and there, too, the key lengths cannot
be determined from context.

To deal with this, we have always defined symmetric key algorithm
values to represent both a cipher and a key length.  Blowfish was a
variable-key-length algorithm, but the Blowfish cipher algorithm byte
was defined to represent a 128-bit key version.

In adding Twofish, we should probably either add three values, for
128-, 192-, and 256-bit versions, or we should settle on a single
size.

If we choose a single size, it would probably make sense to have the
Twofish key size be bigger than the 128 bits used by most of our current
keys.  Unlike the other ciphers, Twofish has a 128 bit block size.
(Keep in mind that the block size bears no necessary relation to the
key size, except that bigger is better in both cases.)  All our other
ciphers use a 64 bit block size.  Given this increase in size, we should
probably consider 192 or 256 bits as the Twofish key size.

Either one of these would probably be OK.  Personally, I feel that 256
bits is awfully big for a key.  There is some speculation that the AES
required such a large key to protect against exotic advances in quantum
computing which nobody really expects to happen.  192 bits is more
than enough strength for any reasonable cryptographic attack.  128 bits
is really very strong still, but if we do want to go up, 192 seems more
reasonable to me than 256.  That would be my recommendation.

Hal

---

From: Werner Koch <[email-masked]>
Date: Wed, 13 Jan 1999 11:16:30 +0100

> values to represent both a cipher and a key length.  Blowfish was a

Another way to handle this is to specify a new version for these
packets (5) which carry more information than just the algorithm.

A standard key length (192 for Twofish?) should then be used with
v4 packets.

I know that this is not covered by rfc2440 but we might consider it
for a new release.

  Werner

---

From: Tony Mione <[email-masked]>
Date: Wed, 13 Jan 1999 08:41:44 -0500 (EST)

-----BEGIN PGP SIGNED MESSAGE-----

> be determined from context.

I think we should deal with this issue reasonably soon. We probably cannot
deal with it until the v1.1 spec. However, with the number of symmetric key
algorithms that are being designed with variable key lengths and other
parameters, it will become prohibitive to assign identifiers for
each. Picking a specific key length may be too limiting (a user may WANT
256 bit keys) and this does not handle other variables of the
algorithm. Take, for instance rc6 (another AES candidate) which allows
variable rounds and blocksizes as well. rc6 as specified for the AES the
way I read it will be RC6-32/20/{16,24,32}. The first number is the number
of bits in a block. The second is the number of rounds. The third is the
key size in bytes (it will handle 128,192,and 256 bit keys). Just because
this is the definition for AES does not mean that we should not allow it to
be run with alternate word sizes or rounds.

I would like to (if it is agreeable) add the concept of parameters for
symmetric algorithms to my v1.1 laundry list. It should probably be handled
in a similar fashion to the public-key parameters (for DSA, etc). This
would probably mean specifying an 'Enhanced symmetric-key encrypted
session-key packet' to replace the existing one but I will leave that up to
the group to hash out.

Does this sound reasonable to people?

>...

We should probably choose a single size for the time being. Later, if the
above recommendation gets implemented in the v1.1 OpenPGP spec, we would
define newer algorithm identifiers with variable parameters.

> Hal

Tony Mione, RUCS/NS, Rutgers University, Hill 055, Piscataway,NJ - 732-445-0650
[email-masked]                 W3: http://www-ns.rutgers.edu/~mione/
PGPFP:E2252CCD28733C5B  0B918A4E22BAFA9F     ***** Important: Rom 10:9-11 *****
Author of 'CDE and Motif : A Practical Primer', Prentice-Hall PTR