[dsfjdssdfsd] Should we/4086 focus on key generation, and defer key derivation and key streaming to elsewhere?

[Dan Brown <[e-mail]>]

Hi Random List Members,

 

What classes of "RNGs" are useful (or just used) in cryptography? / Should
4086bis cover them?

 

I provide my three answers to these questions below, but am also interested
in others' answers.

 

Key streams. / No.

 

Key streams take a short shared secret and generate a long key stream
apparently indistinguishable from random. RFC 4086 seems to also cover key
stream (cipher) generation, in Section 6.2 (third paragraph xor'ing one-time
pads) , but it seems too far out of scope for 4086.  CFRG, or each
individual IETF WGs, now covers stream cipher, at least when as one-time
pads.    Beyond one-time pads, key streams may be useful for side-channel
protection, i.e. blinding (or for general purpose non-crypto applications,
in which case, they not crypto security properties may be required).   My
thought; let's exclude key streaming applications from 4086bis and instead
the focus on the more fundamental task of key generation (further below,
after derivation). 

 

Key derivation. / No.

 

Key derivation function take a (shared or not) short secret key, derive yet
more short keys, often customized for a single purpose.  Examples: from TLS
master_key to encryption key; DH raw shared secret conversion to a session
key; perhaps even private DH keys to session keys; passwords to key
conversion via slow, costly function; -- perhaps also even key wrap as in
S/MIME, nonce generation, and even ephemeral secret key generation.  These
seem to be covered by various other specs, so ought not to be included in
4086.  Again, 4086bis ought best to focus of key generation (below).

 

Key generation. / Yes.

 

With no pre-existing short key, this is a task that actually requires some
genuine secret entropy gathering, and perhaps a persistent state (whereas
the streams and derivations are stateless functions).  The output here could
be quite short, since streaming and derivation can easily generate more
keys.  I think it would be good for 4086bis to focus more on this task.  The
term "generation" is a little awkward, because it is does not distinguish
itself well from key derivation.  Note that key derivation and key streaming
already rely on good key generation, so key generation is unavoidable, and
fundamental.

 

///

 

The approach above is task-oriented.  

 

An opposite approach would be tool-oriented: describe RNGs as a general
purpose tool, and how to build them well and so on, and try to target every
possible security goal.  That approach may have poorly defined (or at least
poorly prioritized) set of requirements, but may also have more realistic
implementability.  Perhaps both approaches should be pursued, but I'd hope
for at least a clearly defined set of task-oriented requirements that is
especially careful about key generation.

 

An approach similar to the tool-oriented approach is an attack-oriented
approach, which has been started already in a different thread here, by Nick
M. 

 

Best regards,

 


Daniel Brown


Research In Motion Limited