Random numbers We have seen that in many applications we need - PowerPoint PPT Presentation

Random numbers We have seen that in many applications we need random number generators • For example we sue random number generator to obtain session keys; to avoid key guessing – If an adversary sees a sequence of session keys – He/she must NOT be able to guess next session key (even in a probabilistic way) Note: good random number generator for cryptography is expensive

Random number generator • Use of systems data • Use of external information Above data are used to start a • Pseudo random number generator : a program that – Given an initial seed (random) – Obtains a long sequence of numbers If an adevrsary sees a long sequence of number in output it should be computationally very expensive to guess next output number (even in a probabilisitc sense)

Initial seed Different sources • Machine / network – Clock – Free space on disk – Number of files on dis – Info on operating system (I/O queus, buffer state etc. ) – User information (eg windows and size of windows) – Interarrival time of packets • User – Keyboard, mouse timing

Initial seed In most cases above sources provide fw bits of randomness (un fact many information can be easily guessed): • clock : we can use only low order digit (eg. Milliseconds: 10 bits of randomness) • Day hour minutes … can be easily guessed and are not random Therefore we must mix several sources of randomness using crypto functions

netscape Seed is computed as a funtion of • pid -process identifier • ppid parent process ID (shift 12 bit) • clock (second and millisecond) seed = MD5(x) MD5 crypto has function (at that time it was considerd secure hash f.)

netscape Pseudo number generator loop forever N = MD5(seed) seed= seed +1 return N This is used by netscape to compute all random material (all keys in SSL)

netscape problems • pid, ppid in most cases are 15 bit (and in many application scan be guessed) • Taking into accoutn 12 bit shift we get 27 random bits • Microseconds provedse 20 bit of randomenss • Seconds are easily guessed • Conclusion: there 47 bit of randomness too few!

Other mistakes: Debian Linux From Schenier’s blog: On May 13th, 2008 the Debian project announced that L. Bello found a vulnerability in the OpenSSL pack. The bug was caused by the removal of the following line of code from md_rand.c • MD_Update(&m,buf,j); / [ .. ] / MD_Update(&m,buf,j); These lines were removed because they caused the Valgrind and Purify tools to produce warnings about the use of uninitialized data in any code that was linked to OpenSSL. Removing this code has the side effect of crippling the seeding process for the OpenSSL PRNG. Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID. On the Linux platform, the default maximum process ID is 32,768, resulting in a very small number of seed values being used for all PRNG operations.

Microsoft: CryptGenRandom Security by not revealing: Based on SHA-1 and followinf external data – The current process ID (GetCurrentProcessID). – The current thread ID (GetCurrentThreadID). ･ – The tick count since boot time (GetTickCount). – The current time (GetLocalTime). – Various high-precision performance counters (QueryPerformanceCounter). – An MD4 hash of the user's environment block, which includes username, computer name, and search path. [...] ･ High-precision internal CPU counters, such as RDTSC, RDMSR, RDPMC[ omitted: long lists of low-level system information fields and performance counters ]

Other problems: Microsoft CryptGenRandom : • Not public • Bruce Schneier "Since the only way to have any confidence in an algorithm's security is to have experts examine it, and the only way they will spend the time necessary to adequately examine it is to allow them to publish research papers about it, the algorithm has to be public. A proprietary algorithm, no matter who designed it and who was paid under Non Disclosure Agreement to evaluate it, is much riskier than a public algorithm."

Other problems: DUAL_EC_DRBG • Dual_EC_DRBG: algorithm supported by NSA (national Sec. Agency US): • Problem: 2007 D. Shumow and N. Ferguson showed that the algorithm contains a weakness that can only be described as a backdoor (There is a possible set of numbers - derived form these constants - whose knowledge allows to predict random numbers) • This is how it works: There are a bunch of constants -- fixed numbers -- in the standard used to define the algorithm's elliptic curve. These constants are listed in Appendix A of the NIST publication, but nowhere is it explained where they came from. Form thiese constants it is in theory possible to derive the secret set of numbers

Cryptographic generators A pseduo number generator is cryptographically strong if it passes one of the two following test • Next bit test: no polynomial time alg with input a sequence of numbers generated is able to guess next bit with probability >0.5 • Statistical tes: no polunomila time algorithm is able to distinguish with prob. >0.5 a truly random sequence forma a pseudo random sequence NOTE: THE TWO TEST ARE EQUIVALENT

Cryptographic generators • Cipher of a counter seed s,cryptog. Function E, initial value c , loop xi = E_s(c) (encode c using key s) c = c +1 • Geenerator with RSA: prime numbers p,q , n = pq, e integer s.t. MCD(e, (n)) = 1, z(1)= 0 loop forever z(i)= z(i-1)**e mod n i = i +1 output (less significant bit of z(i))

Generator standard X9.17 uses 3DES • input: seed s 64 bit, integer m, triple DES key, time( day and hour) • output: x1, x2, ..xm sequence of 64 bit numbers 1. compute I= 3DES(D) 2. for i = 1 to m do xi = 3DES(I exor s) s = 3DES(xi exor I) 3. return x1,x2,.... xm

Random number gener.: conclusions Schenier: • Random numbers are used everywhere in cryptography, for both short- and long-term security. And, as we've seen here, security flaws in random number generators are really easy to accidently create and really hard to discover after the fact. Back when the NSA was routinely weakening commercial cryptography, their favorite technique was reducing the entropy of the random number generator.

Exercise • Pseudo random numebr generator using hash fct • Seed : initial truly random value y = seed for i=1 to n do y=Hash(y) output(y) This is not a good random number generator, why?