Re: Is ansi_cprng.c supposed to implement X9.17/X9.31's RNG?

2014-11-29 Thread George Spelvin
Sorry for the duplicate; I had a crash and I thought the mail was lost.
First message was not quite finished, second is a rewrite from scratch.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Re: Is ansi_cprng.c supposed to implement X9.17/X9.31's RNG?

2014-11-29 Thread Neil Horman
On Sat, Nov 29, 2014 at 12:26:49PM -0500, George Spelvin wrote:
 Sorry for the duplicate; I had a crash and I thought the mail was lost.
 First message was not quite finished, second is a rewrite from scratch.
 --
 To unsubscribe from this list: send the line unsubscribe linux-crypto in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
Responded to your first note
Neil

--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html


Is ansi_cprng.c supposed to implement X9.17/X9.31's RNG?

2014-11-28 Thread George Spelvin
I'm trying to understand the Linux crypto layer, and a lot of
the code I read for guidance I instead end up wanting to fix.

My current itch to scratch is crypto/ansi_cprng.c.

There is a lot of questionable code I'll submit patches for, particularly:

- The rand_data_valid variable, which is actually the amount of
  INvalid data in ctx-rand_data[].  (I'm renaming it to rand_data_pos.)
- The ctx-I and ctx-last_rand_data buffers, which are completely
  unnecessary (and in the latter case, violate anti-backtracking).
- The fact that cprng_init() calls reset_prng_context() with NULL
  key and V inputs, and the latter has special-case code to handle
  that, when cprng_init() sets PRNG_NEED_RESET, so can just omit
  the call entirely.

But there's one thing that I can't figure out, and that is whether
the code is meant to be an implementation of the ANSI X9.17/X9.31 RNG.

It's currently definitely not, because the spec requires periodic input
of a timestamp with some seed entropy, while the code just uses
an incrementing counter.

So I have two paths available:

1. Clarify in comments that, although Based on X9.31 Appendix A.2.4,
   this is very much NOT an implementation thereof.  This is a fully
   deterministic PRNG, while the spec is for an RNG.
2. Alternativelt, change the code to actually use high-resolution
   timestamps for seed material.

In the latter case, I'd use jiffies and random_get_entropy, and provide
a compatible deterministic option for self-testing.  I'd drop the
recommended seedsize to DEFAULT_PRNG_KSZ + DEFAULT_BLK_SZ, but keep the
current implementation's support for an optional starting DT value.

If it isn't provided (the default), the code would generate it fresh
on each call to _get_more_prng_bytes, rather than the current default
to zero.

My problem is I don't know which option is intended.  Is it guaranteed that
CRYPTO_ALG_TYPE_RNG is deterministic?
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html