Wouter Wijngaards wrote:

> The iterations field, as it would be used to defend against dictionary
> attacks, thus has to increase as computing power increases. If computing
> power doubles, iterations has to double to provide the same protection.
> A 16 bit field can only double 16 times. Depending on how long you think
> it takes for computing power to be 16x as powerful, at that time the
> iterations field will be 'too small' to provide the same level of
> defense against dictionary attacks. To allow for further growth, a
> longer bitfield may be prudent.


Fair enough. However, we need to reconcile this with section 10.2. The
table in 10.2 is based on the *ratio* of hash speed to verification
speed, and thus will remain fairly constant as general computing power
increases.

> A reply at the workshop was that a new hash algorithm, the '1024x SHA-1'
> (or something along those lines) algorithm can be defined in that event,
> that would provide an extension for the iterations field.


um, ick. It would certainly work, though.

> An alternative could be to use the iterations field as 15bit, and use
> the high 16th bit to denote a 256x increase in value. This results in
> the same range of values for iterations as before (albeit with less
> granularity).
>
> Note I am only discussing the 16-bit iterations. Flags field is fine.
>
> I also have not met people that voiced a high iterations count was
> important to their interests.


I'm of the opinion that if we feel we need to be able to express a
higher number of iterations, just allocate another octet to the field.
No big deal. It is clear to me, however, that we don't really have any
clue as to what the maximum expressible iterations value should be.

--
David Blacka
Sr. Engineer VeriSign Infrastructure Product Engineering

--
to unsubscribe send a message to namedroppers-request@ops.ietf.org with
the word 'unsubscribe' in a single line as the message text body.
archive: