[EMAIL PROTECTED] (Yedidyah Bar-David) writes:
How about placing a cheap microphone (with very bad shielding) inside
the case (preferably, right next to the CPU's fan) and sample it, taking
the LSB from each sample?
Sounds pretty good to me, but I am not a physicist, nor a statistician.
I
On Wed, Jun 28, 2006 at 10:10:00AM +0300, Oleg Goldshmidt wrote:
[EMAIL PROTECTED] (Yedidyah Bar-David) writes:
How about placing a cheap microphone (with very bad shielding) inside
the case (preferably, right next to the CPU's fan) and sample it, taking
the LSB from each sample?
Quoth Oleg Goldshmidt:
[snip microphones]
I would not be so sure that it will be random at all. Especiallyclose
to fan.
Of course, a GPS receiver (6 channel) and usage of relative signal
strengths/qualities can be used as seed too ;-)
--
---MAV
Marc A. Volovic
Oleg Goldshmidt wrote:
I would not be so sure that it will be random at all. Especiallyclose
to fan.
I'll clarify my suggestion.
Place the microphone. Whether a noisy environment (where there are a lot
of contributers) or a semi-quiet environment (where even small
contributers make a
Oleg Goldshmidt wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
In any case, after placing the mic, start sampling. Keep playing with
the gain control so that the actual noise is at about 80% of the
maximal sampling range (or, at the very least, no more than 80% of the
sampling range).
Shachar Shemesh wrote:
My little experiment failed to record anything at all from /dev/dsp.
It will take me a little while to get the data.
Does anyone care to look at the attached program and tell me why it
fails to record from the mic?
I've set the mixer independently.
I get a bunch of
On Wed, Jun 28, 2006 at 12:52:44PM +0300, Shachar Shemesh wrote:
Oleg Goldshmidt wrote:
Shachar Shemesh [EMAIL PROTECTED] writes:
In any case, after placing the mic, start sampling. Keep playing with
the gain control so that the actual noise is at about 80% of the
maximal sampling range
On Tuesday 27 June 2006 16:06, Shachar Shemesh wrote:
Yedidyah Bar-David wrote:
At least on the boards I checked this, the sensors give very inaccurate
data - e.g. temperature accurate to 0.5degC. You can't really use that
for random data. I guess Intel's RNG has many more digits.
How
Shachar Shemesh [EMAIL PROTECTED] writes:
My little experiment failed to record anything at all from
/dev/dsp. It will take me a little while to get the data.
I managed to find out what DIEHARD is, but not how to get it. Care
to help?
Hmm... The FSU site seems to have lost it... And there
Shachar Shemesh wrote:
Shachar Shemesh wrote:
My little experiment failed to record anything at all from /dev/dsp.
It will take me a little while to get the data.
Does anyone care to look at the attached program and tell me why it
fails to record from the mic?
I've set the mixer
--=-VjH6m0Nazr7X2Z+qg+5u
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
On Sun, 2006-06-25 at 23:43 +0300, Shachar Shemesh wrote:
Oded Arbel wrote:
If we're on the subject - if you find out you are running out of
entropy, you can simply import some. I have a script on one of my
On Mon, Jun 26, 2006 at 01:05:01PM +0300, Ami Chayun wrote:
Well, after digging around for a bit, I can't say I'm very impressed with
Intel:
82802 Firmware Hub Device Random Number Generator (RNG). The RNG is
dedicated
hardware that harnesses system thermal noise to generate random and
Yedidyah Bar-David wrote:
At least on the boards I checked this, the sensors give very inaccurate
data - e.g. temperature accurate to 0.5degC. You can't really use that
for random data. I guess Intel's RNG has many more digits.
How about placing a cheap microphone (with very bad shielding)
On Tue, Jun 27, 2006 at 04:06:43PM +0300, Shachar Shemesh wrote:
Yedidyah Bar-David wrote:
At least on the boards I checked this, the sensors give very inaccurate
data - e.g. temperature accurate to 0.5degC. You can't really use that
for random data. I guess Intel's RNG has many more digits.
ציטוט Michael Vasiliev:
On Sunday June 25 2006 13:25, Amos Shapira wrote:
[skipped]
In theory, by the by, disk access can ALSO be controlled to a degree
(less than network, but still)... So - whence entropy? Shall we now start
adding external devices via RS232 (some kind of multi-cascade
Hi list,
While trying to generate a gpg keypair in a remote server, I discovered I lack
entropy.
A short research lead me to the following startling fact; Someone suggested to
disable the entropy gathering from popular network cards, including tg3 and
e1000: http://lkml.org/lkml/2006/5/5/107
On Sun, Jun 25, 2006 at 10:59:33AM +0300, Ami Chayun wrote:
This is an extremely bad move. 'Headless' servers with no keyboard and mouse
have very few ways to create random entropy. Since the server in question is
a web server, it both generates little amount of entropy via disk events, and
Quoth Muli Ben-Yehuda:
The theory behind disabling entropy gathering from network sources is
that those can be affected (controlled?) by an attacker. There was a
long thread about this recently on lkml, see thread starting at
http://marc.theaimsgroup.com/?l=linux-kernelm=114684809230875w=2
Simple solution:
generate the entropy in another device -- either physical device attached
to the server or just by pre-determining a random seed (500 bits), and put
it into the entropy poll/PRNG device.
Not-so-simple solution, but adequete:
insert the network module back into place, and
On Sun, 2006-06-25 at 11:53 +0300, Marc A. Volovic wrote:
Quoth Muli Ben-Yehuda:
The theory behind disabling entropy gathering from network sources is
that those can be affected (controlled?) by an attacker. There was a
long thread about this recently on lkml, see thread starting at
On 25/06/06, Marc A. Volovic [EMAIL PROTECTED] wrote:
I pretty much agree with the theory, but Ami's query is correct - whence
to get entropy in this case?
If you have control over the hardware in your server then how about
installing things like http://www.idquantique.com/products/quantis.htm
Omer Zak [EMAIL PROTECTED] writes:
Geiger counters coupled to slightly sub-critical lumps of enriched
uranium can be tuned to provide arbitrarily large amounts of
entropy.
Certainly you don't need enriched uranium for that. Which also means
that such a device can be attached to every server
On Sun, 2006-06-25 at 12:48 +0300, Omer Zak wrote:
On Sun, 2006-06-25 at 11:53 +0300, Marc A. Volovic wrote:
In theory, by the by, disk access can ALSO be controlled to a degree (less
than network, but still)... So - whence entropy? Shall we now start adding
external devices via RS232 (some
On Sunday June 25 2006 18:39, Oleg Goldshmidt wrote:
Omer Zak [EMAIL PROTECTED] writes:
Geiger counters coupled to slightly sub-critical lumps of enriched
uranium can be tuned to provide arbitrarily large amounts of
entropy.
Certainly you don't need enriched uranium for that. Which also
On 25/06/06, Omer Zak [EMAIL PROTECTED] wrote:
This is probably the *real* reason why Iran insists upon enriching its
uranium.
Geiger counters coupled to slightly sub-critical lumps of enriched
uranium can be tuned to provide arbitrarily large amounts of entropy.
And Iran needs to be able to
On Sunday June 25 2006 13:25, Amos Shapira wrote:
[skipped]
In theory, by the by, disk access can ALSO be controlled to a degree
(less than network, but still)... So - whence entropy? Shall we now start
adding external devices via RS232 (some kind of multi-cascade motion
detector ;-)...
Oded Arbel wrote:
If we're on the subject - if you find out you are running out of
entropy, you can simply import some. I have a script on one of my server
that monitors kernel.random.entropy_avail and seeds the pool by getting
some random bits from random.org when its gets too low.
Nice
27 matches
Mail list logo
