> On Wed, 15 May 1996, Theodore Y. Ts'o wrote:
> 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:
>
> [cute idea dependent on Linux ruling the world omitted due to size]
>
> 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.
Here's an idea you should consider. I am an end user who does not program.
Any software company with a good reputation sells me a program to allow me
to buy things safely and securely over the Internet. A number of people say
they have tested the software and it is highly secure; a number of people
say they have tested the software and it is not. The software encrypts my
bank account information all right, but it incidentally sends it to a
central database administered by your evil Linux programmer, who has gone to
work for the new company with no one the wiser. He is accumulating a second
Swiss bank account, presumably because he spent all the money in the first
one.
Or, I am a programmer who is quite bright, but just can't understand how
encryption algorithms work. I have that same compromised code mentioned
above, in SOURCE and still haven't a clue what is going on.
What percentage of the world's population is familiar with and understands
the algorithms involved? I'd guess it's certainly under 10%.... ;)
MORAL: SINCE MOST PEOPLE HAVEN'T A CLUE HOW, OR HOW EFFECTIVELY, ENCRYPTION
ALGORITHMS WORK, THEY SHOULD NEVER BUY ANYTHING ON THE COMPUTER AND NEVER
KEEP SECRET STUFF ON THE COMPUTER. Q.e.d. ;)
Linux users have access to the entire source code of the Linux kernel and
all the programs they run, if they want it. They are much more likely to be
computer literate than the average person.
Absolutely nothing will be certain to prevent clever people from breaking
random-number encryption. There are too many variables involved in the
software to be absolutely, certainly safe. But having the source code and
having the possibility of being able to understand it and understand the
issues involved helps A LOT.
> 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...
There are known trade-offs between speed and effectiveness of the algorithms
involved. So? As an end user, I'd like to have the benefit of maximum
effectiveness in encrypting my personal information, not to say improving
the security of my network connections, etc., etc.
As the mathematics student you mentioned, I suppose I'd have to consider
whether getting the randomness I needed was worth the minor resource usage
(yes, minor) that was required. I might even look at getting a faster
machine to do my research on. ;)
> And now just think about cryptography and reproductibility of results!!!
The desirability of reproducibility of results depends largely on who is
evaluating that desirability, to what category of results the desirability
applies and who the results are being reproduced for. For example, if the
results are successful decryptions of my personal secrets and they are being
reproduced for someone who should not be reading them, because I didn't use
a clever enough randomization algorithm, the desirability tends to be low.
> Those (and similiar arguments) are the reasons, while the /dev/random isn't
> usefull for real world apps.
>
> q.e.d. (Proof by contradiction.)
Your worries about compromises to randomization algorithms are groundless,
since they are likely to be used primarily for encryption, and most people
don't understand how encryption works and hence are unqualified to use it.
q.e.d.
Or, if you prefer, people who are unable to sacrifice minor computer
resources to gain services which are important to their research should
probably reconsider their priorities.... ;)
> The kernel fits again on the 3.5inch disk and the world is saved...
Apparently it was too large to fit by just the space taken up 16KB of
uncompressed data, when compressed. What, maybe 6K? Wow, eliminating 6K of
kernel code saves the world! In practice, you might want to start by
eliminating or modularizing some larger drivers if your kernel is getting
too big....
> 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.
As were mine both lazily-formulated and serious enough for our purposes here.
lilo