On Wed, Jul 16, 2008 at 09:58:41AM -0400, Neil Horman wrote:
>
> No, this was rather a stream of conscious thing, shifting incrementing numbers
> through the buffer, I can certainly make it a simple counter.
Yeah I think a simple counter fits the spirit of the specification
better. It'll also hav
On Wed, Jul 16, 2008 at 09:44:56PM +0800, Herbert Xu wrote:
> On Thu, Jul 03, 2008 at 04:21:02PM -0400, Neil Horman wrote:
> >> + /*
> > +* Now update our DT value
> > +*/
> > + for (i=DEFAULT_BLK_SZ-1;i>0;i--) {
> > + ctx->DT[i] = ctx->DT[i-1];
> > + }
> > + ctx->DT[0] +=
On Thu, Jul 03, 2008 at 04:21:02PM -0400, Neil Horman wrote:
>> +/*
> + * Now update our DT value
> + */
> + for (i=DEFAULT_BLK_SZ-1;i>0;i--) {
> + ctx->DT[i] = ctx->DT[i-1];
> + }
> + ctx->DT[0] += 1;
Is there any reason behind using this algorithm as opposed
On Wed, Jul 16, 2008 at 09:25:40AM -0400, Neil Horman wrote:
>
> I think I have an irc log somewhere where I thought we discussed this, and
> decided that counter mode allowed us a larger period in the random number
> stream, but you're correct, simple AES mode is called for in the
> specification
On Wed, Jul 16, 2008 at 08:45:33PM +0800, Herbert Xu wrote:
> On Thu, Jul 03, 2008 at 04:21:02PM -0400, Neil Horman wrote:
> >
> > + * See http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf
> > + * for implementation details
>
> BTW, any reason why counter mode is used? This document
On Thu, Jul 03, 2008 at 04:21:02PM -0400, Neil Horman wrote:
>
> + * See http://csrc.nist.gov/groups/STM/cavp/documents/rng/931rngext.pdf
> + * for implementation details
BTW, any reason why counter mode is used? This document specifies
simple AES only, with no modes of operations.
Thanks,
--
Vi
Patch 1/2: Add prng files to source tree
Signed-off-by: Neil Horman <[EMAIL PROTECTED]>
prng.c | 409 +
prng.h | 27
2 files changed, 436 insertions(+)
diff --git a/crypto/prng.c b/crypto/prng.c
new file mode 100644
index
