Dealing with variable-size hash algorithms

When cryptlib was created, the block size of a hash algorithm was implicitly
specified by the algorithm being used.  Starting with SHA-2, it's become
trendy to have an infinite number of combinations of hash size for every
algorithm, -256, -384, -512, -512/256, and many more.  Problem is that
cryptlib just has the config values CRYPT_OPTION_ENCR_HASH and
CRYPT_OPTION_ENCR_MAC (and the associated CRYPT_OPTION_KEYING_ALGO), which
don't have any way to specify sub-options around the hash size.

Adding any new options is going to cause problems because it will change the
IDs for existing values, so reading an existing cryptlib .init file won't work
any more.

The possible options are:

1. Use the existing unused CRYPT_OPTION_DUMMY1 as a hash-size option, which
   applies to hash and MAC algorithm use.

2. Add new options CRYPT_OPTION_ENCR_HASH_SIZE, CRYPT_OPTION_ENCR_MAC_SIZE,
   and CRYPT_OPTION_KEYING_ALGO_SIZE.

Option 1 causes no problems but assumes that the preference is for the same
block size for hash and MAC, i.e. SHA-256 implies HMAC-SHA-256.

Option 2 breaks compatibility with existing .init files but allows for e.g.
SHA-256 for hashing while using SHA-384 for MAC and SHA-512 for key
derivation.

Given that algorithms are almost always matched up in terms of perceived
strength, I can't see any strong argument for option 2 where you can have a
512-bit hash combined with a 384-bit MAC, but thought I'd ask on the list in
case anyone has a strong case for option 2.  In particular since currently the
only option is SHA-2 == SHA-256 and no-one's complained about it, it seems
that shouldn't be a huge problem.

Peter.


_______________________________________________
Cryptlib mailing list
[email protected] via Mail: [email protected]
Archive: ftp://ftp.franken.de/pub/crypt/cryptlib/archives/
http://news.gmane.org/gmane.comp.encryption.cryptlib
Posts from non-subscribed addresses are blocked to prevent spam, please
subscribe in order to post messages.