r169 - trunk/text/chapter02

robert at linuxfromscratch.org robert at linuxfromscratch.org
Sat Feb 12 10:32:42 PST 2005

Author: robert
Date: 2005-02-12 11:32:41 -0700 (Sat, 12 Feb 2005)
New Revision: 169

Added arc4random info page.

Added: trunk/text/chapter02/04-arc4random.txt
--- trunk/text/chapter02/04-arc4random.txt	2005-02-12 16:16:44 UTC (rev 168)
+++ trunk/text/chapter02/04-arc4random.txt	2005-02-12 18:32:41 UTC (rev 169)
@@ -0,0 +1,56 @@
+- Chapter 2 - Arc4random
+The arc4random() library function was developed by OpenBSD to provide very
+dependable random numbers even when the system is in awful running order.
+Originally it was made to provide a Libc interface to /dev/arandom and sysctl
+arandom, but arandom does not exist in Linux. The arc4random library uses
+arcfour (another rc4) key stream cipher, which can be in about (2**1700) states.
+The frandom kernel patch, providing erandom, is very similar to arandom except
+that erandom must be seeded manually, and erandom uses md5 hashes while arandom
+uses arcfour. Erandom is seeded from the state of frandom and uses no kernel
+entropy, but consequently is unsafe for cryptography. Frandom is seeded
+directly from the kernel entropy pool, but only once per use, and can provide
+gigabytes of output while only consuming 4 bytes of kernel entropy. To reseed
+erandom simply use frandom, such as dumping one block from frandom to /dev/null.
+The sysctl interfaces are available to provide entropy through chroot. Sysctl
+is a single thread interface, so the devices in /dev are attempted first. Even
+if the devices in /dev are not available sysctl has performed very well.
+The frandom, erandom, and sysctl urandom devices and interfaces are available
+from the pseudo_random kernel patch.
+In this implementation the Libc patches for arc4random provide two key
+functions, arc4random() and arc4randomII(). arc4random() uses urandom and is
+intended for cryptographic applications, arc4randomII() uses erandom and is
+intended for non-cryptographic applications. Both of these functions include
+gettimeofday(2) when initializing, making it impossible to generate the same
+sequence twice, even if the kernel random generator (urandom) has crashed.
+The first 256 long words (1024 bytes) are discarded due to a 'known text'
+weakness in the rc4 cipher. There is a man page provided with the Libc patches.
+The man page for arc4random(3) provided by OpenBSD assumes arc4random() uses
+arandom, and it is incorrect for this implementation.
+The Libc patches also patch mktemp(3) to use arc4randomII().
+Many applications can use arc4random() in place of /dev/urandom. Applications
+often have no fail safe or error control if the kernel random driver is
+OpenSSL supports arc4random() with a minor patch to enable it. Their portable
+alternative is to use getpid(), so using arc4random() is a significant
+Also see:
+Frandom homepage -
+Paper describing Arcfour -
+	draft-kaukonen-cipher-arcfour-03.txt
+Paper describing the RC4 (and arcfour) weakness -
+The original library source code -

Modified: trunk/text/chapter02/05-ssp.txt
--- trunk/text/chapter02/05-ssp.txt	2005-02-12 16:16:44 UTC (rev 168)
+++ trunk/text/chapter02/05-ssp.txt	2005-02-12 18:32:41 UTC (rev 169)
@@ -1,6 +1,6 @@
-- Chapter 2 - Smashing Stack Protector
+- Chapter 2 - Stack Smashing Protector
-Based on StackGaurd, Smashing Stack Protector (SSP) was developed by IBM's
+Based on StackGaurd, Stack Smashing Protector (SSP) was developed by IBM's
 Hiroaki Etoh for protecting applications from stack smashing attacks. This is
 the single largest class of attacks. There has been some effort to include SSP
 in the mainstream GCC, but this has yet to surface. Many distributions have
@@ -13,20 +13,10 @@
 -fno-stack-protector* to extensions for C and C++. -Wstack-protector is also
 available to warn when SSP is not used. The patch for Libc adds __guard_setup
 and __stack_smash_handler to libc.so and libc.a. __guard_setup is a function
-used to create a unique and random value for __guard each run time. The Frandom
-kernel patch was added to solve an entropy starvation bug caused by SSP needing
-a random seed for every program at run time. Frandom adds the Erandom device
-(economical random) which uses the state of Frandom as a seed. Frandom is seeded
-from the kernel's random device. The result is that Erandom does not consume
-any kernel entropy while producing crypto quality output. In the event of a
-stack overflow the __stack_smash_handler function will use the Libc syslog
-facility to record the overflow, which typically depends on /dev/log, and will
-abort the program. The Erandom device is available from the sysctl interface
-so it will work threw chroot. If the Erandom sysctl interface is not working
-for whatever reason the __guard_setup function will attempt to use /dev/urandom
-or gettimeofday to seed the __guard. The use of urandom will cause entropy
-starvation, and gettimeofday is not random, so this fallback is not ideal but
-provided as a safety net.
+used to create a unique and random value for __guard each run time. In the
+event of a stack overflow the __stack_smash_handler function will use the Libc
+syslog facility to record the overflow, which typically depends on /dev/log,
+and will abort the program.
 -fstack-protector only protects functions with arrays of length seven of less.
 -fstack-protector-all protects all functions regardless of array size.
@@ -40,7 +30,6 @@
 Also see:
 Operating system distributors using SSP (there are many more):

More information about the hlfs-dev mailing list