>I hate to bring rain to the parade, but when I build a dedicated server, I
>don't spend the extra money to add a sound card that would just consume
>extra power. Servers are usually stashed in back rooms or even dedicated
No one said every server needs a sound card. You only need one machine
i
>So personally I think people should forget about mice, sound cards and the
>like. It seems to me that the server problem is the
>big one to solve and if it can be solved by say using when a request
>arrives or a disk access takes place, or an interupt occurs
>- then the same techniques can be us
$30 for a true random source? Seems like a bargain, 'specially
compared to radium and geiger counters and other esoterica being
discussed here. For this application "cheaper is better".
Mike Lempriere wrote:
> I hate to bring rain to the parade, but when I build a dedicated server, I
> don't spen
I realise there are lots of ways to get random data including mouse pointers, sound
cards, etc. Often the simplest solution is to
just poke in a card and be done with it.
A couple weeks ago I posted a message to the effect that if a card is a good solution,
we can probably build it. People h
This noise should probably be whitened by passing through something
like MD5 or SHA in cipher-feedback mode. Also, what if it's not noisy
in the office? I suggest using only the least-significant bit and not
bothering with the microphone. Disconnect it and use the amplifier/ADC
quantum noise. Then
>> > > OTOH, why people don't just read a pile of bytes from /dev/audio
Yep this is what I do. I have a host with a sound card located in a busy
office. I grab sound samples from this system at regular intervals.
The script below takes care of the grunt work and may be of use
to others wanting
- Original Message -
From: <[EMAIL PROTECTED]>
> On 20-Oct-99 at 09:53, Ben Laurie ([EMAIL PROTECTED]) wrote:
> > Exactly. The fundamental point that OpenSSL should have a pool of
> > entropy which it attempts to fill with an appropriate amount of the
> > stuff at appropriate moments is
On 20-Oct-99 at 09:53, Ben Laurie ([EMAIL PROTECTED]) wrote:
> Exactly. The fundamental point that OpenSSL should have a pool of
> entropy which it attempts to fill with an appropriate amount of the
> stuff at appropriate moments is a good one.
I'm not so sure about that. Oh, there's no question
CJ Holmes wrote:
>
> >
> >> Eh? You can already point OpenSSL at a file and tell it to read bytes.
> >> What's the problem?
> >
> >Ben, I am talking about functionality beyond pointing OpenSSL at a file.
> >OpenSSL ought to include the code to generate that file using a sound
> >card or other dev
>
>> Eh? You can already point OpenSSL at a file and tell it to read bytes.
>> What's the problem?
>
>Ben, I am talking about functionality beyond pointing OpenSSL at a file.
>OpenSSL ought to include the code to generate that file using a sound
>card or other device/scheme, and ought to trigger r
From: Mike Lempriere <[EMAIL PROTECTED]>
>
> Am I missing something here? The point is to get a _truly_ random number,
> right?
>
> a) Why not use your processes PID?
> b) Sound card input would also be excellent.
> c) Time read straight from the clock chip helps, it's number of seconds
>
From: Michael R. Batchelor <[EMAIL PROTECTED]>
> >My point is not that it doesn't yield useful randomness but that the
> >assertion that it is _completely unpredictable_ is false. This is, of
> >course, quite different to the assertion that it is not completely
> >predictable, with which I agree
>Am I missing something here? The point is to get a _truly_ random number,
>right?
>
[ many good ideas snipped ]
Most of these items are, in themselves, known to fall between certain
ranges at most points in time. However, taking ALL of these things and
hashing them with SHA gives you a decen
]>
> To: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
> Date: Sat, 16 Oct 99 20:46:56 -0600
> Subject: Re: RNGs - Use input from your sound card!
>
> commercial.
>
> On Sat, 16 Oct 1999 20:18:35 -0400, Michael R. Batchelor wrote:
>
> >>Would it make any
commercial.
On Sat, 16 Oct 1999 20:18:35 -0400, Michael R. Batchelor wrote:
>>Would it make any sense to build a card?
>
>
>As a commercial product or a hobby project?
>
>MB
>
>__
>OpenSSL Project
>Would it make any sense to build a card?
As a commercial product or a hobby project?
MB
__
OpenSSL Project http://www.openssl.org
User Support Mailing List[EMAIL PROTECTED
Terrell Larson wrote:
>
> Would it make any sense to build a card?
Somebody already has, but I keep forgetting who.
Cheers,
Ben.
--
http://www.apache-ssl.org/ben.html
"My grandfather once told me that there are two kinds of people: those
who work and those who take the credit. He told me to
Would it make any sense to build a card?
On Sat, 16 Oct 1999 11:25:14 -0400, Michael R. Batchelor wrote:
>>My point is not that it doesn't yield useful randomness but that the
>>assertion that it is _completely unpredictable_ is false. This is, of
>>course, quite different to the assertion tha
>My point is not that it doesn't yield useful randomness but that the
>assertion that it is _completely unpredictable_ is false. This is, of
>course, quite different to the assertion that it is not completely
>predictable, with which I agree (over any finite time period).
But I think most of thi
- Original Message -
From: Bodo Moeller <[EMAIL PROTECTED]>
> On Wed, Oct 13, 1999 at 04:40:04PM -0300, Miguel Angel Fraga wrote:
> > Bodo Moeller wrote:
>
> [...]
> >> The application has to take care of this, not the library. A generic
> >> solution is not possible; e.g. for servers,
Matthew Ling <[EMAIL PROTECTED]>:
> How does OpenSSL generate random number for the client side during an SSL
> handshaking?
It uses whatever seed the application provides, plus /dev/urandom if
available, plus some low-entropy values. The application is
responsible for seeding.
> Does it reply
- Original Message -
From: Miguel Angel Fraga <[EMAIL PROTECTED]>
To: OpenSSL Users <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; Bodo Moeller
<[EMAIL PROTECTED]>
Sent: Wednesday, October 13, 1999 9:40 PM
Subject: Re: RNGs
> Why not? A hash of the screen
On Wed, Oct 13, 1999 at 04:40:04PM -0300, Miguel Angel Fraga wrote:
> Bodo Moeller wrote:
[...]
>> The application has to take care of this, not the library. A generic
>> solution is not possible; e.g. for servers, you cannot expect the
>> mouse to move at all. The seeding that OpenSSL does aut
René G. Eberhard wrote:
> > Due to a part or fraction of the screen could stay
> > constant (several hashes could stay constant), so
> > several RNG inputs could stay constant.
> > IMHO it seems to be a poor RNG.
>
> I've never checked the current RAND_screen().
> I've worked with SSLeay till ve
How does OpenSSL generate random number for the client side during an SSL
handshaking?
Does it reply on the presence of something like ".rnd" file?
Bodo Moeller wrote:
> On Tue, Oct 12, 1999 at 11:43:01AM -0300, Miguel Angel Fraga wrote:
>
> >> OpenSSL does not contain a "RNG". It uses a cryp
On Tue, Oct 12, 1999 at 11:43:01AM -0300, Miguel Angel Fraga wrote:
>> OpenSSL does not contain a "RNG". It uses a cryptographic PRNG, which
>> you as the application programmer have to initialize by calling
>> RAND_seed() with appropriate input.
>> In the case of Windows, one method for creatin
Ulf Möller <[EMAIL PROTECTED]> wrote:
> > The seed generation *is* the RNG. What happens later is a PRNG, not an
RNG.
> > An RNG with a poor seed is always a poor RNG.
>
> OpenSSL does not contain a "RNG". It uses a cryptographic PRNG, which
> you as the application programmer have to initialize
Rene,
> Miguel
>
> > I was analyzing the RNG routines of OpenSSL, especially
> > those related with Windows environment, RAND_screen seeds
> > the random generator with the contents of the screen. It
> > seems to be a poor RNG.
> > Anybody has a better RNG for Windows?
> >
> > Any ideas, suggesti
> The seed generation *is* the RNG. What happens later is a PRNG, not an RNG.
> An RNG with a poor seed is always a poor RNG.
OpenSSL does not contain a "RNG". It uses a cryptographic PRNG, which
you as the application programmer have to initialize by calling
RAND_seed() with appropriate input.
amanda <[EMAIL PROTECTED]> writes:
> The seed generation *is* the RNG. What happens later is a PRNG, not an RNG.
>
> An RNG with a poor seed is always a poor RNG.
Yes, but there are a number of ways for an RNG to be
poor that will still make it acceptable for use to
seed a PRNG, because the PRN
The seed generation *is* the RNG. What happens later is a PRNG, not an RNG.
An RNG with a poor seed is always a poor RNG.
A.
On Fri, 8 Oct 1999, Reni G. Eberhard wrote:
> > I was analyzing the RNG routines of OpenSSL, especially
> > those related with Windows environment, RAND_screen seeds
>
>Anybody has a better RNG for Windows?
>
>Any ideas, suggestions, or help would be most appreciated.
Yarrow, by Bruce Schneier & co at Counterpane, is often mentioned as
state-of-the-art in software PRNGs, and has all the right Free Software
properties. See http://www.counterpane.com/yarrow.html.
I was analyzing the RNG routines of OpenSSL, especially
those related with Windows environment, RAND_screen seeds
the random generator with the contents of the screen. It
seems to be a poor RNG.
Anybody has a better RNG for Windows?
Any ideas, suggestions, or help would be most appreciated.
Than
33 matches
Mail list logo
