Re: seeding /dev/random from a security key
On Tue, Mar 26, 2024 at 7:12 PM Björn Persson wrote:
>
> Jeffrey Walton wrote:
> > For what you want to do, and if I am parsing it correctly... I would
> > write a daemon in C [...]
>
> Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
> somehow. Writing and compiling a daemon is no less work than compiling
> an already written daemon.
>
> > The part about extracting the entropy from the source would use
> > OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
> > libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}.
>
> RNGD 6 actually uses OpenSC's libp11, where it calls the function
> PKCS11_generate_random, which in turn calls the PKCS #11 function
> C_GenerateRandom.
It sounds like you have it sorted out. Good luck with it.
Jeff
Re: seeding /dev/random from a security key
Jeffrey Walton wrote:
> For what you want to do, and if I am parsing it correctly... I would
> write a daemon in C [...]
Only in the unlikely case that both RNGD and SCDrand turn out unsuitable
somehow. Writing and compiling a daemon is no less work than compiling
an already written daemon.
> The part about extracting the entropy from the source would use
> OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
> libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}.
RNGD 6 actually uses OpenSC's libp11, where it calls the function
PKCS11_generate_random, which in turn calls the PKCS #11 function
C_GenerateRandom.
Björn Persson
pgpOK5m0QGWIe.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Tue, Mar 26, 2024 at 11:52 AM Björn Persson wrote:
>
> Jeffrey Walton wrote:
> > Out of morbid curiosity, what hardware are the servers using? RDRAND
> > and RDSEED have been available since about 2012, so it is mostly
> > ubiquitous nowadays.
>
> Do you mean I should add to the e-waste pile by throwing away working
> hardware and buy an entire new computer instead of buying a tiny dongle?
No, I was wondering about the server hardware. I would be surprised to
learn of something without Intel's SecureKey nowadays (assuming it is
x86{-64} based).
> > Be careful of rng-tools. It does not do a good job for non-mainstream
> > generators, like VIA's Padlock Security Engine. And rng-tools did not
> > support generators for architectures, like you would find on ARM,
> > aarch64 and PowerPC.
>
> I figure it can be used with devices it supports even if there are some
> other devices it doesn't support – but it looks like I'd have to build
> it from source myself.
Yeah, I've had to do that in the past. You will also (probably) need
to write a systemd unit file or two.
> > OpenSSL and GnuPG should be
> > able to extract the entropy from the card, and then use it to seed
> > /dev/{u}random.
>
> This job requires a daemon. OpenSSL is a library. Or do you mean its
> command-line tool? So how would I tell that to fetch random data
> through PKCS #11?
>
> GnuPG at least has a daemon called scdaemon. Is that what you mean? So
> how would I tell that to fetch random data through PKCS #11 and write
> to /dev/random?
For what you want to do, and if I am parsing it correctly... I would
write a daemon in C to collect the entropy from the source, then
extract the entropy from the bytes, and then insert the entropy into
the system's random number generator. For entropy extraction, take a
look at HKDF and Krawczyk's paper. Krawczyk does a good job of cleanly
separating entropy extraction from later stage key expansion.
The part about extracting the entropy from the source would use
OpenSSL or GnuPG. I believe you would compile and link to OpenSSL's
libcrypto.{a|so}, or GnuPG's libgcrypt.{a|so}. Since this is a daemon
and not a driver, I believe you can use the shared objects.
I eat my own dog food. I've done similar in the past with both an
EntropyKey and custom on-board generator for a MIPS Creator CI-20 with
the jz4780-rng. For the EntropyKey, I did not even bother decrypting
the stream. I stuffed the encrypted stream right into /dev/random,
because the amount of entropy does not change regardless of the
formatting (encrypted vs unencrypted).
And you may find this interesting... Debian suffers entropy depletion
on /dev/random and can hang components that use it, including
/dev/urandom. It is easy for a userland process to do. All you need is
a stock Debian system _without_ an entropy gatherer like Haveged. Have
your program perform a big read on /dev/random with O_NONBLOCK. The
kernel will return every last bit of entropy it has, and then start
blocking processes. The only way to recover in reasonable time is to
run a daemon like Haveged. I reported it to the devs several years
ago, but there was no interest in fixing it.
Jeff
Re: seeding /dev/random from a security key
Jeffrey Walton wrote:
> Out of morbid curiosity, what hardware are the servers using? RDRAND
> and RDSEED have been available since about 2012, so it is mostly
> ubiquitous nowadays.
Do you mean I should add to the e-waste pile by throwing away working
hardware and buy an entire new computer instead of buying a tiny dongle?
> Be careful of rng-tools. It does not do a good job for non-mainstream
> generators, like VIA's Padlock Security Engine. And rng-tools did not
> support generators for architectures, like you would find on ARM,
> aarch64 and PowerPC.
I figure it can be used with devices it supports even if there are some
other devices it doesn't support – but it looks like I'd have to build
it from source myself.
> OpenSSL and GnuPG should be
> able to extract the entropy from the card, and then use it to seed
> /dev/{u}random.
This job requires a daemon. OpenSSL is a library. Or do you mean its
command-line tool? So how would I tell that to fetch random data
through PKCS #11?
GnuPG at least has a daemon called scdaemon. Is that what you mean? So
how would I tell that to fetch random data through PKCS #11 and write
to /dev/random?
Björn Persson
pgpia22PvZ5bD.pgp
Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Mon, Mar 25, 2024 at 4:33 PM Björn Persson wrote:
>
> In a quest to acquire hardware random number generators for seeding
> /dev/random on servers that lack a built-in entropy source, I'm
> investigating how random data can be obtained from a security key such
> as a Nitrokey, Yubikey or a similar device.
Out of morbid curiosity, what hardware are the servers using? RDRAND
and RDSEED have been available since about 2012, so it is mostly
ubiquitous nowadays.
> RNGD version 6 from https://github.com/nhorman/rng-tools can fetch
> random data through a PKCS #11 interface, but the two versions of RNGD
> in Debian seem to lack that ability. Debian has rng-tools5 and
> rng-tools-debian, but not Neil Horman's version 6. Or am I just failing
> to find it?
Be careful of rng-tools. It does not do a good job for non-mainstream
generators, like VIA's Padlock Security Engine. And rng-tools did not
support generators for architectures, like you would find on ARM,
aarch64 and PowerPC.
> SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain
> random data from a "smartcard"-compatible device, but I don't find that
> in Debian either.
>
> Does anyone know of another way to obtain random data from devices of
> this kind?
PKCS#11 is a standard interface. If the card provides a generator,
then the code is the same for all cards. OpenSSL and GnuPG should be
able to extract the entropy from the card, and then use it to seed
/dev/{u}random.
But keep in mind ... the kernel crypto folks effectively deprecated
/dev/random, and recommend using /dev/urandom for your random bits. Or
use getrandom(2). See <https://lkml.org/lkml/2017/7/20/993>.
Jeff
Re: seeding /dev/random from a security key
Andy Smith wrote: > EntropyKey is a dead product that can no longer be obtained I've seen several like that. They're permanently sold out, or the webshops are abandoned and half-broken. Pure random number generators that are actually possible to buy are rare. That's why I'm investigating whether security keys can be used instead. Security keys are available from multiple vendors, but it's hard to find any information about the random number generators inside them. > OneRNG is still in production. I tried to buy one of those a while ago, but I couldn't because the shop didn't like my card number. > On their mailing list however, there > is a recent discussion about whether there any point. The conclusion > seems to be "not really". Thread starts here: > > http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html > > The thread covers how to make rngd feed /dev/random from a OneRNG in > Debian 12, but it is no longer possible to tell if that does > anything useful. It is indeed harder to tell since Linux stopped keeping track of the entropy level, and it's now necessary to force-feed /dev/random periodically instead of waiting for the entropy level to drop. A random number generator is still useful on a server with no keyboard, no spinning disk and no RDRAND or similar processor instruction. Otherwise network traffic becomes the only source of entropy, and I'd rather not rely solely on events controlled by other computers. It also helps to mix entropy from multiple sources, in case one of them has a design flaw or a backdoor, or breaks down, or loses its driver like in Debian bug 1041007. Björn Persson pgpEuWy2nx_ME.pgp Description: OpenPGP digital signatur
Re: seeding /dev/random from a security key
On Mon, Mar 25, 2024 at 06:09:02PM -0400, e...@gmx.us wrote: > On 3/25/24 17:27, Andy Smith wrote: > > The thread covers how to make rngd feed /dev/random from a OneRNG in > > Debian 12, but it is no longer possible to tell if that does > > anything useful. > > If not from devices like this, from where does Debian get its randomness? random(4) (i.e. "man 4 random") gives a basic introduction to the topic, if you have manpages-dev installed.
Re: seeding /dev/random from a security key
On 3/25/24 17:27, Andy Smith wrote: The thread covers how to make rngd feed /dev/random from a OneRNG in Debian 12, but it is no longer possible to tell if that does anything useful. If not from devices like this, from where does Debian get its randomness? -- For is it not written, wheresoever two or three are gathered together, yea they will perform the Parrot Sketch. -- Rob on ASR
Re: seeding /dev/random from a security key
Hi, On Mon, Mar 25, 2024 at 09:24:23PM +0100, Björn Persson wrote: > Does anyone know of another way to obtain random data from devices of > this kind? I have some EntropyKeys and some OneRNGs. I have the rngd packaged in Debian feeding /dev/random from them. This had an actual noticeable effect in Debian 9 and earlier, but since the reworking of Linux's random subsystem I cannot demonstrate any benefit unless I disable all use of the RDRAND CPU instruction. EntropyKey is a dead product that can no longer be obtained but OneRNG is still in production. On their mailing list however, there is a recent discussion about whether there any point. The conclusion seems to be "not really". Thread starts here: http://lists.ourshack.com/pipermail/discuss/2024-March/000797.html The thread covers how to make rngd feed /dev/random from a OneRNG in Debian 12, but it is no longer possible to tell if that does anything useful. I most likely will not be replacing these devices when they fail. Thanks, Andy -- https://bitfolk.com/ -- No-nonsense VPS hosting
seeding /dev/random from a security key
Hello! In a quest to acquire hardware random number generators for seeding /dev/random on servers that lack a built-in entropy source, I'm investigating how random data can be obtained from a security key such as a Nitrokey, Yubikey or a similar device. RNGD version 6 from https://github.com/nhorman/rng-tools can fetch random data through a PKCS #11 interface, but the two versions of RNGD in Debian seem to lack that ability. Debian has rng-tools5 and rng-tools-debian, but not Neil Horman's version 6. Or am I just failing to find it? SCDrand from https://incenp.org/dvlpt/scdtools.html can also obtain random data from a "smartcard"-compatible device, but I don't find that in Debian either. Does anyone know of another way to obtain random data from devices of this kind? Björn Persson pgp1OCs1ezY_B.pgp Description: OpenPGP digital signatur
Re: /dev/random
On Sat, Aug 2, 2014 at 11:01 AM, Joel Rees joel.r...@gmail.com wrote: [...] Now, the random typing is not necessary. Well, it's not as rosy as I thought, for /dev/random: duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=16 if=/dev/random iflag=fullblock of=randump2 16+0 レコード入力 16+0 レコード出力 2048 バイト (2.0 kB) コピーされました、 107.939 秒、 0.0 kB/秒 real1m47.945s user0m0.004s sys0m0.012s duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=16 if=/dev/urandom iflag=fullblock of=urandump2 16+0 レコード入力 16+0 レコード出力 2048 バイト (2.0 kB) コピーされました、 0.000850541 秒、 2.4 MB/秒 real0m0.048s user0m0.004s sys0m0.004s I want to take a 2 MB dump from both and run some statistical stuff on them. Which means I'm going to have to start the one for urandom in the morning one day when I'm going to be doing something else with a lot of typing and other entropy improving stuff and see how long it takes to dump 16 kilobytes, and then try 64 kilobytes, and so forth until I have an idea how long it will take. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNEWXiUNByAgZ1=qM3YD+qc0F9PXPvc=qbhg2ildqd...@mail.gmail.com
Re: /dev/random
On Mon, Aug 4, 2014 at 7:52 PM, Joel Rees joel.r...@gmail.com wrote: On Sat, Aug 2, 2014 at 11:01 AM, Joel Rees joel.r...@gmail.com wrote: [...] Now, the random typing is not necessary. Well, it's not as rosy as I thought, for /dev/random: duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=16 if=/dev/random iflag=fullblock of=randump2 16+0 レコード入力 16+0 レコード出力 2048 バイト (2.0 kB) コピーされました、 107.939 秒、 0.0 kB/秒 real1m47.945s user0m0.004s sys0m0.012s duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=16 if=/dev/urandom iflag=fullblock of=urandump2 16+0 レコード入力 16+0 レコード出力 2048 バイト (2.0 kB) コピーされました、 0.000850541 秒、 2.4 MB/秒 real0m0.048s user0m0.004s sys0m0.004s I want to take a 2 MB dump from both and run some statistical stuff on them. Which means I'm going to have to start the one for urandom in the morning one day when I'm going to be doing something else with a lot of typing and other entropy improving stuff and see how long it takes to dump 16 kilobytes, and then try 64 kilobytes, and so forth until I have an idea how long it will take. -- duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=128 if=/dev/urandom iflag=fullblock of=urandump2 128+0 レコード入力 128+0 レコード出力 16384 バイト (16 kB) コピーされました、 0.00482425 秒、 3.4 MB/秒 real0m0.011s user0m0.000s sys0m0.004s duty@deb:~/math_work/sf/rollcalld$ time dd bs=128 count=128 if=/dev/random iflag=fullblock of=randump2 128+0 レコード入力 128+0 レコード出力 16384 バイト (16 kB) コピーされました、 946.389 秒、 0.0 kB/秒 real15m46.570s user0m0.008s sys0m0.120s -- Reading e-mail and posting to one of my blogs while I dumped /dev/random . 16 minutes for 16K, looks like 64K will be an hour and a half or so. 16K is enough for some initial analysis. Need to allocate some time for it. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNNJfKuumG5FG1ZNpFQA5=jpkj+svorrywtg3tpvod...@mail.gmail.com
Re: /dev/random
On Fri, 1 Aug 2014 16:34:50 +0100 Lisi Reisz lisi.re...@gmail.com wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! Lisi LOL -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140803110221.4800d...@mydesq2.domain.cxm
Re: /dev/random
On Fri, 1 Aug 2014 17:48:33 +0200 B lazyvi...@gmx.com wrote: On Fri, 1 Aug 2014 16:34:50 +0100 Lisi Reisz lisi.re...@gmail.com wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! This is a common deformation inducted by the web: people tend to reject what is more than 10 lines or without a very explicit title. Which is not very good for learning and comprehending things… Take your time and use a very old and well known cure as an every day mental hygiene: forget the web and use something made in paper called a book; you'll see, it will open your horizons and your mind ;) Yes, and start with The French Lieutenant's Woman. The entire first page is one paragraph, ornate with bullshituous adverbs and other fluffatudes. In the 1980's, long before what we call the web (http), I bought this book at Crown books, read the first page, and threw it in the garbage. Six bucks well spent: I learned how not to write. Megaparagraphs were all the rage in the 1800's, when housewives had nothing to do but keep house, businessmen had nothing to do but do their business, and farmers had nothing to do but farm. Long days? Of course. But when they were done, they were done, and could fully concentrate. Denizens of the 1800's weren't on call 24/7. They didn't need to work on five issues at once. They didn't need to wedge urgent calls to the bureaucracy while snarfing lunch and answering fifteen emails, keeping one ear open for texts. Workers at the local saloon didn't need to take orders from the radio in their right ear while taking money and giving change to the customer speaking into their left. If you want your writing to entertain folks from the 1800's, take a time machine back, and write ornate megaparagraphs. But if you want to be read by time-crunched citizens of the 21st century, make your point, get onto the next thing, and make sure it's obvious you've moved on. Or else, your writings generate the infamous tl;dnr. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140803111626.16324...@mydesq2.domain.cxm
Re: /dev/random
On Fri, 1 Aug 2014 17:49:02 +0100 Lisi Reisz lisi.re...@gmail.com wrote: On Friday 01 August 2014 17:02:45 B wrote: But you didn't say it in your rant… I didn't rant. Lisi It's twu, it's twu! Lisi wrote two short sentences that took up less than one line. No rant. Her point was very succinct, complete with a metaphor (let some air in). I'd like to go on, but the more I go on, the less succinct I get :-) SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140803112023.6fdde...@mydesq2.domain.cxm
Re: /dev/random
On Fri, 1 Aug 2014 12:15:22 -0700 Bob Holtzman hol...@cox.net wrote: On Fri, Aug 01, 2014 at 04:34:50PM +0100, Lisi Reisz wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! Thank God. I thought I'd finally lost it. Yeah, I read the first four lines (I think I break at 72 or something like that), saw four times that much still to go, and went on to the next post. SteveT Steve Litt* http://www.troubleshooters.com/ Troubleshooting Training * Human Performance -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140803112128.1d728...@mydesq2.domain.cxm
Re: /dev/random
Le jeudi 31 juillet 2014 à 16:41:01 -0700, pecon...@mesanetworks.net a écrit: not generated by the functioning of the computer, but from something like the keystroke times of a human asking for help on this list. It differs from /dev/urandom in that /dev/random blocks and does not give any bits if there have not been enough keystrokes since the last call to replenish the supply of entropy in its entropy store. In contrast, As far as I know, keystrokes aren't the only monitored data used to fill the entropy pool; HDD and network I/Os timestamps are also use, as they can be considered as chaotic. Maybe the kernel doc can help you to know all of entropy sources. I know this isn't really the question, but I think you must know that keystrokes aren't the only entropy sources. Regards. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: /dev/random
On Jo, 31 iul 14, 16:41:01, pecon...@mesanetworks.net wrote: Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? I'm wondering is this a event with which many Debianers are quite familiar, or is it more like something of a rare event that people know about, but most have never actually had it happen to them? Why do I ask?: Just wondering. The only times I've seen this was when generating my GPG keys. Besides e-mail signing and ssh I only have an encrypted file with passwords. Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: /dev/random
On Fri, Aug 1, 2014 at 4:00 PM, David Guyot david.gu...@europecamions-interactive.com wrote: Le jeudi 31 juillet 2014 à 16:41:01 -0700, pecon...@mesanetworks.net a écrit: not generated by the functioning of the computer, but from something like the keystroke times of a human asking for help on this list. It differs from /dev/urandom in that /dev/random blocks and does not give any bits if there have not been enough keystrokes since the last call to replenish the supply of entropy in its entropy store. In contrast, As far as I know, keystrokes aren't the only monitored data used to fill the entropy pool; HDD and network I/Os timestamps are also use, as they can be considered as chaotic. Maybe the kernel doc can help you to know all of entropy sources. I know this isn't really the question, but I think you must know that keystrokes aren't the only entropy sources. Yes, but, ... Most I/O devices are dependent on certain kinds of timing to function. For instance, if you try to use the timing between cache fills on your hard disk, and the system for some reason reads a large block of data on a non-fragmented file, things that were pretty random suddenly are not. And there is a difference between random and arbitrary. If we could access the bit jitter on the shift register behind the read heads, we would discover quite of bit of regularity in the apparently random rises and falls. Likewise, bearings are not perfectly smooth, and lubricant not perfectly distributed, but the variations are going to repeat themselves with some regularity. Ethernet chatter seems unpredictable, but packets tend to flow in cyclic bursts. Pretty much everything in our world has hidden cyclic behavior. Keyboard hits tend to be much more random, but, even there, a good typist gets a rhythm going as well. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43ioszn6nndbl57prcj0pl5wkpahaj7pya_buvegkcpx...@mail.gmail.com
Re: /dev/random
On Fri, Aug 1, 2014 at 8:41 AM, pecon...@mesanetworks.net wrote: As many of you know, /dev/random is a source of random bits that are suitable for use some uses in cryptographic analysis. [...] Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? When generating certificates with openssl, I often have to type a full paragraph or two to get the number of bits I need. I find myself typing things I memorized in high school or seminary or words to popular songs or advertisements. And if I get in too good a rhythm, I end up having to type more. So I stop and move the mouse pointer a bit, too, to break my rhythm and to introduce another hand-type input. The actual data can be tapped for entropy as well, but then you introduce possible security issues. And using the entropy in data can be pretty tricky, too. Otherwise, simple rotation cyphers would not be subject to frequency analysis. I'm wondering is this a event with which many Debianers are quite familiar, or is it more like something of a rare event that people know about, but most have never actually had it happen to them? Considering the variety of debian users we have, some will not really be conscious of the thing, some will be working with entropy issues every day. Why do I ask?: Just wondering. Heh. [...] -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caar43init6hz2m1kquv5dtexrv887si60jgg3h0mn7+b-hv...@mail.gmail.com
Re: /dev/random
Le vendredi 01 août 2014 à 20:36:29 +0900, Joel Rees a écrit: Yes, but, ... Most I/O devices are dependent on certain kinds of timing to function. For instance, if you try to use the timing between cache fills on your hard disk, and the system for some reason reads a large block of data on a non-fragmented file, things that were pretty random suddenly are not. And there is a difference between random and arbitrary. If we could access the bit jitter on the shift register behind the read heads, we would discover quite of bit of regularity in the apparently random rises and falls. Likewise, bearings are not perfectly smooth, and lubricant not perfectly distributed, but the variations are going to repeat themselves with some regularity. Ethernet chatter seems unpredictable, but packets tend to flow in cyclic bursts. Pretty much everything in our world has hidden cyclic behavior. Keyboard hits tend to be much more random, but, even there, a good typist gets a rhythm going as well. Indeed, the entropy pool isn't as chaotic as it seems, but, with a deterministic machine like a computer, true random numbers can only be retrieved by thermal noise in resistors or similar processes for which a computer isn't designed. Besides, even if /dev/random is only pseudo-random, guessing its output is hard enough to consider it as a true RNG for common operations because, to guess /dev/random output, you would have to know very precise machine parameters, as HDD lubricant distribution, the kind of data you can only gather by deeply probing the system, so deeply that using such a spied machine for RNG would be futile. In short, as partly chaotic is better than totally deterministic, /dev/random can be considered reliable for punctual or day-to-day activity, but it is also obvious that, if our activity needs truly random number generation or heavy stream of at least pseudo random numbers, a dedicated hardware using thermal noise, cosmic rays, nuclear fission or any over per se chaotic phenomenon is greatly recommended. Regards. -- David Guyot Administrateur système, réseau et télécommunications / Sysadmin Europe Camions Interactive / Stockway Moulin Collot F-88500 Ambacourt Tel: +33 (0)3 29 30 47 85 Fax : +33 (0)3 29 31 31 31 signature.asc Description: Digital signature
Re: /dev/random
On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201408011634.50327.lisi.re...@gmail.com
Re: /dev/random
On Fri, 1 Aug 2014 16:34:50 +0100 Lisi Reisz lisi.re...@gmail.com wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! This is a common deformation inducted by the web: people tend to reject what is more than 10 lines or without a very explicit title. Which is not very good for learning and comprehending things… Take your time and use a very old and well known cure as an every day mental hygiene: forget the web and use something made in paper called a book; you'll see, it will open your horizons and your mind ;) -- automobile if you were a car, you'd be a ferrari mélanie o that's so cute darling, thanks automobile your consumption is very high signature.asc Description: PGP signature
Re: /dev/random
On Friday 01 August 2014 16:48:33 B wrote: Take your time and use a very old and well known cure as an every day mental hygiene: forget the web and use something made in paper called a book; you'll see, it will open your horizons and your mind ;) I'm glad you live in a world where everyone has 20/20 vision and disability is unheard of. Some of us are not so lucky. It is 15 years since I was able to read a book. Try to learn a little tolerance some time. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201408011653.09062.lisi.re...@gmail.com
Re: /dev/random
On Fri, 1 Aug 2014 16:53:09 +0100 Lisi Reisz lisi.re...@gmail.com wrote: I'm glad you live in a world where everyone has 20/20 vision and disability is unheard of. Some of us are not so lucky. It is 15 years since I was able to read a book. But you didn't say it in your rant… Try to learn a little tolerance some time. As some of my best friend are completely blind, I don't think I'm that intolerant (you see ;-p) -- * Cécilia was unblocked Cécilia says : kikooo!!! * Cécilia was blocked signature.asc Description: PGP signature
Re: /dev/random
On Fri, Aug 01, 2014 at 01:50:44AM +0200, B wrote: On Thu, 31 Jul 2014 16:41:01 -0700 pecon...@mesanetworks.net wrote: whatever experience you want to share. use haveged, it feeds /dev/random with a reservoir. I'd like to chime in that I recently installed haveged myself and have seen a massive increase in available entropy. Haveged, as I understand it basically runs a fairly complex calculation (with lots of branches and things) in a loop. Because almost all CPUs these days are complex beasts, the time to perform the calculation varies with each loop (sometimes because of cache misses, or maybe a branch was optimized differently). Haveged monitors the differences in these times and populates a random pool based on it. This is then fed in to the kernel as another source of entropy. Haveged is amazingly useful on headless or virtual or appliance machines. -- Pazns: U don't know about the drawer method? Pazns: U take your schoolbag, empty it in a drawer, close it, hop! clean up done! Zeeln: Yeah but my drawers are all full… Pazns: U don't know about the trash method? signature.asc Description: Digital signature
Re: /dev/random
On Friday 01 August 2014 17:02:45 B wrote: But you didn't say it in your rant… I didn't rant. Lisi -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/201408011749.02024.lisi.re...@gmail.com
Re: /dev/random
On Fri, Aug 01, 2014 at 04:34:50PM +0100, Lisi Reisz wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! Thank God. I thought I'd finally lost it. -- Bob Holtzman Giant intergalactic brain-sucking hyperbacteria came to Earth to rape our women and create a race of mindless zombies. Look! It's working! signature.asc Description: Digital signature
Re: /dev/random
On Vi, 01 aug 14, 17:48:33, B wrote: On Fri, 1 Aug 2014 16:34:50 +0100 Lisi Reisz lisi.re...@gmail.com wrote: On Friday 01 August 2014 00:41:01 pecon...@mesanetworks.net wrote: Thanks for reading I found it unreadable. Please let some air in!! This is a common deformation inducted by the web: people tend to reject what is more than 10 lines or without a very explicit title. I think it would have helped a lot if the whole thing was split in paragraphs ;) Kind regards, Andrei -- http://wiki.debian.org/FAQsFromDebianUser Offtopic discussions among Debian users and developers: http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic http://nuvreauspam.ro/gpg-transition.txt signature.asc Description: Digital signature
Re: /dev/random
Hi, On 01/08/14 18:06, Darac Marjal wrote: On Fri, Aug 01, 2014 at 01:50:44AM +0200, B wrote: On Thu, 31 Jul 2014 16:41:01 -0700 pecon...@mesanetworks.net wrote: whatever experience you want to share. use haveged, it feeds /dev/random with a reservoir. I'd like to chime in that I recently installed haveged myself and have seen a massive increase in available entropy. Haveged, as I understand it basically runs a fairly complex calculation (with lots of branches and things) in a loop. Because almost all CPUs these days are complex beasts, the time to perform the calculation varies with each loop (sometimes because of cache misses, or maybe a branch was optimized differently). Haveged monitors the differences in these times and populates a random pool based on it. This is then fed in to the kernel as another source of entropy. Haveged is amazingly useful on headless or virtual or appliance machines. Unfortunately, it does not seem to work on OpenVZ boxes. Jerome -- Pazns: U don't know about the drawer method? Pazns: U take your schoolbag, empty it in a drawer, close it, hop! clean up done! Zeeln: Yeah but my drawers are all full… Pazns: U don't know about the trash method? -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53dbf96f.9010...@rezozer.net
Re: /dev/random
Okay, the following was old information. REALLY old information: On Fri, Aug 1, 2014 at 8:51 PM, Joel Rees joel.r...@gmail.com wrote: On Fri, Aug 1, 2014 at 8:41 AM, pecon...@mesanetworks.net wrote: As many of you know, /dev/random is a source of random bits that are suitable for use some uses in cryptographic analysis. [...] Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? When generating certificates with openssl, I often have to type a full make that had, as in about ten years or so ago. paragraph or two to get the number of bits I need. [...] The OS was probably Redhat or Fedora, and FreeBSD. Don't recall doing it with Debian, so my information was not even relevant to Paul's question. (Sorry, Paul.) Just made a dummy key and cert on wheezy, after having been booted up for about three hours. No typing or mouse movement was necessary, just took a second or two. I suppose I should power cycle and see what it's like with a fresh entropy pool. -- Joel Rees Be careful where you see conspiracy. Look first in your own heart. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAAr43iNNmUsXC7Ve71d4ZcNnUbZT4BC9DSPgbz=-tpu326e...@mail.gmail.com
Re: /dev/random
(For Lisi and Bob and others ;-/) On Fri, Aug 1, 2014 at 8:41 AM, pecon...@mesanetworks.net wrote: As many of you know, /dev/random is a source of random bits that are suitable for use in cryptographic analysis. Wikipedia, stackoverflow, and other places have useful entries on random numbers, randomness, and the problem of mechanically generating random numbers when the machines we build are cyclic (repetitive) in nature. pseudorandom and true random numbers are useful search terms. Also, man 3 rand and following up on the references in the man page on debian presents some useful background information. Way oversimplifying, while a random number between 0 and 32,000 seems a bit hard to guess to humans, a modern computer can count through the possibilities in something like a millisecond. And the random number algorithm for rand() generally uses a standard formula (for compatibility reasons) such that, once you know one random number it generates, you can predetermine the next with a fairly simple calculation. Random numbers are used in key places in our security systems, to help thwart attackers. Obviously, the random numbers used there should not be numbers returned from rand(). Various approaches have been taken to resolve the potential problems, and the size of the random number and the predictability of the calculation are always issues. 32 bits is still too quickly countable to be comfortable, and any static formula is inherently reproduceable. So we want some source of truly random numbers. The timing of events that occur within the system tends to hide cyclic behavior and synchronizations we don't expect. If the attacker can profile the hardware of a system, he can guess the timings too often for such things to be used alone. The software supporting /dev/random collects random time data from monitoring events that are not generated by the functioning of the computer, but from something like the keystroke times of a human asking for help on this list. Typing on the keyboard and moving the mouse are two things that are really out of sync with what's going on in the computer, especially at sub-millisecond timings. Floppy disks could be useful, with some care, but of course those are not generally available any more. USB drives, with no moving parts except electrons, are generally too regular to be of much use, although a USB insertion would provide a bit or two of real world randomness. Entropy here is a mathematical term for referring to this kind of real randomness, by the way. (Oversimplifications, again, but you have to start somewhere.) Mechanical hard disks and network devices also provide a bit of access to de-synchronized events, and can also be used with care to provide some of this entropy. (Emphasis on with care.) The HAVEGE algorithm and the haveged daemon attempt to use CPU and memory timings to provide more. The CPU by itself is, even with out-of-order execution, too predictable to be of use. But when you factor in cache hits and misses, the unpredictable nature of what the CPU has been working on before, in addition to variations between actual physical cache and how that interplays with the actual CPU doing the work, etc., can give useable entropy, according to the HAVEGE project description. Again, you need to run the resulting timings through some pseudorandomness massaging to make it actually useable. The HAVEGE approach has been criticized, particularly if haveged is allowed to replace all the other sources of entropy. /dev/random and /dev/urandom are two devices which modern Unix-like systems provide, which give programs (and users) access to the randomness of external events like keypresses and mouse motion, heavily massaged and filtered with pseudorandom techniques. (Without the pseudorandomness, those devices would give the attacker new ways to probe a computer.) It differs from /dev/urandom in that /dev/random blocks and does not give any bits if there have not been enough keystrokes since the last call to replenish the supply of entropy in its entropy store. In contrast, /dev/urandom gives the number of bits requested quickly, but with no guarantee as to the quality of their randomness. I'm thinking I should wonder which openssl defaults to using. Okay, the openssl site says /dev/urandom since way back, and /dev/random only if /dev/urandom is not avaiable. Hmm. Places where this distinction is discussed suggest that a user of /dev/random 'randomly' poke at the keys on his keyboard if he finds himself waiting for /dev/random to un-block and give the needed random bits. Some users of Debian are concerned about performing cryptographic analysis correctly and I wonder: Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? I'm wondering is this a event with which many Debianers are quite familiar, or is it more like
/dev/random
As many of you know, /dev/random is a source of random bits that are suitable for use in cryptographic analysis. The software supporting /dev/random collects random time data from monitoring events that are not generated by the functioning of the computer, but from something like the keystroke times of a human asking for help on this list. It differs from /dev/urandom in that /dev/random blocks and does not give any bits if there have not been enough keystrokes since the last call to replenish the supply of entropy in its entropy store. In contrast, /dev/urandom gives the number of bits requested quickly, but with no guarantee as to the quality of their randomness. Places where this distinction is discussed suggest that a user of /dev/random 'randomly' poke at the keys on his keyboard if he finds himself waiting for /dev/random to un-block and give the needed random bits. Some users of Debian are concerned about performing cryptographic analysis correctly and I wonder: Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? I'm wondering is this a event with which many Debianers are quite familiar, or is it more like something of a rare event that people know about, but most have never actually had it happen to them? Why do I ask?: Just wondering. Thanks for reading, and please reply with whatever experience you want to share. Best regards, -- Paul E Condon pecon...@mesanetworks.net -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20140731164101.192b2...@m0005298.ppops.net
Re: /dev/random
On Thu, 31 Jul 2014 16:41:01 -0700 pecon...@mesanetworks.net wrote: whatever experience you want to share. use haveged, it feeds /dev/random with a reservoir. -- Pazns: U don't know about the drawer method? Pazns: U take your schoolbag, empty it in a drawer, close it, hop! clean up done! Zeeln: Yeah but my drawers are all full… Pazns: U don't know about the trash method? signature.asc Description: PGP signature
Re: /dev/random
On 07/31/2014 04:41 PM, pecon...@mesanetworks.net wrote: Just how often do you have to poke at the keyboard? And when you do poke at it, about how many key presses do you make before you get the number of bits you requested? Whenever I do a fresh system build, I use /dev/random to generate a 32 byte LUKS key: # dd if=/dev/random of=/root/.luks-keyfile bs=1 count=32 32+0 records in 32+0 records out 32 bytes (32 B) copied, 36.2822 s, 0.0 kB/s If the machine has been recently booted, /dev/random blocks (note run time in final line of example, above). I typically run ping, CVS, or other network related commands in another terminal until /dev/random completes, believing that processor interrupts also feed the random number entropy pool (?). Typically a half dozen such commands are enough. I'm wondering is this a event with which many Debianers are quite familiar, or is it more like something of a rare event that people know about, but most have never actually had it happen to them? I encounter the above case several times each year. HTH, David -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/53db0914.9040...@holgerdanske.com
/dev/random vs /dev/urandom
Hi folks! I need create a block file, later use it like archive (with dm). What is better use? /dev/random or /dev/urandom? thanks! Pol -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517421c9.1040...@fuckaround.org
Re: /dev/random vs /dev/urandom
Pol Hallen: Hi folks! I need create a block file, later use it like archive (with dm). What is better use? /dev/random or /dev/urandom? Define better. /dev/random is cryptographically more secure. /dev/random is faster. J. -- I lust after strangers but only date people from the office. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: /dev/random vs /dev/urandom
Define better. better = secure (high level of security) :-) /dev/random is cryptographically more secure. do you mean /dev/urandom is [...]? /dev/random is faster. thanks! Pol -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51742a1f.3010...@fuckaround.org
Re: /dev/random vs /dev/urandom
Hello List, On 21/04/13 20:04, Pol Hallen wrote: Define better. better = secure (high level of security) :-) /dev/random is cryptographically more secure. do you mean /dev/urandom is [...]? /dev/random is faster. thanks! man 4 random Pol hth, Jerome -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51742e12.5030...@rezozer.net
Re: /dev/random vs /dev/urandom
Pol Hallen a écrit : Define better. better = secure (high level of security) :-) /dev/random is cryptographically more secure. do you mean /dev/urandom is [...]? Not here. /dev/random is faster. But here. /dev/random is more random. /dev/urandom is faster. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/51742bdd.40...@plouf.fr.eu.org
Re: /dev/random vs /dev/urandom
Hi folks! I need create a block file, later use it like archive (with dm). What is better use? /dev/random or /dev/urandom? thanks! Pol You might want to install haveged. You can use that directly without affecting your system entropy. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/517421c9.1040...@fuckaround.org -- ___ 'Write programs that do one thing and do it well. Write programs to work together. Write programs to handle text streams, because that is a universal interface' (Doug McIlroy) ___ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20130421205142.41dfa...@kc-sys.chadwicks.me.uk
Re: /dev/random vs /dev/urandom
Pascal Hambourg: Pol Hallen a écrit : /dev/random is cryptographically more secure. do you mean /dev/urandom is [...]? Not here. /dev/random is faster. But here. /dev/random is more random. /dev/urandom is faster. Exactly, thanks. My 'u' key gets stck sometimes. :) J. -- I have never been happier than I am now; a fact which depresses me immensely. [Agree] [Disagree] http://www.slowlydownward.com/NODATA/data_enter2.html signature.asc Description: Digital signature
Re: use another /dev/tty0 as /dev/random
worked it out, i neeed the app rng-tools and set my device as /dev/foo :) About.me http://about.me/dick.thomas Blog: www.xpd259.co.uk G+: www.google.com/profiles/xpd259 gpg key: C791809B On 22 February 2013 17:05, Dick Thomas xpd...@gmail.com wrote: I'm making a random number generator out of bit and Arduino but that isn't the question my Question is is it possible to use a serial imput from the Arduino as /dev/random I've no idea what to even google to do this any help or pointers where to start would be fantastic Dick About.me http://about.me/dick.thomas Blog: www.xpd259.co.uk G+: www.google.com/profiles/xpd259 gpg key: C791809B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGe0=N2MtdgrwnN9z+vtxUa0BE1Ld5LX=8xm9n+zd_qrsvo...@mail.gmail.com
use another /dev/tty0 as /dev/random
I'm making a random number generator out of bit and Arduino but that isn't the question my Question is is it possible to use a serial imput from the Arduino as /dev/random I've no idea what to even google to do this any help or pointers where to start would be fantastic Dick About.me http://about.me/dick.thomas Blog: www.xpd259.co.uk G+: www.google.com/profiles/xpd259 gpg key: C791809B -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/CAGe0=N2UfeUHghpX2nsE5r2z1FTLTxNtu+6hnwCcZT2QSW+=i...@mail.gmail.com
/dev/random rate
I am trying to generate an SSL key using OpenSSL and /dev/random . However, it looks that the entropy generation rate is very low. Everything works in less than a second if I use /dev/urandom, but with /dev/random I can strace the process and see it reading about 8 bytes per second (even though I generate as much noise as I can (mouse+keyboard+network)). read(4, \332\242_\26\360\3140e..., 190) = 8 read(4, \256\212\263-~\245n\37..., 182) = 8 read(4, \33a\f\...@\327\274d..., 174) = 8 read(4, \364\325\327D\261\r\346\233..., 166) = 8 read(4, \237\327}r3\24S\334..., 158) = 8 read(4, q\204\237\252\261\2515,..., 150) = 8 read(4, W\320A\331`8\201\252..., 142) = 8 read(4, o\257\314\363\270B\206\331..., 134) = 8 Any ideas? You can try this: strace openssl genrsa -out test.random -rand /dev/random 1024 on your system and tell me what you see. :-) STF http://eisenbits.homelinux.net/~stf/ OpenPGP: DFD9 0146 3794 9CF6 17EA D63F DBF5 8AA8 3B31 FE8A -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/random rate
On Thu Jan 14, 2010 at 01:43:39 +0100, Stanis??aw T. Findeisen wrote: I am trying to generate an SSL key using OpenSSL and /dev/random . However, it looks that the entropy generation rate is very low. .. Any ideas? You can try this: You can see the amount of available entropy via: s...@gold:~$ cat /proc/sys/kernel/random/entropy_avail 1902 s...@gold:~$ I would guess that you have little available before, during, and after the generation. YOu could try to fix this via one of the sources. (e.g. big network traffic / the addition of rng-tools or similar.) Steve -- Debian GNU/Linux System Administration http://www.debian-administration.org/ -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: /dev/random vide !?
On 30 May 2003 18:53:15 +0200 Philippe Amelant [EMAIL PROTECTED] wrote: Bonjour, Je viens d'installer cyrus-imap sur un serveur. Tout à l'air OK sauf le serveur POP3... bizarre ... je cherche un peu, le met en debug, et là on voit qu'il bloque pour lire un fichier. Je cherche un peu sur la ML de cyrus et là je vois quelqu'un avec le même problème, auquel on lui à répondu qu'il manquait d'entropie. je vérifie et effectivement mon /dev/random et vide, et ne se rempli jamais ! En cherchant un peu plus, j'ai trouvé que /dev/random devrait ce remplir à plus de 10 octet/s sur une machine idle, alors que moi c'est 0 à l'heure !! cat /dev/random n'affiche rien ? Est ce que quelqu'un à déjà eut ce genre de problème ou sait comment le résoudre ? As tu activé le support du générateur matériel de nombres aléatoires dans le noyau ? Section Char devices (ça vient peut-etre de là) Je precise que c'est un noyau 2.4.18 sur une woody
/dev/random vide !?
Bonjour, Je viens d'installer cyrus-imap sur un serveur. Tout à l'air OK sauf le serveur POP3... bizarre ... je cherche un peu, le met en debug, et là on voit qu'il bloque pour lire un fichier. Je cherche un peu sur la ML de cyrus et là je vois quelqu'un avec le même problème, auquel on lui à répondu qu'il manquait d'entropie. je vérifie et effectivement mon /dev/random et vide, et ne se rempli jamais ! En cherchant un peu plus, j'ai trouvé que /dev/random devrait ce remplir à plus de 10 octet/s sur une machine idle, alors que moi c'est 0 à l'heure !! Est ce que quelqu'un à déjà eut ce genre de problème ou sait comment le résoudre ? Je precise que c'est un noyau 2.4.18 sur une woody Merci -- Philippe Amelant [EMAIL PROTECTED]
