Re: Big Prime number prolem.

From: Jean-Luc Cooke (jlcooke_at_engsoc.org)
Date: 08/12/05 

Date: 12 Aug 2005 13:03:17 GMT

Harlan Lieberman-Berg <sysadmin@tacticalbusinesspartners.com> wrote:
> In my last post I advised against the using of /dev/urandom and favored
> /dev/random because it was /more/ secure. Isn't it true that using a
> finite order context modeler is /more/ secure than using a simple random
> number generator as /dev/urandom does when it runs out of random data from
> /dev/random? IBM believes so.

> "Output generated without random input is theoretically less secure than
> output generated from random input, so /dev/random should be used for
> applications for which a high level of confidence in the security of the
> output is required."

> http://publib.boulder.ibm.com/infocenter/pseries/index.jsp?topic=/com.ibm.aix.doc/files/aixfiles/random.htm

First of all, this is for AIX, not Linux. I'll claim ignorance in that
I don't know how similar AIX's /dev/{u}random is to Linux's.

If it's identical, I still wouldn't worry. If you're concered that
/dev/urandom's PRNG isn't secure enough to stretch 8kbits of seed into
enough kbits of matirial, then I suggest replacing it with Fortuna.
  http://jlcooke.ca/random

I welcome bug reports.

Fortuna using AES in CTR mode for PRNG output. Seed collecting and
state update is done usign 32 pools of SHA-256 hashs. The N-th pool is
used every 2^N reseeds. The AES in CTR mode is re-keyed at most every
0.1 sec and/or 10MB which ever comes first. If you can find the AES key
from the output of CTR mode, then you should we writting a paper or
breaking into banks.

Cheers,

JLC

Relevant Pages

  • Re: Security Engineering vs. Crypto Academics... (was strengthening /dev/urandom)
    ... and weaknesses discovered in the crypto primitives. ... > (it's basically the sum of all of the reseeds plus the number of AES ... > blocks extracted from a particular Fortuna pool). ... I coneeded this is a problem and the proposed change from CTR mode to ...
    (sci.crypt)
  • Re: How strong would randomizing data be ?
    ... >> a good block cipher in CTR mode. ... > In AES the counter is simply incremented. ... It encrypts something which an attacker could known given the IV... ...
    (sci.crypt)
  • Re: How strong would randomizing data be ?
    ... > and your reasons behind creating the design can be easily dealt with ... The number of layers is about the same. ... In AES the counter is simply incremented. ... What I don't undestand is why it would be bad for AES in CTR mode if the ...
    (sci.crypt)
  • Re: What is the speed of the fastest (secure) stream cipher?
    ... Currently there are no stream ciphers faster than AES in CTR mode in ... However interest in stream ciphers seems to have increased recently so ... If AES in CTR is definitely too slow (around 16 cycles per byte), ...
    (sci.crypt)
  • Re: RC4 on AMD64
    ... If the key is the same and the IV is the same and the algorithm does ... combiner at the end (all true in the case of AES in CTR mode and RC4) ...
    (sci.crypt)