lkml.org 
[lkml]   [1996]   [May]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: CONFIG_RANDOM option for 1.99.2
Date
In article <199605241108.NAA10621@wildsau.idv.uni-linz.ac.at> Herbert Rosmanith <herp@wildsau.idv.uni-linz.ac.at> writes:

> a rendom generator placed in the kernel is a thematical error.
> i always thought that an OS is an abstracion of the hardware.
> please put random generators to where they belong to: to the
> application level. put it into some static library.
>
> what's coming next anyway ? /dev/gaussian-distribution ?

Your example gives you away. You think /dev/random is a fancy method
to get random numbers like the ones we have all seen in college, in
Knuth, etc. for statistics and simulation.

It is not so. They're different animals.

It is extremely difficult to generate cryptographically strong random
numbers in software. It is close to impossible. Let me rephrase it:
It is close to impossible, so it must be done using the best available
methods.

Moreover, in an operating system like Linux (or nearly every Unix-like
system and most operating systems excepting kernels for embedded
real-time systems and such), it is probably hopeless because all
randomness sources will be smoothed by the kernel scheduling policy or
network implementation (that's one reason why you should not seed PGP
over a telnet session or an xterm and, even so, it's better to do it
on DOS). Further, you don't want to start a program to generate
entropy when it is needed. You need to collect it in advance and in a
way that no other user can peek at.

Believe me, there is no other place for this than the kernel. It has
to be there, because there is no better place for it. Doing it in
user space means losing randomness. The current techniques in user
space (the Netscape servers, PGP, etc.) are just poor substitutes for
the real thing. Compromising on this means weaker random numbers for
cryptography. And experience shows that you don't mess with that.

Think about this: without /dev/random, DOS will be a better platform
than Linux for cryptography. Got it? A DOS program can mess with all
sorts of details in the system that a userland program in Linux ever
gets to see. On Unix, /dev/random is *the* tool.

And cryptography is not an esoteric technique. You will be using a
lot of it before you even notice.

To sum up, Ted is right, /dev/random is good, /dev/random is right,
/dev/random must stay.

I will welcome any scheme that allows software producers to count on
its presence and yet avoids reserving those 16k for users that will
never need it. But if no compromise is possible, let's keep it in.
Maybe #ifdef'ed with something not configurable thorough make config
so that disabling it takes some effort and not just some clueless
newbie answering N to a question that does not understand or clicking
on random (no pun intended) parts of the make xconfig windows.

All the best,

Julio

--
Julio Sanchez, SGI Soluciones Globales Internet
Tel: (91) 804 28 37 Fax: (91) 804 14 05 WWW: http://www.esegi.es
jsanchez@esegi.es jsanchez@gmv.es
PGP Key fingerprint = E5 29 93 6F 41 4E 00 E2 90 11 A1 8C 72 D0 DE 71


\
 
 \ /
  Last update: 2005-03-22 13:37    [W:0.092 / U:0.172 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site