> No, don't bother with a simple linear congruential generator --- those
> are trivial to break, and most of the places where you need strong
> random numbers, a linear congruential generator simply won't cut it.
>
> That's why I've resisted strenuously any suggestion that /dev/random
> might be replaced by a psuedo-random number generator --- that will
> only give people a false sense of security, while network cracker cackle
> with glee over how easy it is to break into Linux boxes....
HI there!
Some words related to the topic of security and /dev/random:
Let's assume now that all the security related programs are using it.
And now You are an internet provider selling Linux boxes used as internet
servers. (They are allready quite a lot of them out there,
doing *exactly* this.)
HERE IS AN IDEA HOW TO GET RICH VERY EASY:
1. Grab the kernel sources.
2. Fake random.c, so that it is using an deterministic algorithm for
generation of random numbers, which is *very well* know by You, instead
of the strong random number generater.
3. Sell it as often as You can.
4. Wait until the customers are starting to use it for financial
transactions.
5. Open an money account at a swiss bank. Buy a ticket to the southern
sea.
7. Get all the credit card numbers...
8. ............
9. Have a nice day, nice live, the fastest CPU money can buy, 512 Megs of
static 1ns RAM. 100 emacs sessions on one engine. The fastest
connection to the net. (In this case through a satellite for
obvious reasons.)
Now imagine You are the software developement cheef officer at, let's say for
example FusyNet(R), who is planing the developement of the new killer app:
AutoMoneyTransfer(TM).
This is the year 2000.
You are *determined* to support Linux in any case, since it got in the meantime
a quite big part of the market (dream dream ...). You need some way to get
strong random numbers wich can't be guessed easly by anybody. Oh quite fast
done: There is allready the famous /dev/random there!!!
And now You are thinking about the possibility of the scenario described
just above... You spend a night at thinking about it. Finally the decision
will surely be:
DO ANYTHING TO GET GOOD RANDOM NUMBERS, BUT DON'T USE /dev/random.
And now back to 1996.
You are the student of pure mathematics with some interrest in cryptography
and Montecarlo methods for numerical solving of integral equations. This isn't
Your's specialisation. You only intend to implement the algorithm XYZ which is
relaying on good random numbers, seen yerstoday as an example in some book;
just to see how it works. You write a wizardly optimized,
blanzingly fast implementation. You need *every* micro MIPS of Your's
over tuned 90MHz Pentium PC to get the results in reasonably time.
(It was in fact something similiar I did.)
YOU USE: /dev/random.
You start the program. Now You are waiting waiting waiting waiting... No
body touches the keyboard or mouse. You are waiting waiting waiting... The
paging stops. The programm fits compleatly into the core memmory (16MB). You
are waiting waiting and waiting... You didn't consider /dev/urandom an
alternative, since it would be no problem to do mostly the same in user land
in case the /dev/random falls back very fast into pseudo random number mode.
You are waiting and waiting until now...
And now just think about cryptography and reproductibility of results!!!
Those (and similiar arguments) are the reasons, while the /dev/random isn't
usefull for real world apps.
q.e.d. (Proof by contradiction.)
And this is the reason, why I think that noone of the other UNIX
developers will never implement something similiar. Nothing to say about it
getting POSIX standard. No it will never. Surely. I will put my hand into
fire...
And now we are in the year 2005. Linus is thinking about the release of Linux
3.0 to the pulic as the new offical release. The kernel is by about 1.5Meg in
size now. He is thinking about how to make it somehow smaller to fit on an
ordinary 3.5inch disk drive (which are still in common use). He looks through
the code and there it comes *along*:
random.c:
banach:/usr/src/linux/drivers/char# size random.o
text data bss dec hex filename
40133 504 2000 40137 Ab21 random.o
(remember we are on an 64bit 80986 with a compleatly new VLSIW additional op.
code set by now!!)
And he is wondering why it is still only used in the BOOTP code.
And there it's inessential and overkill like nothing.
BINGO!!!! just remove it and fix BOOTP to use something more appriopriate.
Or at least he adds an option to the kernel config, to give freedom to the
people who don't like the kernel becoming slowly shaped like a big fat pig by
some baroque features.
The kernel fits again on the 3.5inch disk and the world is saved...
Marcin
ps. I really didn't intend to offend anybody. This wasn't a statement about
the code quality of random.c. But it was a statement about the usefullness
of it. The arguments presented above are quite lazy formulated but they are
serious.