Transforming variable-length to fixed keys

Adam Back aba at dcs.ex.ac.uk
Tue Sep 24 16:35:00 PDT 1996



Peter Guttmann <pgut001 at cs.auckland.ac.nz> writes on cpunks:
> I posted this to sci.crypt recently but the response to it was rather
> underwhelming, so I thought I'd repost it here to see if anyone has any
> comments on it.  What it is is a scheme for transforming arbitrary user keys
> (typically a long passphrase) into a fixed-length key for a particular
> algorithm.  This has the following properties:

> 1. The user key 'userKey' is transformed into an algorithm-specific key 'key'
>    using a number of 'iterations' of a hash algorithm 'hash()'.
>
> 2. The transformation is strongly serialized so that any form of attack
>    involving parallelization or precomputation isn't possible.

If the speed of your key generation is an issue, you could do
something like:

   key[] = { 0 };
   const int nhashes = 4;
   typedef void (*hashfnptr)(byte*, byte*, int);
	/* array of hash functions */
   hashfnptr hash[ nhashes ] = { md5, sha1, haval, ... };

   state = hash[ 0 ]( algorithm, mode, parameters, userKey );

   for count = 1 to iterations
      for length = 1 to keyLength (in hash_output_size blocks)
		/* selecting a hash function based on the state */
         state = hash[ state % nhashes ]( state );
         key[ length ] = hash[ state % nhashes]( state, userKey );

This provides more expense in hardware for the same expense in
software, so for the same CPU time you get more hardware expense, and
could reduce the iterations for the same security.

`nhashes' determined by the number of digest algorithms you consider
trustworthy.

(They need hardware for `nhashes' different digest algorithms).

You need to do something about resolving the differing output and
state sizes.

Probably speed isn't an issue though.

Adam






More information about the cypherpunks-legacy mailing list