Replace hacked OpenSSL code with OpenSSL 0.9.8e distribution.

svn path=/openssl/Makefile; revision=659

1 files changed, 0 insertions, 476 deletions

diff --git a/openssl/trunk/MacOS/Randomizer.cpp b/openssl/trunk/MacOS/Randomizer.cpp
deleted file mode 100644
index cceb6bde..00000000
--- a/openssl/trunk/MacOS/Randomizer.cpp
+++ /dev/null
@@ -1,476 +0,0 @@
-/* 
-------- Strong random data generation on a Macintosh (pre - OS X) ------
-		
---	GENERAL: We aim to generate unpredictable bits without explicit
-	user interaction. A general review of the problem may be found
-	in RFC 1750, "Randomness Recommendations for Security", and some
-	more discussion, of general and Mac-specific issues has appeared
-	in "Using and Creating Cryptographic- Quality Random Numbers" by
-	Jon Callas (www.merrymeet.com/jon/usingrandom.html).
-
-	The data and entropy estimates provided below are based on my
-	limited experimentation and estimates, rather than by any
-	rigorous study, and the entropy estimates tend to be optimistic.
-	They should not be considered absolute.
-
-	Some of the information being collected may be correlated in
-	subtle ways. That includes mouse positions, timings, and disk
-	size measurements. Some obvious correlations will be eliminated
-	by the programmer, but other, weaker ones may remain. The
-	reliability of the code depends on such correlations being
-	poorly understood, both by us and by potential interceptors.
-
-	This package has been planned to be used with OpenSSL, v. 0.9.5.
-	It requires the OpenSSL function RAND_add. 
-
---	OTHER WORK: Some source code and other details have been
-	published elsewhere, but I haven't found any to be satisfactory
-	for the Mac per se:
-
-	* The Linux random number generator (by Theodore Ts'o, in
-	  drivers/char/random.c), is a carefully designed open-source
-	  crypto random number package. It collects data from a variety
-	  of sources, including mouse, keyboard and other interrupts.
-	  One nice feature is that it explicitly estimates the entropy
-	  of the data it collects. Some of its features (e.g. interrupt
-	  timing) cannot be reliably exported to the Mac without using
-	  undocumented APIs.
-
-	* Truerand by Don P. Mitchell and Matt Blaze uses variations
-	  between different timing mechanisms on the same system. This
-	  has not been tested on the Mac, but requires preemptive
-	  multitasking, and is hardware-dependent, and can't be relied
-	  on to work well if only one oscillator is present.
-
-	* Cryptlib's RNG for the Mac (RNDMAC.C by Peter Gutmann),
-	  gathers a lot of information about the machine and system
-	  environment. Unfortunately, much of it is constant from one
-	  startup to the next. In other words, the random seed could be
-	  the same from one day to the next. Some of the APIs are
-	  hardware-dependent, and not all are compatible with Carbon (OS
-	  X). Incidentally, the EGD library is based on the UNIX entropy
-	  gathering methods in cryptlib, and isn't suitable for MacOS
-	  either.
-
-	* Mozilla (and perhaps earlier versions of Netscape) uses the
-	  time of day (in seconds) and an uninitialized local variable
-	  to seed the random number generator. The time of day is known
-	  to an outside interceptor (to within the accuracy of the
-	  system clock). The uninitialized variable could easily be
-	  identical between subsequent launches of an application, if it
-	  is reached through the same path.
-
-	* OpenSSL provides the function RAND_screen(), by G. van
-	  Oosten, which hashes the contents of the screen to generate a
-	  seed. This is not useful for an extension or for an
-	  application which launches at startup time, since the screen
-	  is likely to look identical from one launch to the next. This
-	  method is also rather slow.
-
-	* Using variations in disk drive seek times has been proposed
-	  (Davis, Ihaka and Fenstermacher, world.std.com/~dtd/;
-	  Jakobsson, Shriver, Hillyer and Juels,
-	  www.bell-labs.com/user/shriver/random.html). These variations
-	  appear to be due to air turbulence inside the disk drive
-	  mechanism, and are very strongly unpredictable. Unfortunately
-	  this technique is slow, and some implementations of it may be
-	  patented (see Shriver's page above.) It of course cannot be
-	  used with a RAM disk.
-
---	TIMING: On the 601 PowerPC the time base register is guaranteed
-	to change at least once every 10 addi instructions, i.e. 10
-	cycles. On a 60 MHz machine (slowest PowerPC) this translates to
-	a resolution of 1/6 usec. Newer machines seem to be using a 10
-	cycle resolution as well.
-	
-	For 68K Macs, the Microseconds() call may be used. See Develop
-	issue 29 on the Apple developer site
-	(developer.apple.com/dev/techsupport/develop/issue29/minow.html)
-	for information on its accuracy and resolution. The code below
-	has been tested only on PowerPC based machines.
-
-	The time from machine startup to the launch of an application in
-	the startup folder has a variance of about 1.6 msec on a new G4
-	machine with a defragmented and optimized disk, most extensions
-	off and no icons on the desktop. This can be reasonably taken as
-	a lower bound on the variance. Most of this variation is likely
-	due to disk seek time variability. The distribution of startup
-	times is probably not entirely even or uncorrelated. This needs
-	to be investigated, but I am guessing that it not a majpor
-	problem. Entropy = log2 (1600/0.166) ~= 13 bits on a 60 MHz
-	machine, ~16 bits for a 450 MHz machine.
-
-	User-launched application startup times will have a variance of
-	a second or more relative to machine startup time. Entropy >~22
-	bits.
-
-	Machine startup time is available with a 1-second resolution. It
-	is predictable to no better a minute or two, in the case of
-	people who show up punctually to work at the same time and
-	immediately start their computer. Using the scheduled startup
-	feature (when available) will cause the machine to start up at
-	the same time every day, making the value predictable. Entropy
-	>~7 bits, or 0 bits with scheduled startup.
-
-	The time of day is of course known to an outsider and thus has 0
-	entropy if the system clock is regularly calibrated.
-
---	KEY TIMING: A  very fast typist (120 wpm) will have a typical
-	inter-key timing interval of 100 msec. We can assume a variance
-	of no less than 2 msec -- maybe. Do good typists have a constant
-	rhythm, like drummers? Since what we measure is not the
-	key-generated interrupt but the time at which the key event was
-	taken off the event queue, our resolution is roughly the time
-	between process switches, at best 1 tick (17 msec). I  therefore
-	consider this technique questionable and not very useful for
-	obtaining high entropy data on the Mac.
-
---	MOUSE POSITION AND TIMING: The high bits of the mouse position
-	are far from arbitrary, since the mouse tends to stay in a few
-	limited areas of the screen. I am guessing that the position of
-	the mouse is arbitrary within a 6 pixel square. Since the mouse
-	stays still for long periods of time, it should be sampled only
-	after it was moved, to avoid correlated data. This gives an
-	entropy of log2(6*6) ~= 5 bits per measurement.
-
-	The time during which the mouse stays still can vary from zero
-	to, say, 5 seconds (occasionally longer). If the still time is
-	measured by sampling the mouse during null events, and null
-	events are received once per tick, its resolution is 1/60th of a
-	second, giving an entropy of log2 (60*5) ~= 8 bits per
-	measurement. Since the distribution of still times is uneven,
-	this estimate is on the high side.
-
-	For simplicity and compatibility across system versions, the
-	mouse is to be sampled explicitly (e.g. in the event loop),
-	rather than in a time manager task.
-
---	STARTUP DISK TOTAL FILE SIZE: Varies typically by at least 20k
-	from one startup to the next, with 'minimal' computer use. Won't
-	vary at all if machine is started again immediately after
-	startup (unless virtual memory is on), but any application which
-	uses the web and caches information to disk is likely to cause
-	this much variation or more. The variation is probably not
-	random, but I don't know in what way. File sizes tend to be
-	divisible by 4 bytes since file format fields are often
-	long-aligned. Entropy > log2 (20000/4) ~= 12 bits.
-	
---	STARTUP DISK FIRST AVAILABLE ALLOCATION BLOCK: As the volume
-	gets fragmented this could be anywhere in principle. In a
-	perfectly unfragmented volume this will be strongly correlated
-	with the total file size on the disk. With more fragmentation
-	comes less certainty. I took the variation in this value to be
-	1/8 of the total file size on the volume.
-
---	SYSTEM REQUIREMENTS: The code here requires System 7.0 and above
-	(for Gestalt and Microseconds calls). All the calls used are
-	Carbon-compatible.
-*/
-
-/*------------------------------ Includes ----------------------------*/
-
-#include "Randomizer.h"
-
-// Mac OS API
-#include <Files.h>
-#include <Folders.h>
-#include <Events.h>
-#include <Processes.h>
-#include <Gestalt.h>
-#include <Resources.h>
-#include <LowMem.h>
-
-// Standard C library
-#include <stdlib.h>
-#include <math.h>
-
-/*---------------------- Function declarations -----------------------*/
-
-// declared in OpenSSL/crypto/rand/rand.h
-extern "C" void RAND_add (const void *buf, int num, double entropy);
-
-unsigned long GetPPCTimer (bool is601);	// Make it global if needed
-					// elsewhere
-
-/*---------------------------- Constants -----------------------------*/
-
-#define kMouseResolution 6		// Mouse position has to differ
-					// from the last one by this
-					// much to be entered
-#define kMousePositionEntropy 5.16	// log2 (kMouseResolution**2)
-#define kTypicalMouseIdleTicks 300.0	// I am guessing that a typical
-					// amount of time between mouse
-					// moves is 5 seconds
-#define kVolumeBytesEntropy 12.0	// about log2 (20000/4),
-					// assuming a variation of 20K
-					// in total file size and
-					// long-aligned file formats.
-#define kApplicationUpTimeEntropy 6.0	// Variance > 1 second, uptime
-					// in ticks  
-#define kSysStartupEntropy 7.0		// Entropy for machine startup
-					// time
-
-
-/*------------------------ Function definitions ----------------------*/
-
-CRandomizer::CRandomizer (void)
-{
-	long	result;
-	
-	mSupportsLargeVolumes =
-		(Gestalt(gestaltFSAttr, &result) == noErr) &&
-		((result & (1L << gestaltFSSupports2TBVols)) != 0);
-	
-	if (Gestalt (gestaltNativeCPUtype, &result) != noErr)
-	{
-		mIsPowerPC = false;
-		mIs601 = false;
-	}
-	else
-	{
-		mIs601 = (result == gestaltCPU601);
-		mIsPowerPC = (result >= gestaltCPU601);
-	}
-	mLastMouse.h = mLastMouse.v = -10;	// First mouse will
-						// always be recorded
-	mLastPeriodicTicks = TickCount();
-	GetTimeBaseResolution ();
-	
-	// Add initial entropy
-	AddTimeSinceMachineStartup ();
-	AddAbsoluteSystemStartupTime ();
-	AddStartupVolumeInfo ();
-	AddFiller ();
-}
-
-void CRandomizer::PeriodicAction (void)
-{
-	AddCurrentMouse ();
-	AddNow (0.0);	// Should have a better entropy estimate here
-	mLastPeriodicTicks = TickCount();
-}
-
-/*------------------------- Private Methods --------------------------*/
-
-void CRandomizer::AddCurrentMouse (void)
-{
-	Point mouseLoc;
-	unsigned long lastCheck;	// Ticks since mouse was last
-					// sampled
-
-#if TARGET_API_MAC_CARBON
-	GetGlobalMouse (&mouseLoc);
-#else
-	mouseLoc = LMGetMouseLocation();
-#endif
-	
-	if (labs (mLastMouse.h - mouseLoc.h) > kMouseResolution/2 &&
-	    labs (mLastMouse.v - mouseLoc.v) > kMouseResolution/2)
-		AddBytes (&mouseLoc, sizeof (mouseLoc),
-				kMousePositionEntropy);
-	
-	if (mLastMouse.h == mouseLoc.h && mLastMouse.v == mouseLoc.v)
-		mMouseStill ++;
-	else
-	{
-		double entropy;
-		
-		// Mouse has moved. Add the number of measurements for
-		// which it's been still. If the resolution is too
-		// coarse, assume the entropy is 0.
-
-		lastCheck = TickCount() - mLastPeriodicTicks;
-		if (lastCheck <= 0)
-			lastCheck = 1;
-		entropy = log2l
-			(kTypicalMouseIdleTicks/(double)lastCheck);
-		if (entropy < 0.0)
-			entropy = 0.0;
-		AddBytes (&mMouseStill, sizeof (mMouseStill), entropy);
-		mMouseStill = 0;
-	}
-	mLastMouse = mouseLoc;
-}
-
-void CRandomizer::AddAbsoluteSystemStartupTime (void)
-{
-	unsigned long	now;		// Time in seconds since
-					// 1/1/1904
-	GetDateTime (&now);
-	now -= TickCount() / 60;	// Time in ticks since machine
-					// startup
-	AddBytes (&now, sizeof (now), kSysStartupEntropy);
-}
-
-void CRandomizer::AddTimeSinceMachineStartup (void)
-{
-	AddNow (1.5);			// Uncertainty in app startup
-					// time is > 1.5 msec (for
-					// automated app startup).
-}
-
-void CRandomizer::AddAppRunningTime (void)
-{
-	ProcessSerialNumber PSN;
-	ProcessInfoRec		ProcessInfo;
-	
-	ProcessInfo.processInfoLength = sizeof (ProcessInfoRec);
-	ProcessInfo.processName = nil;
-	ProcessInfo.processAppSpec = nil;
-	
-	GetCurrentProcess (&PSN);
-	GetProcessInformation (&PSN, &ProcessInfo);
-
-	// Now add the amount of time in ticks that the current process
-	// has been active
-
-	AddBytes (&ProcessInfo, sizeof (ProcessInfoRec),
-			kApplicationUpTimeEntropy);
-}
-
-void CRandomizer::AddStartupVolumeInfo (void)
-{
-	short			vRefNum;
-	long			dirID;
-	XVolumeParam	pb;
-	OSErr			err;
-	
-	if (!mSupportsLargeVolumes)
-		return;
-		
-	FindFolder (kOnSystemDisk, kSystemFolderType, kDontCreateFolder,
-			&vRefNum, &dirID);
-	pb.ioVRefNum = vRefNum;
-	pb.ioCompletion = 0;
-	pb.ioNamePtr = 0;
-	pb.ioVolIndex = 0;
-	err = PBXGetVolInfoSync (&pb);
-	if (err != noErr)
-		return;
-		
-	// Base the entropy on the amount of space used on the disk and
-	// on the next available allocation block. A lot else might be
-	// unpredictable, so might as well toss the whole block in. See
-	// comments for entropy estimate justifications.
-
-	AddBytes (&pb, sizeof (pb),
-		kVolumeBytesEntropy +
-		log2l (((pb.ioVTotalBytes.hi - pb.ioVFreeBytes.hi)
-				* 4294967296.0D +
-			(pb.ioVTotalBytes.lo - pb.ioVFreeBytes.lo))
-				/ pb.ioVAlBlkSiz - 3.0));
-}
-
-/*
-	On a typical startup CRandomizer will come up with about 60
-	bits of good, unpredictable data. Assuming no more input will
-	be available, we'll need some more lower-quality data to give
-	OpenSSL the 128 bits of entropy it desires. AddFiller adds some
-	relatively predictable data into the soup.
-*/
-
-void CRandomizer::AddFiller (void)
-{
-	struct
-	{
-		ProcessSerialNumber psn;	// Front process serial
-						// number
-		RGBColor	hiliteRGBValue;	// User-selected
-						// highlight color
-		long		processCount;	// Number of active
-						// processes
-		long		cpuSpeed;	// Processor speed
-		long		totalMemory;	// Total logical memory
-						// (incl. virtual one)
-		long		systemVersion;	// OS version
-		short		resFile;	// Current resource file
-	} data;
-	
-	GetNextProcess ((ProcessSerialNumber*) kNoProcess);
-	while (GetNextProcess (&data.psn) == noErr)
-		data.processCount++;
-	GetFrontProcess (&data.psn);
-	LMGetHiliteRGB (&data.hiliteRGBValue);
-	Gestalt (gestaltProcClkSpeed, &data.cpuSpeed);
-	Gestalt (gestaltLogicalRAMSize, &data.totalMemory);
-	Gestalt (gestaltSystemVersion, &data.systemVersion);
-	data.resFile = CurResFile ();
-	
-	// Here we pretend to feed the PRNG completely random data. This
-	// is of course false, as much of the above data is predictable
-	// by an outsider. At this point we don't have any more
-	// randomness to add, but with OpenSSL we must have a 128 bit
-	// seed before we can start. We just add what we can, without a
-	// real entropy estimate, and hope for the best.
-
-	AddBytes (&data, sizeof(data), 8.0 * sizeof(data));
-	AddCurrentMouse ();
-	AddNow (1.0);
-}
-
-//-------------------  LOW LEVEL ---------------------
-
-void CRandomizer::AddBytes (void *data, long size, double entropy)
-{
-	RAND_add (data, size, entropy * 0.125);	// Convert entropy bits
-						// to bytes
-}
-
-void CRandomizer::AddNow (double millisecondUncertainty)
-{
-	long time = SysTimer();
-	AddBytes (&time, sizeof (time), log2l (millisecondUncertainty *
-			mTimebaseTicksPerMillisec));
-}
-
-//----------------- TIMING SUPPORT ------------------
-
-void CRandomizer::GetTimeBaseResolution (void)
-{	
-#ifdef __powerc
-	long speed;
-	
-	// gestaltProcClkSpeed available on System 7.5.2 and above
-	if (Gestalt (gestaltProcClkSpeed, &speed) != noErr)
-		// Only PowerPCs running pre-7.5.2 are 60-80 MHz
-		// machines.
-		mTimebaseTicksPerMillisec =  6000.0D;
-	// Assume 10 cycles per clock update, as in 601 spec. Seems true
-	// for later chips as well.
-	mTimebaseTicksPerMillisec = speed / 1.0e4D;
-#else
-	// 68K VIA-based machines (see Develop Magazine no. 29)
-	mTimebaseTicksPerMillisec = 783.360D;
-#endif
-}
-
-unsigned long CRandomizer::SysTimer (void)	// returns the lower 32
-						// bit of the chip timer
-{
-#ifdef __powerc
-	return GetPPCTimer (mIs601);
-#else
-	UnsignedWide usec;
-	Microseconds (&usec);
-	return usec.lo;
-#endif
-}
-
-#ifdef __powerc
-// The timebase is available through mfspr on 601, mftb on later chips.
-// Motorola recommends that an 601 implementation map mftb to mfspr
-// through an exception, but I haven't tested to see if MacOS actually
-// does this. We only sample the lower 32 bits of the timer (i.e. a
-// few minutes of resolution)
-
-asm unsigned long GetPPCTimer (register bool is601)
-{
-	cmplwi	is601, 0	// Check if 601
-	bne	_601		// if non-zero goto _601
-	mftb  	r3		// Available on 603 and later.
-	blr			// return with result in r3
-_601:
-	mfspr r3, spr5  	// Available on 601 only.
-				// blr inserted automatically
-}
-#endif