[kitten] New s2k and exposing the strength (iteration count) part of s2kparams

[Nico Williams <[e-mail]>]

ISTM that we should:

1) Expose the iteration count of the otherwise-opaque s2k params, and
standardize it, renaming it a strength indication and leaving its
interpretation as mechanism-specific.  I.e., from now on all new
enctypes with s2kparams will have theirs start with a four-octet,
network byte order unsigned measure of strength.

The rationale for this is based on:

a) that utilities like ktutil need access to this in some cases (e.g.,
when KDCs are not reachable)

b) KDC-side admin utilities (e.g., kadmin, LDAP clients of an
LDAP-based KDB) need to know how to set s2k strenght, otherwise
there's no way to ever change the default!

c) we need it to be easy to add at least a synthetic strength
parameter option in administrative tools

d) all new enctypes with s2k functions can be expected to have a
reasonable synthetic strength measure

e) admins can be expected to understand strength measures for specific
enctypes (particularly given how few enctypes/enctype families we'll
have that have opaque s2kparams).

Enctypes can't be expected to have normalized strength measures
though.  I.e., a strength of 4096 may mean one thing to one enctype
and another to a different enctype.

2)  It'd be nice if we could add memory-hard s2k functions.  I'm not
sure what NIST is prepared to consider here.  I guess anything
provably not weaker than PBKDF2 should be acceptable, but I'm not sure
how to construct such a thing (XOR of two s2ks is not necessarily
provably not weaker than either of the s2ks; consider the case where
they are the same s2k!).

For a memory- and compute-hard s2k the strength measure might be
composed of two numbers, one indicating memory strength and the other
indicating compute strength.

Nico
--