Re: a small C program to test xdm's /dev/mem reading on your architecture
In article [EMAIL PROTECTED] [EMAIL PROTECTED] write: [XDM randomness] /dev/random? /dev/urandom? You are kidding. This randmomness is used to create authorisation cookies for X which in my understanding provide ZERO security. Use plain libc rand() and the security is exactly the same. In the situation where the X session is in practice running over unix sockets (or other configurations where all the data stays local to the machine without being vulnerable to network (or other) sniffing attacks)[1], the cookies in question provide the security that they were designed for - namely requiring a significant proportion of the space available to said cookies to be trawled to be able to send authenticated requests to the X server.[2] Jonathan. [1] Although, said server may be listening for tcpip connections, or those of other protocols to which the attacker can send their requests. [2] Having looked at the code, it is not obvious to me that the entropy produced in said cookies doesn't have a maximum of 32 bits, even if the cookie is longer than that.
Re: a small C program to test xdm's /dev/mem reading on your architecture
[Apologies to readers of debian-sparc, who have already received a copy of this] In article [EMAIL PROTECTED] [EMAIL PROTECTED] write: [XDM randomness] /dev/random? /dev/urandom? You are kidding. This randmomness is used to create authorisation cookies for X which in my understanding provide ZERO security. Use plain libc rand() and the security is exactly the same. In the situation where the X session is in practice running over unix sockets (or other configurations where all the data stays local to the machine without being vulnerable to network (or other) sniffing attacks)[1], the cookies in question provide the security that they were designed for - namely requiring a significant proportion of the space available to said cookies to be trawled to be able to send authenticated requests to the X server.[2] Jonathan. [1] Although, said server may be listening for tcpip connections, or those of other protocols to which the attacker can send their requests. [2] Having looked at the code, it is not obvious to me that the entropy produced in said cookies doesn't have a maximum of 32 bits, even if the cookie is longer than that.
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article [EMAIL PROTECTED] Kusti writes: I believe the /dev/mem gets read only in systems where no /dev/(u)random exists. Actually, the standard configuration is that /dev/mem is read. The code to read from /dev/(u)random isn't activated in any situation in the standard upstream X distribution, and given that it contains an error that stops it from compiling[1] I suspect that it has only ever rarely been used. Obviously the correct thing to do is to shift to using /dev/(u)random by default. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
In article [EMAIL PROTECTED] Branden writes: I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? I suspect that /dev/urandom may be the better choice, however. Jonathan.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Fri, 30 Aug 2002, Jonathan Amery wrote: Date: Fri, 30 Aug 2002 13:58:43 +0100 From: Jonathan Amery [EMAIL PROTECTED] To: [EMAIL PROTECTED], debian-x@lists.debian.org Subject: Re: a small C program to test xdm's /dev/mem reading on your architecture In article [EMAIL PROTECTED] Branden writes: I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. And Debian Hurd? Or does the Hurd not have /dev/random or /dev/urandom? I suspect that /dev/urandom may be the better choice, however. /dev/urandom makes more sense. /dev/random will block too easily. -- Mike A. Harris Shipping/mailing address: OS Systems Engineer 190 Pittsburgh Ave., Sault Ste. Marie, XFree86 maintainer Ontario, Canada, P6C 5B3 Red Hat Inc. http://www.redhat.com ftp://people.redhat.com/mharris
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hello ! This programm works on 20164 (LX) running Debian/GNU Linux (Woody) 20164 (dual) running Digital Unix (using Compaq C-Compiler) 20264 (XP1000) running Linux Greetings Helge -- Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferredgpg-key: finger [EMAIL PROTECTED] 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software libre: http://www.freepatents.org/ pgpDIEfIoaElF.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
Marcus Brinkmann [EMAIL PROTECTED] writes: You are mistaken. Do yourself a favour and get a book about (pseudo) random number generators, entropy, hash functions and cryptography. If you don't start with random numbers, you can turn the numbers upside down, it won't get any more random than what you started with. There's also a nice comment at the top of drivers/char/random.c that (I assume) Ted Ts'o wrote. It's a nice, succinct explanation of many things regarding linux randomness and randomness in general. --
a small C program to test xdm's /dev/mem reading on your architecture
The long story, for those interested:
http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html
(and read the whole thread)
The short story:
I need people with root on machines of your given architecture to
compile and run the attached C program. It consists of code borrowed
from xdm's genauth.c program.
The X Strike Force is trying to determine for which architectures it's a
bad idea to read several megabytes of data sequentially from /dev/mem,
because this is exactly what XDM currently does when generating an
XDM-AUTHORIZATION-1 cookie.
Be warned: on at least some architectures (notably IA-64), this sort of
read has been known to cause untrapped machine checks (a.k.a., lockups
or spontaneous reboots). Arguably the kernel should trap this sort of
nonsense, so you may be in the mood to file a bug against kernel after
running this program.
I and the other folks at the X Strike Force need to know the following
things:
1) whether or not this program works when you run it without arguments
2) if scenario 1) causes problems, what the last line of output was
3) if scenario 1) causes problems, whether invoking this program with
the argument fragile helps it
4) if scenario 3) causes problems, what the last line of output was
Remember, this program must be run as root. If normal users can read
from /dev/mem on your machine, you're in trouble. :)
--
G. Branden Robinson| No math genius, eh? Then perhaps
Debian GNU/Linux | you could explain to me where you
[EMAIL PROTECTED] | got these... PENROSE TILES!
http://people.debian.org/~branden/ | -- Stephen R. Notley
#include errno.h
#include fcntl.h
#include stdio.h
#include string.h
#include sys/types.h
#include sys/stat.h
#include unistd.h
#define FILE_LIMIT 1024
static int
sumFile (char *name, long sum[2], int dofragile)
{
longbuf[1024*2];
int cnt;
int fd;
int loops;
int reads;
int i;
int ret_status = 0;
fd = open (name, O_RDONLY);
if (fd 0) {
fprintf(stderr, Cannot open randomFile \%s\ (%s)\n, name, strerror(errno));
return 0;
}
if (dofragile) {
if (strcmp(name, /dev/mem) == 0) lseek (fd, (off_t) 0x10, SEEK_SET);
}
reads = FILE_LIMIT;
sum[0] = 0;
sum[1] = 0;
while ((cnt = read (fd, (char *) buf, sizeof (buf))) 0 --reads 0) {
printf(read #%d of %d bytes \n, (FILE_LIMIT - reads + 1), sizeof (buf));
loops = cnt / (2 * sizeof (long));
for (i = 0; i loops; i+= 2) {
sum[0] += buf[i];
sum[1] += buf[i+1];
ret_status = 1;
}
}
if (cnt 0)
fprintf(stderr, Cannot read randomFile \%s\ (%s)\n, name, strerror(errno));
close (fd);
return ret_status;
}
int main(int argc, char *argv[])
{
int status;
int dofragile = 0;
long checksum[2];
char *filename = /dev/mem;
if (argv[1] != NULL (strncmp(argv[1], fragile, 7) == 0)) {
dofragile = 1;
}
printf(Reading data from %s%s...\n, (dofragile ? (fragile) : ), filename);
status = sumFile(filename, checksum, dofragile);
printf(done with read of %s%s (returned %d).\n, (dofragile ? (fragile) : ), filename, status);
printf(sumFile() %s.\n, (status ? succeeded : failed ));
exit(0);
}
pgp1AslsoG9Qu.pgp
Description: PGP signature
re: a small C program to test xdm's /dev/mem reading on your architecture
Be warned: on at least some architectures (notably IA-64), this sort of read has been known to cause untrapped machine checks (a.k.a., lockups or spontaneous reboots). Arguably the kernel should trap this sort of nonsense, so you may be in the mood to file a bug against kernel after running this program. wow, this is such a bad idea. the kernel *can't* trap that sort of thing in a lot of cases. simply the hardware goes catatonic. this is true of ultrasparc machines as well. you may also access some random device memory causing it do do something unexpected. read can be very destructive of device state... why don't you use /dev/urandom if it exists, as it does on pretty much all modern UNIX platforms? *shudder* .mrg.
re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 04:28:38PM +1000, matthew green wrote: wow, this is such a bad idea. It originated upstream. mmm, xdm. In fact, judging by CVS logs it has been in xdm's source for many, many years. bad ideas often hang around for a long time. the only surprising thing to me is how long this one has taken to surface... why don't you use /dev/urandom if it exists, as it does on pretty much all modern UNIX platforms? *shudder* I see you haven't read the thread. actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). my point is that on modern systems we simply should not read from /dev/mem for these purposes _ever_. so far it has shown to be unsafe on at least: - ia64 - arm - mips - ultrasparc i'm sure there are more... i don't see the purpose in running the program you posted - we shouldn't care whether it works, just don't do it. i'm going to patch NetBSD xsrc shortly to fix this if it isn't already... .mrg.
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hello ! I'll run it later on different alphas, but I checked it on a ppc-machine running AIX if this is of any interest to you: [EMAIL PROTECTED]: /root # ./readmem.aix.x Reading data from /dev/mem... read #2 of 8192 bytes ... read #1024 of 8192 bytes done with read of /dev/mem (returned 1). sumFile() succeeded. There are 1023 lines starting with read (starting with number 2). Greetings Helge -- Helge Kreutzmann, Dipl.-Phys. [EMAIL PROTECTED] gpg signed mail preferredgpg-key: finger [EMAIL PROTECTED] 64bit GNU powered http://www.itp.uni-hannover.de/~kreutzm Help keep free software libre: http://www.freepatents.org/ pgpNHP54rOldi.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
Hi, On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: why don't you use /dev/urandom if it exists, as it does on pretty much all modern UNIX platforms? I see you haven't read the thread. actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). If any of these it should be /dev/random. /dev/urandom would stall most of the time on headless systems, which is the only place where I (and very likely a lot of other people too) run xdm in the first place. Regards, Filip -- netgod shorty: its not exactly intuitive, since women dont follow boolean logic netgod or any logic known to man, for that matter
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, 26 Aug 2002 17:04:26 +1000 matthew green [EMAIL PROTECTED] wrote: actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). my point is that on modern systems we simply should not read from /dev/mem for these purposes _ever_. so far it has shown to be unsafe on at least: I believe the /dev/mem gets read only in systems where no /dev/(u)random exists. There really are such systems. Agreed, reading raw memory is an unstable and dangerous way of getting enthropy, but xdm needs some way of getting it. If I understood the thread correctly, the preferred way indeed is the /dev/(u)random way. Still, the unlucky ones with no /dev/(u)random should not be forgotten. I think the safe way of getting random data without a decent random source would be to write one. This, however, would be more that just a small patch. A simple random number generator doesn't do, since it's all too predictable. One approach could be using two separate threads to read the same rnd-generator, so the system's scheduler would make the resulting data sequence unpredictable. However, I believe this is not very portable approach either: it is only possible, if threads are. And even if the system supports mt-programming, how can we be sure that the thread switching happens unpredictably? So, a better solution is needed. Probably one even exists. Just my 2 cents, Kusti
RE: a small C program to test xdm's /dev/mem reading on your architecture
Filip Van Raemdonck [EMAIL PROTECTED] wrote: On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). If any of these it should be /dev/random. /dev/urandom would stall most of the time on headless systems, which is the only place where I (and very likely a lot of other people too) run xdm in the first place. You're mistaken here: /dev/random blocks, /dev/urandom doesn't. Julian.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 05:04:26PM +1000, matthew green wrote: actually, i hadn't, but there wasn't very much there besides the fact that people found it was xdm reading /dev/mem and a small patch for debian to enable /dev/random (i'd suggest /dev/urandom). If any of these it should be /dev/random. /dev/urandom would stall most of the time on headless systems, which is the only place where I (and very likely a lot of other people too) run xdm in the first place. No, it's random that stalls if the entropy pool is not full. // Thomas
Re: a small C program to test xdm's /dev/mem reading on your architecture
Previously Kimmo K. I. Surakka wrote: I think the safe way of getting random data without a decent random source would be to write one. This, however, would be more that just a small patch. There is existing code to generate randomness from userland, look at what current OpenSSH does for example. Wichert. -- _ /[EMAIL PROTECTED] This space intentionally left occupied \ | [EMAIL PROTECTED]http://www.wiggy.net/ | | 1024D/2FA3BC2D 576E 100B 518D 2F16 36B0 2805 3CB8 9250 2FA3 BC2D |
Re: a small C program to test xdm's /dev/mem reading on your architecture
matthew green [EMAIL PROTECTED] writes: my point is that on modern systems we simply should not read from /dev/mem for these purposes _ever_. It would make some sense to read all the physical memory in the machine. Unfortunately, I'm not aware of any reasonably way to do that. Reading /dev/mem does something quite different. I was about to put /dev/mem reading into my own seed-generation program a while back, but then [EMAIL PROTECTED] explained to me that it was a really bad idea. A safer thing to do is to read the raw partitions on which /var, /tmp and perhaps also swap lives, but I gave up that plan after I read the GNU df source code looking for a way to get to a device, given a directory (such as /var) in the filesystem. But programs such as xdm should not do things like that, regular generation of cookies etc should use some decent randomness generator provided with the operating system, be that /dev/urandom or prngd or whatever. /Niels
Re: a small C program to test xdm's /dev/mem reading on your architecture
Branden, The long story, for those interested: http://lists.debian.org/debian-x/2002/debian-x-200208/msg00091.html (and read the whole thread) The short story: I need people with root on machines of your given architecture to compile and run the attached C program. It consists of code borrowed from xdm's genauth.c program. Done. I've submitted the output for HPPA boxes running 32 and 64-bit kernels. Looks like they pass without any problem. I'll pass on the test results for an older 715/50 box (the other boxes were an A500 and C3K). Secondly, I will open a big can a whoopass on anyone else I see complaining about /dev/mem reading without providng a patch :) Branden is merely asking you to _test_ something. c.
Re: a small C program to test xdm's /dev/mem reading on your architecture
matthew green wrote: bad ideas often hang around for a long time. the only surprising thing to me is how long this one has taken to surface... Perhaps Branden is gathering information about what a bad idea this really is, to show upstream the error of their ways. I can't believe he actually intends to keep it like this.. FWIW, the program doesn't crash my old 486, which is a bit suprising, I know that this kind of thing is capable of crashing ISA systems. -- see shy jo
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:06:00AM -0400, Carlos O'Donell wrote: Done. I've submitted the output for HPPA boxes running 32 and 64-bit kernels. Looks like they pass without any problem. I'll pass on the yes, but it may well crash them. some parts of /dev/mem map random IO addresses which may not take kindly to being read in an unprovoked manner. -- Revolutions do not require corporate support.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 10:23:06AM -0400, Joey Hess wrote: matthew green wrote: bad ideas often hang around for a long time. the only surprising thing to me is how long this one has taken to surface... Perhaps Branden is gathering information about what a bad idea this really is, to show upstream the error of their ways. Well, I hadn't reached that conclusion a priori. I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. -- G. Branden Robinson|You should try building some of the Debian GNU/Linux |stuff in main that is [EMAIL PROTECTED] |modern...turning on -Wall is like http://people.debian.org/~branden/ |turning on the pain. -- James Troup pgplHz4js2jgu.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. That's bad, because that will drain the entropy a lot, and it might block for a long time, and that for no good reason as I don't think the magic cookie needs strong cryptographical security (for comparison: The secret key of a public key cryptography key pair should be created using /dev/random, while for session keys /dev/urandom is good enough). Also, reading /dev/mem doesn't sound very secure at all (even if it works) because the patterns in the memory of a computer are probably predictable and a lot of information can be observed from the outside (which processes are running etc). Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: Also, reading /dev/mem doesn't sound very secure at all (even if it works) because the patterns in the memory of a computer are probably predictable and a lot of information can be observed from the outside (which processes are running etc). why do you assume that xdm uses the raw result from /dev/mem? running, say, md5 over the results would give you something as close to random as i doubt you could find a difference. -- Revolutions do not require corporate support.
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 08:16:06PM +0100, Matthew Wilcox wrote: On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: Also, reading /dev/mem doesn't sound very secure at all (even if it works) because the patterns in the memory of a computer are probably predictable and a lot of information can be observed from the outside (which processes are running etc). why do you assume that xdm uses the raw result from /dev/mem? I don't. That would be obviously too foolish. It would also not make sense by Branden's original mail which clearly stated that xdm can read several megabytes from /dev/mem. I assume they do this because they know that /dev/mem doesn't contain much entropy, and as such they try to get enough randomness squeezed out of it by reading more and more of it. This is a dubious approach. running, say, md5 over the results would give you something as close to random as i doubt you could find a difference. You are mistaken. Do yourself a favour and get a book about (pseudo) random number generators, entropy, hash functions and cryptography. If you don't start with random numbers, you can turn the numbers upside down, it won't get any more random than what you started with. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
Marcus Brinkmann writes:
On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote:
I can't believe he actually intends to keep it like this..
I'm going to #define DEV_RANDOM /dev/random for Linux systems.
That's bad, because that will drain the entropy a lot, and it might
block for a long time, and that for no good reason as I don't think the
magic cookie needs strong cryptographical security (for comparison: The
secret key of a public key cryptography key pair should be created using
/dev/random, while for session keys /dev/urandom is good enough).
Here is how I create the magic cookie in my ~/.xserverrc shell script,
cookie ()
{
dd if=/dev/urandom 2/dev/null bs=16 count=1 | od -x | awk ' NR==1 {
print $2 $3 $4 $5 $6 $7 $8 $9 } '
}
e.g.,
$ cookie
a0de8e57919780bbc5ff16e66e1af2a9
and I use it in .xserverrc like this,
mcookie=`cookie`
# Add this cookie to the X server auth file.
xauth -f ${auth} \
-v add 0.0.0.0:${xdpnum} ${access} ${mcookie}
# Add necessary new display entries to .Xauthority file.
xauth -v add ${eth0}:${xdpnum} ${access} ${mcookie}
xauth -v add ${host}:${xdpnum} ${access} ${mcookie}
xauth -v add ${host}/unix:${xdpnum} ${access} ${mcookie}
Why does anyone need to read megabytes of urandom? If it really
is random, then 16 bytes should be enough.
--
Jeff Sheinberg
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. That's bad, because that will drain the entropy a lot, xdm doesn't read the same amount of data when it's reading from a (presumably) entropic device node. It reads eight size_t's. Surely that is not excessive. Please read the thread. -- G. Branden Robinson| Measure with micrometer, Debian GNU/Linux | mark with chalk, [EMAIL PROTECTED] | cut with axe, http://people.debian.org/~branden/ | hope like hell. pgpXes5PcCmwz.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote: Why does anyone need to read megabytes of urandom? Nobody does. Or, at least, xdm doesn't. Markus is opining without the benefit of having checked the facts. -- G. Branden Robinson| What influenced me to atheism was Debian GNU/Linux | reading the Bible cover to cover. [EMAIL PROTECTED] | Twice. http://people.debian.org/~branden/ | -- J. Michael Straczynski pgpflELhmC3Qe.pgp Description: PGP signature
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 02:43:09PM -0500, Branden Robinson wrote: xdm doesn't read the same amount of data when it's reading from a (presumably) entropic device node. I didn't assume that. It reads eight size_t's. Surely that is not excessive. It's eight size_t's good entropy wasted for no important use still. In some environments, good entropy is really hard to get at. Thanks, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 02:44:26PM -0500, Branden Robinson wrote: On Mon, Aug 26, 2002 at 03:28:18PM -0400, Jeff Sheinberg wrote: Why does anyone need to read megabytes of urandom? Nobody does. Or, at least, xdm doesn't. Markus is opining without the benefit of having checked the facts. Uh, I never, ever said that xdm would read megabytes from any /dev/ but /dev/mem. Some people have too much phantasies. Thanks, Brandon, Marcus -- `Rhubarb is no Egyptian god.' GNU http://www.gnu.org[EMAIL PROTECTED] Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/ [EMAIL PROTECTED] http://www.marcus-brinkmann.de/
Re: a small C program to test xdm's /dev/mem reading on your architecture
On Mon, Aug 26, 2002 at 09:10:54PM +0200, Marcus Brinkmann wrote: On Mon, Aug 26, 2002 at 12:50:22PM -0500, Branden Robinson wrote: I can't believe he actually intends to keep it like this.. I'm going to #define DEV_RANDOM /dev/random for Linux systems. That's bad, because that will drain the entropy a lot, and it might block for a long time, and that for no good reason as I don't think the magic cookie needs strong cryptographical security (for comparison: The secret key of a public key cryptography key pair should be created using /dev/random, while for session keys /dev/urandom is good enough). /dev/random? /dev/urandom? You are kidding. This randmomness is used to create authorisation cookies for X which in my understanding provide ZERO security. Use plain libc rand() and the security is exactly the same. Richard
