import openssl-0.9.7-beta1

14 files changed, 1961 insertions, 0 deletions

diff --git a/lib/libssl/src/MacOS/Randomizer.cpp b/lib/libssl/src/MacOS/Randomizer.cpp
new file mode 100644
index 00000000000..cceb6bde44f
--- /dev/null
+++ b/lib/libssl/src/MacOS/Randomizer.cpp
@@ -0,0 +1,476 @@
+/* 
+------- 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
diff --git a/lib/libssl/src/MacOS/Randomizer.h b/lib/libssl/src/MacOS/Randomizer.h
new file mode 100644
index 00000000000..565537b15df
--- /dev/null
+++ b/lib/libssl/src/MacOS/Randomizer.h
@@ -0,0 +1,43 @@
+
+//	Gathers unpredictable system data to be used for generating
+//	random bits
+
+#include <MacTypes.h>
+
+class CRandomizer
+{
+public:
+	CRandomizer (void);
+	void PeriodicAction (void);
+	
+private:
+
+	// Private calls
+
+	void		AddTimeSinceMachineStartup (void);
+	void		AddAbsoluteSystemStartupTime (void);
+	void		AddAppRunningTime (void);
+	void		AddStartupVolumeInfo (void);
+	void		AddFiller (void);
+
+	void		AddCurrentMouse (void);
+	void		AddNow (double millisecondUncertainty);
+	void		AddBytes (void *data, long size, double entropy);
+	
+	void		GetTimeBaseResolution (void);
+	unsigned long	SysTimer (void);
+
+	// System Info	
+	bool		mSupportsLargeVolumes;
+	bool		mIsPowerPC;
+	bool		mIs601;
+	
+	// Time info
+	double		mTimebaseTicksPerMillisec;
+	unsigned long	mLastPeriodicTicks;
+	
+	// Mouse info
+	long		mSamplePeriod;
+	Point		mLastMouse;
+	long		mMouseStill;
+};
diff --git a/lib/libssl/src/apps/rand.c b/lib/libssl/src/apps/rand.c
new file mode 100644
index 00000000000..cfbba307558
--- /dev/null
+++ b/lib/libssl/src/apps/rand.c
@@ -0,0 +1,140 @@
+/* apps/rand.c */
+
+#include "apps.h"
+
+#include <ctype.h>
+#include <stdio.h>
+#include <string.h>
+
+#include <openssl/bio.h>
+#include <openssl/err.h>
+#include <openssl/rand.h>
+
+#undef PROG
+#define PROG rand_main
+
+/* -out file         - write to file
+ * -rand file:file   - PRNG seed files
+ * -base64           - encode output
+ * num               - write 'num' bytes
+ */
+
+int MAIN(int, char **);
+
+int MAIN(int argc, char **argv)
+	{
+	int i, r, ret = 1;
+	int badopt;
+	char *outfile = NULL;
+	char *inrand = NULL;
+	int base64 = 0;
+	BIO *out = NULL;
+	int num = -1;
+
+	apps_startup();
+
+	if (bio_err == NULL)
+		if ((bio_err = BIO_new(BIO_s_file())) != NULL)
+			BIO_set_fp(bio_err, stderr, BIO_NOCLOSE|BIO_FP_TEXT);
+
+	badopt = 0;
+	i = 0;
+	while (!badopt && argv[++i] != NULL)
+		{
+		if (strcmp(argv[i], "-out") == 0)
+			{
+			if ((argv[i+1] != NULL) && (outfile == NULL))
+				outfile = argv[++i];
+			else
+				badopt = 1;
+			}
+		else if (strcmp(argv[i], "-rand") == 0)
+			{
+			if ((argv[i+1] != NULL) && (inrand == NULL))
+				inrand = argv[++i];
+			else
+				badopt = 1;
+			}
+		else if (strcmp(argv[i], "-base64") == 0)
+			{
+			if (!base64)
+				base64 = 1;
+			else
+				badopt = 1;
+			}
+		else if (isdigit(argv[i][0]))
+			{
+			if (num < 0)
+				{
+				r = sscanf(argv[i], "%d", &num);
+				if (r == 0 || num < 0)
+					badopt = 1;
+				}
+			else
+				badopt = 1;
+			}
+		else
+			badopt = 1;
+		}
+
+	if (num < 0)
+		badopt = 1;
+	
+	if (badopt) 
+		{
+		BIO_printf(bio_err, "Usage: rand [options] num\n");
+		BIO_printf(bio_err, "where options are\n");
+		BIO_printf(bio_err, "-out file            - write to file\n");
+		BIO_printf(bio_err, "-rand file%cfile%c...  - seed PRNG from files\n", LIST_SEPARATOR_CHAR, LIST_SEPARATOR_CHAR);
+		BIO_printf(bio_err, "-base64              - encode output\n");
+		goto err;
+		}
+
+	app_RAND_load_file(NULL, bio_err, (inrand != NULL));
+	if (inrand != NULL)
+		BIO_printf(bio_err,"%ld semi-random bytes loaded\n",
+			app_RAND_load_files(inrand));
+
+	out = BIO_new(BIO_s_file());
+	if (out == NULL)
+		goto err;
+	if (outfile != NULL)
+		r = BIO_write_filename(out, outfile);
+	else
+		r = BIO_set_fp(out, stdout, BIO_NOCLOSE | BIO_FP_TEXT);
+	if (r <= 0)
+		goto err;
+
+	if (base64)
+		{
+		BIO *b64 = BIO_new(BIO_f_base64());
+		if (b64 == NULL)
+			goto err;
+		out = BIO_push(b64, out);
+		}
+	
+	while (num > 0) 
+		{
+		unsigned char buf[4096];
+		int chunk;
+
+		chunk = num;
+		if (chunk > sizeof buf)
+			chunk = sizeof buf;
+		r = RAND_bytes(buf, chunk);
+		if (r <= 0)
+			goto err;
+		BIO_write(out, buf, chunk);
+		num -= chunk;
+		}
+	BIO_flush(out);
+
+	app_RAND_write_file(NULL, bio_err);
+	ret = 0;
+	
+err:
+	ERR_print_errors(bio_err);
+	if (out)
+		BIO_free_all(out);
+	EXIT(ret);
+	}
diff --git a/lib/libssl/src/apps/winrand.c b/lib/libssl/src/apps/winrand.c
new file mode 100644
index 00000000000..d042258b504
--- /dev/null
+++ b/lib/libssl/src/apps/winrand.c
@@ -0,0 +1,149 @@
+/* apps/winrand.c */
+/* ====================================================================
+ * Copyright (c) 1998-2000 The OpenSSL Project.  All rights reserved.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions
+ * are met:
+ *
+ * 1. Redistributions of source code must retain the above copyright
+ *    notice, this list of conditions and the following disclaimer. 
+ *
+ * 2. Redistributions in binary form must reproduce the above copyright
+ *    notice, this list of conditions and the following disclaimer in
+ *    the documentation and/or other materials provided with the
+ *    distribution.
+ *
+ * 3. All advertising materials mentioning features or use of this
+ *    software must display the following acknowledgment:
+ *    "This product includes software developed by the OpenSSL Project
+ *    for use in the OpenSSL Toolkit. (http://www.openssl.org/)"
+ *
+ * 4. The names "OpenSSL Toolkit" and "OpenSSL Project" must not be used to
+ *    endorse or promote products derived from this software without
+ *    prior written permission. For written permission, please contact
+ *    openssl-core@openssl.org.
+ *
+ * 5. Products derived from this software may not be called "OpenSSL"
+ *    nor may "OpenSSL" appear in their names without prior written
+ *    permission of the OpenSSL Project.
+ *
+ * 6. Redistributions of any form whatsoever must retain the following
+ *    acknowledgment:
+ *    "This product includes software developed by the OpenSSL Project
+ *    for use in the OpenSSL Toolkit (http://www.openssl.org/)"
+ *
+ * THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS'' AND ANY
+ * EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
+ * PURPOSE ARE DISCLAIMED.  IN NO EVENT SHALL THE OpenSSL PROJECT OR
+ * ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
+ * SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
+ * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
+ * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT,
+ * STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED
+ * OF THE POSSIBILITY OF SUCH DAMAGE.
+ * ====================================================================
+ *
+ * This product includes cryptographic software written by Eric Young
+ * (eay@cryptsoft.com).  This product includes software written by Tim
+ * Hudson (tjh@cryptsoft.com).
+ *
+ */
+
+/* Usage: winrand [filename]
+ *
+ * Collects entropy from mouse movements and other events and writes
+ * random data to filename or .rnd
+ */
+
+#include <windows.h>
+#include <openssl/opensslv.h>
+#include <openssl/rand.h>
+
+LRESULT CALLBACK WndProc(HWND, UINT, WPARAM, LPARAM);
+const char *filename;
+
+int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance,
+        PSTR cmdline, int iCmdShow)
+	{
+	static char appname[] = "OpenSSL";
+	HWND hwnd;
+	MSG msg;
+	WNDCLASSEX wndclass;
+        char buffer[200];
+
+        if (cmdline[0] == '\0')
+                filename = RAND_file_name(buffer, sizeof buffer);
+        else
+                filename = cmdline;
+
+        RAND_load_file(filename, -1);
+
+	wndclass.cbSize = sizeof(wndclass);
+	wndclass.style = CS_HREDRAW | CS_VREDRAW;
+	wndclass.lpfnWndProc = WndProc;
+	wndclass.cbClsExtra = 0;
+	wndclass.cbWndExtra = 0;
+	wndclass.hInstance = hInstance;
+	wndclass.hIcon = LoadIcon(NULL, IDI_APPLICATION);
+	wndclass.hCursor = LoadCursor(NULL, IDC_ARROW);
+	wndclass.hbrBackground = (HBRUSH) GetStockObject(WHITE_BRUSH);
+	wndclass.lpszMenuName = NULL;
+        wndclass.lpszClassName = appname;
+	wndclass.hIconSm = LoadIcon(NULL, IDI_APPLICATION);
+	RegisterClassEx(&wndclass);
+
+        hwnd = CreateWindow(appname, OPENSSL_VERSION_TEXT,
+		WS_OVERLAPPEDWINDOW, CW_USEDEFAULT, CW_USEDEFAULT,
+		CW_USEDEFAULT, CW_USEDEFAULT, NULL, NULL, hInstance, NULL);
+
+	ShowWindow(hwnd, iCmdShow);
+	UpdateWindow(hwnd);
+
+
+	while (GetMessage(&msg, NULL, 0, 0))
+		{
+		TranslateMessage(&msg);
+		DispatchMessage(&msg);
+		}
+
+	return msg.wParam;
+	}
+
+LRESULT CALLBACK WndProc(HWND hwnd, UINT iMsg, WPARAM wParam, LPARAM lParam)
+	{
+        HDC hdc;
+	PAINTSTRUCT ps;
+        RECT rect;
+        char buffer[200];
+        static int seeded = 0;
+
+	switch (iMsg)
+		{
+	case WM_PAINT:
+		hdc = BeginPaint(hwnd, &ps);
+		GetClientRect(hwnd, &rect);
+                DrawText(hdc, "Seeding the PRNG. Please move the mouse!", -1,
+			&rect, DT_SINGLELINE | DT_CENTER | DT_VCENTER);
+		EndPaint(hwnd, &ps);
+		return 0;
+		
+        case WM_DESTROY:
+                PostQuitMessage(0);
+                return 0;
+                }
+
+        if (RAND_event(iMsg, wParam, lParam) == 1 && seeded == 0)
+                {
+                seeded = 1;
+                if (RAND_write_file(filename) <= 0)
+                        MessageBox(hwnd, "Couldn't write random file!",
+				"OpenSSL", MB_OK | MB_ICONERROR);
+                PostQuitMessage(0);
+                }
+
+	return DefWindowProc(hwnd, iMsg, wParam, lParam);
+	}
diff --git a/lib/libssl/src/crypto/des/des.pod b/lib/libssl/src/crypto/des/des.pod
new file mode 100644
index 00000000000..bf479e83d26
--- /dev/null
+++ b/lib/libssl/src/crypto/des/des.pod
@@ -0,0 +1,217 @@
+=pod
+
+=head1 NAME
+
+des - encrypt or decrypt data using Data Encryption Standard
+
+=head1 SYNOPSIS
+
+B<des>
+(
+B<-e>
+|
+B<-E>
+) | (
+B<-d>
+|
+B<-D>
+) | (
+B<->[B<cC>][B<ckname>]
+) |
+[
+B<-b3hfs>
+] [
+B<-k>
+I<key>
+]
+] [
+B<-u>[I<uuname>]
+[
+I<input-file>
+[
+I<output-file>
+] ]
+
+=head1 NOTE
+
+This page describes the B<des> stand-alone program, not the B<openssl des>
+command.
+
+=head1 DESCRIPTION
+
+B<des>
+encrypts and decrypts data using the
+Data Encryption Standard algorithm.
+One of
+B<-e>, B<-E>
+(for encrypt) or
+B<-d>, B<-D>
+(for decrypt) must be specified.
+It is also possible to use
+B<-c>
+or
+B<-C>
+in conjunction or instead of the a encrypt/decrypt option to generate
+a 16 character hexadecimal checksum, generated via the
+I<des_cbc_cksum>.
+
+Two standard encryption modes are supported by the
+B<des>
+program, Cipher Block Chaining (the default) and Electronic Code Book
+(specified with
+B<-b>).
+
+The key used for the DES
+algorithm is obtained by prompting the user unless the
+B<-k>
+I<key>
+option is given.
+If the key is an argument to the
+B<des>
+command, it is potentially visible to users executing
+ps(1)
+or a derivative.  To minimise this possibility,
+B<des>
+takes care to destroy the key argument immediately upon entry.
+If your shell keeps a history file be careful to make sure it is not
+world readable.
+
+Since this program attempts to maintain compatibility with sunOS's
+des(1) command, there are 2 different methods used to convert the user
+supplied key to a des key.
+Whenever and one or more of
+B<-E>, B<-D>, B<-C>
+or
+B<-3>
+options are used, the key conversion procedure will not be compatible
+with the sunOS des(1) version but will use all the user supplied
+character to generate the des key.
+B<des>
+command reads from standard input unless
+I<input-file>
+is specified and writes to standard output unless
+I<output-file>
+is given.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-b>
+
+Select ECB
+(eight bytes at a time) encryption mode.
+
+=item B<-3>
+
+Encrypt using triple encryption.
+By default triple cbc encryption is used but if the
+B<-b>
+option is used then triple ECB encryption is performed.
+If the key is less than 8 characters long, the flag has no effect.
+
+=item B<-e>
+
+Encrypt data using an 8 byte key in a manner compatible with sunOS
+des(1).
+
+=item B<-E>
+
+Encrypt data using a key of nearly unlimited length (1024 bytes).
+This will product a more secure encryption.
+
+=item B<-d>
+
+Decrypt data that was encrypted with the B<-e> option.
+
+=item B<-D>
+
+Decrypt data that was encrypted with the B<-E> option.
+
+=item B<-c>
+
+Generate a 16 character hexadecimal cbc checksum and output this to
+stderr.
+If a filename was specified after the
+B<-c>
+option, the checksum is output to that file.
+The checksum is generated using a key generated in a sunOS compatible
+manner.
+
+=item B<-C>
+
+A cbc checksum is generated in the same manner as described for the
+B<-c>
+option but the DES key is generated in the same manner as used for the
+B<-E>
+and
+B<-D>
+options
+
+=item B<-f>
+
+Does nothing - allowed for compatibility with sunOS des(1) command.
+
+=item B<-s>
+
+Does nothing - allowed for compatibility with sunOS des(1) command.
+
+=item B<-k> I<key>
+
+Use the encryption 
+I<key>
+specified.
+
+=item B<-h>
+
+The
+I<key>
+is assumed to be a 16 character hexadecimal number.
+If the
+B<-3>
+option is used the key is assumed to be a 32 character hexadecimal
+number.
+
+=item B<-u>
+
+This flag is used to read and write uuencoded files.  If decrypting,
+the input file is assumed to contain uuencoded, DES encrypted data.
+If encrypting, the characters following the B<-u> are used as the name of
+the uuencoded file to embed in the begin line of the uuencoded
+output.  If there is no name specified after the B<-u>, the name text.des
+will be embedded in the header.
+
+=head1 SEE ALSO
+
+ps(1),
+L<des_crypt(3)|des_crypt(3)>
+
+=head1 BUGS
+
+The problem with using the
+B<-e>
+option is the short key length.
+It would be better to use a real 56-bit key rather than an
+ASCII-based 56-bit pattern.  Knowing that the key was derived from ASCII
+radically reduces the time necessary for a brute-force cryptographic attack.
+My attempt to remove this problem is to add an alternative text-key to
+DES-key function.  This alternative function (accessed via
+B<-E>, B<-D>, B<-S>
+and
+B<-3>)
+uses DES to help generate the key.
+
+Be carefully when using the B<-u> option.  Doing B<des -ud> I<filename> will
+not decrypt filename (the B<-u> option will gobble the B<-d> option).
+
+The VMS operating system operates in a world where files are always a
+multiple of 512 bytes.  This causes problems when encrypted data is
+send from Unix to VMS since a 88 byte file will suddenly be padded
+with 424 null bytes.  To get around this problem, use the B<-u> option
+to uuencode the data before it is send to the VMS system.
+
+=head1 AUTHOR
+
+Eric Young (eay@cryptsoft.com)
+
+=cut
diff --git a/lib/libssl/src/doc/apps/rand.pod b/lib/libssl/src/doc/apps/rand.pod
new file mode 100644
index 00000000000..f81eab0457f
--- /dev/null
+++ b/lib/libssl/src/doc/apps/rand.pod
@@ -0,0 +1,50 @@
+=pod
+
+=head1 NAME
+
+rand - generate pseudo-random bytes
+
+=head1 SYNOPSIS
+
+B<openssl rand>
+[B<-out> I<file>]
+[B<-rand> I<file(s)>]
+[B<-base64>]
+I<num>
+
+=head1 DESCRIPTION
+
+The B<rand> command outputs I<num> pseudo-random bytes after seeding
+the random number generater once.  As in other B<openssl> command
+line tools, PRNG seeding uses the file I<$HOME/>B<.rnd> or B<.rnd>
+in addition to the files given in the B<-rand> option.  A new
+I<$HOME>/B<.rnd> or B<.rnd> file will be written back if enough
+seeding was obtained from these sources.
+
+=head1 OPTIONS
+
+=over 4
+
+=item B<-out> I<file>
+
+Write to I<file> instead of standard output.
+
+=item B<-rand> I<file(s)>
+
+Use specified file or files or EGD socket (see L<RAND_egd(3)|RAND_egd(3)>)
+for seeding the random number generator.
+Multiple files can be specified separated by a OS-dependent character.
+The separator is B<;> for MS-Windows, B<,> for OpenVSM, and B<:> for
+all others.
+
+=item B<-base64>
+
+Perform base64 encoding on the output.
+
+=back
+
+=head1 SEE ALSO
+
+L<RAND_bytes(3)|RAND_bytes(3)>
+
+=cut
diff --git a/lib/libssl/src/doc/crypto/EVP_OpenInit.pod b/lib/libssl/src/doc/crypto/EVP_OpenInit.pod
new file mode 100644
index 00000000000..9707a4b3997
--- /dev/null
+++ b/lib/libssl/src/doc/crypto/EVP_OpenInit.pod
@@ -0,0 +1,51 @@
+=pod
+
+=head1 NAME
+
+EVP_OpenInit, EVP_OpenUpdate, EVP_OpenFinal - EVP envelope decryption
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_OpenInit(EVP_CIPHER_CTX *ctx,EVP_CIPHER *type,unsigned char *ek,
+		int ekl,unsigned char *iv,EVP_PKEY *priv);
+ void EVP_OpenUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl, unsigned char *in, int inl);
+ void EVP_OpenFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl);
+
+=head1 DESCRIPTION
+
+The EVP envelope routines are a high level interface to envelope
+decryption. They decrypt a public key encrypted symmetric key and
+then decrypt data using it.
+
+EVP_OpenInit() initialises a cipher context B<ctx> for decryption
+with cipher B<type>. It decrypts the encrypted symmetric key of length
+B<ekl> bytes passed in the B<ek> parameter using the private key B<priv>.
+The IV is supplied in the B<iv> parameter.
+
+EVP_OpenUpdate() and EVP_OpenFinal() have exactly the same properties
+as the EVP_DecryptUpdate() and EVP_DecryptFinal() routines, as 
+documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual
+page. 
+
+=head1 RETURN VALUES
+
+EVP_OpenInit() returns -1 on error or an non zero integer (actually the
+recovered secret key size) if successful.
+
+EVP_SealUpdate() does not return a value.
+
+EVP_SealFinal() returns 0 if the decrypt failed or 1 for success.
+
+=head1 SEE ALSO
+
+L<evp(3)|evp(3)>,L<rand(3)|rand(3)>
+L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>,
+L<EVP_SealInit(3)|EVP_SealInit(3)>
+
+=head1 HISTORY
+
+=cut
diff --git a/lib/libssl/src/doc/crypto/EVP_SealInit.pod b/lib/libssl/src/doc/crypto/EVP_SealInit.pod
new file mode 100644
index 00000000000..1579d110fa2
--- /dev/null
+++ b/lib/libssl/src/doc/crypto/EVP_SealInit.pod
@@ -0,0 +1,70 @@
+=pod
+
+=head1 NAME
+
+EVP_SealInit, EVP_SealUpdate, EVP_SealFinal - EVP envelope encryption
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ int EVP_SealInit(EVP_CIPHER_CTX *ctx, EVP_CIPHER *type, unsigned char **ek,
+		int *ekl, unsigned char *iv,EVP_PKEY **pubk, int npubk);
+ void EVP_SealUpdate(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl, unsigned char *in, int inl);
+ void EVP_SealFinal(EVP_CIPHER_CTX *ctx, unsigned char *out,
+         int *outl);
+
+=head1 DESCRIPTION
+
+The EVP envelope routines are a high level interface to envelope
+encryption. They generate a random key and then "envelope" it by
+using public key encryption. Data can then be encrypted using this
+key.
+
+EVP_SealInit() initialises a cipher context B<ctx> for encryption
+with cipher B<type> using a random secret key and IV supplied in
+the B<iv> parameter. B<type> is normally supplied by a function such
+as EVP_des_cbc(). The secret key is encrypted using one or more public
+keys, this allows the same encrypted data to be decrypted using any
+of the corresponding private keys. B<ek> is an array of buffers where
+the public key encrypted secret key will be written, each buffer must
+contain enough room for the corresponding encrypted key: that is
+B<ek[i]> must have room for B<EVP_PKEY_size(pubk[i])> bytes. The actual
+size of each encrypted secret key is written to the array B<ekl>. B<pubk> is
+an array of B<npubk> public keys.
+
+EVP_SealUpdate() and EVP_SealFinal() have exactly the same properties
+as the EVP_EncryptUpdate() and EVP_EncryptFinal() routines, as 
+documented on the L<EVP_EncryptInit(3)|EVP_EncryptInit(3)> manual
+page. 
+
+=head1 RETURN VALUES
+
+EVP_SealInit() returns -1 on error or B<npubk> if successful.
+
+EVP_SealUpdate() and EVP_SealFinal() do not return values.
+
+=head1 NOTES
+
+Because a random secret key is generated the random number generator
+must be seeded before calling EVP_SealInit().
+
+The public key must be RSA because it is the only OpenSSL public key
+algorithm that supports key transport.
+
+Envelope encryption is the usual method of using public key encryption
+on large amounts of data, this is because public key encryption is slow
+but symmetric encryption is fast. So symmetric encryption is used for
+bulk encryption and the small random symmetric key used is transferred
+using public key encryption.
+
+=head1 SEE ALSO
+
+L<evp(3)|evp(3)>,L<rand(3)|rand(3)>
+L<EVP_EncryptInit(3)|EVP_EncryptInit(3)>,
+L<EVP_OpenInit(3)|EVP_OpenInit(3)>
+
+=head1 HISTORY
+
+=cut
diff --git a/lib/libssl/src/doc/crypto/EVP_SignInit.pod b/lib/libssl/src/doc/crypto/EVP_SignInit.pod
new file mode 100644
index 00000000000..bbc9203c9ca
--- /dev/null
+++ b/lib/libssl/src/doc/crypto/EVP_SignInit.pod
@@ -0,0 +1,85 @@
+=pod
+
+=head1 NAME
+
+EVP_SignInit, EVP_SignUpdate, EVP_SignFinal - EVP signing functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ void EVP_SignInit(EVP_MD_CTX *ctx, const EVP_MD *type);
+ void EVP_SignUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
+ int EVP_SignFinal(EVP_MD_CTX *ctx,unsigned char *sig,unsigned int *s, EVP_PKEY *pkey);
+
+ int EVP_PKEY_size(EVP_PKEY *pkey);
+
+=head1 DESCRIPTION
+
+The EVP signature routines are a high level interface to digital
+signatures.
+
+EVP_SignInit() initialises a signing context B<ctx> to using digest
+B<type>: this will typically be supplied by a function such as
+EVP_sha1().
+
+EVP_SignUpdate() hashes B<cnt> bytes of data at B<d> into the
+signature context B<ctx>. This funtion can be called several times on the
+same B<ctx> to include additional data.
+
+EVP_SignFinal() signs the data in B<ctx> using the private key B<pkey>
+and places the signature in B<sig>. If the B<s> parameter is not NULL
+then the number of bytes of data written (i.e. the length of the signature)
+will be written to the integer at B<s>, at most EVP_PKEY_size(pkey) bytes
+will be written.  After calling EVP_SignFinal() no additional calls to
+EVP_SignUpdate() can be made, but EVP_SignInit() can be called to initialiase
+a new signature operation.
+
+EVP_PKEY_size() returns the maximum size of a signature in bytes. The actual
+signature returned by EVP_SignFinal() may be smaller.
+
+=head1 RETURN VALUES
+
+EVP_SignInit() and EVP_SignUpdate() do not return values.
+
+EVP_SignFinal() returns 1 for success and 0 for failure.
+
+EVP_PKEY_size() returns the maximum size of a signature in bytes.
+
+The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
+
+=head1 NOTES
+
+The B<EVP> interface to digital signatures should almost always be used in
+preference to the low level interfaces. This is because the code then becomes
+transparent to the algorithm used and much more flexible.
+
+Due to the link between message digests and public key algorithms the correct
+digest algorithm must be used with the correct public key type. A list of
+algorithms and associated public key algorithms appears in 
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>.
+
+When signing with DSA private keys the random number generator must be seeded
+or the operation will fail. The random number generator does not need to be
+seeded for RSA signatures.
+
+=head1 BUGS
+
+Several of the functions do not return values: maybe they should. Although the
+internal digest operations will never fail some future hardware based operations
+might.
+
+=head1 SEE ALSO
+
+L<EVP_VerifyInit(3)|EVP_VerifyInit(3)>,
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<err(3)|err(3)>,
+L<evp(3)|evp(3)>, L<hmac(3)|hmac(3)>, L<md2(3)|md2(3)>,
+L<md5(3)|md5(3)>, L<mdc2(3)|mdc2(3)>, L<ripemd(3)|ripemd(3)>,
+L<sha(3)|sha(3)>, L<digest(1)|digest(1)>
+
+=head1 HISTORY
+
+EVP_SignInit(), EVP_SignUpdate() and EVP_SignFinal() are
+available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod b/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod
new file mode 100644
index 00000000000..3b5e07f4ade
--- /dev/null
+++ b/lib/libssl/src/doc/crypto/EVP_VerifyInit.pod
@@ -0,0 +1,71 @@
+=pod
+
+=head1 NAME
+
+EVP_VerifyInit, EVP_VerifyUpdate, EVP_VerifyFinal - EVP signature verification functions
+
+=head1 SYNOPSIS
+
+ #include <openssl/evp.h>
+
+ void EVP_VerifyInit(EVP_MD_CTX *ctx, const EVP_MD *type);
+ void EVP_VerifyUpdate(EVP_MD_CTX *ctx, const void *d, unsigned int cnt);
+ int EVP_VerifyFinal(EVP_MD_CTX *ctx,unsigned char *sigbuf, unsigned int siglen,EVP_PKEY *pkey);
+
+=head1 DESCRIPTION
+
+The EVP signature verification routines are a high level interface to digital
+signatures.
+
+EVP_VerifyInit() initialises a verification context B<ctx> to using digest
+B<type>: this will typically be supplied by a function such as EVP_sha1().
+
+EVP_VerifyUpdate() hashes B<cnt> bytes of data at B<d> into the
+verification context B<ctx>. This funtion can be called several times on the
+same B<ctx> to include additional data.
+
+EVP_VerifyFinal() verifies the data in B<ctx> using the public key B<pkey>
+and against the B<siglen> bytes at B<sigbuf>. After calling EVP_VerifyFinal()
+no additional calls to EVP_VerifyUpdate() can be made, but EVP_VerifyInit()
+can be called to initialiase a new verification operation.
+
+=head1 RETURN VALUES
+
+EVP_VerifyInit() and EVP_VerifyUpdate() do not return values.
+
+EVP_VerifyFinal() returns 1 for a correct signature, 0 for failure and -1 if some
+other error occurred.
+
+The error codes can be obtained by L<ERR_get_error(3)|ERR_get_error(3)>.
+
+=head1 NOTES
+
+The B<EVP> interface to digital signatures should almost always be used in
+preference to the low level interfaces. This is because the code then becomes
+transparent to the algorithm used and much more flexible.
+
+Due to the link between message digests and public key algorithms the correct
+digest algorithm must be used with the correct public key type. A list of
+algorithms and associated public key algorithms appears in 
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>.
+
+=head1 BUGS
+
+Several of the functions do not return values: maybe they should. Although the
+internal digest operations will never fail some future hardware based operations
+might.
+
+=head1 SEE ALSO
+
+L<EVP_SignInit(3)|EVP_SignInit(3)>,
+L<EVP_DigestInit(3)|EVP_DigestInit(3)>, L<err(3)|err(3)>,
+L<evp(3)|evp(3)>, L<hmac(3)|hmac(3)>, L<md2(3)|md2(3)>,
+L<md5(3)|md5(3)>, L<mdc2(3)|mdc2(3)>, L<ripemd(3)|ripemd(3)>,
+L<sha(3)|sha(3)>, L<digest(1)|digest(1)>
+
+=head1 HISTORY
+
+EVP_VerifyInit(), EVP_VerifyUpdate() and EVP_VerifyFinal() are
+available in all versions of SSLeay and OpenSSL.
+
+=cut
diff --git a/lib/libssl/src/doc/crypto/des.pod b/lib/libssl/src/doc/crypto/des.pod
new file mode 100644
index 00000000000..c553210ef28
--- /dev/null
+++ b/lib/libssl/src/doc/crypto/des.pod
@@ -0,0 +1,376 @@
+=pod
+
+=head1 NAME
+
+des_random_key, des_set_key, des_key_sched, des_set_key_checked,
+des_set_key_unchecked, des_set_odd_parity, des_is_weak_key,
+des_ecb_encrypt, des_ecb2_encrypt, des_ecb3_encrypt, des_ncbc_encrypt,
+des_cfb_encrypt, des_ofb_encrypt, des_pcbc_encrypt, des_cfb64_encrypt,
+des_ofb64_encrypt, des_xcbc_encrypt, des_ede2_cbc_encrypt,
+des_ede2_cfb64_encrypt, des_ede2_ofb64_encrypt, des_ede3_cbc_encrypt,
+des_ede3_cbcm_encrypt, des_ede3_cfb64_encrypt, des_ede3_ofb64_encrypt,
+des_read_password, des_read_2passwords, des_read_pw_string,
+des_cbc_cksum, des_quad_cksum, des_string_to_key, des_string_to_2keys,
+des_fcrypt, des_crypt, des_enc_read, des_enc_write - DES encryption
+
+=head1 SYNOPSIS
+
+ #include <openssl/des.h>
+
+ void des_random_key(des_cblock *ret);
+
+ int des_set_key(const_des_cblock *key, des_key_schedule schedule);
+ int des_key_sched(const_des_cblock *key, des_key_schedule schedule);
+ int des_set_key_checked(const_des_cblock *key,
+        des_key_schedule schedule);
+ void des_set_key_unchecked(const_des_cblock *key,
+        des_key_schedule schedule);
+
+ void des_set_odd_parity(des_cblock *key);
+ int des_is_weak_key(const_des_cblock *key);
+
+ void des_ecb_encrypt(const_des_cblock *input, des_cblock *output, 
+        des_key_schedule ks, int enc);
+ void des_ecb2_encrypt(const_des_cblock *input, des_cblock *output, 
+        des_key_schedule ks1, des_key_schedule ks2, int enc);
+ void des_ecb3_encrypt(const_des_cblock *input, des_cblock *output, 
+        des_key_schedule ks1, des_key_schedule ks2, 
+        des_key_schedule ks3, int enc);
+
+ void des_ncbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, des_key_schedule schedule, des_cblock *ivec, 
+        int enc);
+ void des_cfb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, des_key_schedule schedule,
+        des_cblock *ivec, int enc);
+ void des_ofb_encrypt(const unsigned char *in, unsigned char *out,
+        int numbits, long length, des_key_schedule schedule,
+        des_cblock *ivec);
+ void des_pcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, des_key_schedule schedule, des_cblock *ivec, 
+        int enc);
+ void des_cfb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, des_key_schedule schedule, des_cblock *ivec,
+        int *num, int enc);
+ void des_ofb64_encrypt(const unsigned char *in, unsigned char *out,
+        long length, des_key_schedule schedule, des_cblock *ivec,
+        int *num);
+
+ void des_xcbc_encrypt(const unsigned char *input, unsigned char *output, 
+        long length, des_key_schedule schedule, des_cblock *ivec, 
+        const_des_cblock *inw, const_des_cblock *outw, int enc);
+
+ void des_ede2_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, des_key_schedule ks1,
+        des_key_schedule ks2, des_cblock *ivec, int enc);
+ void des_ede2_cfb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, des_key_schedule ks1,
+        des_key_schedule ks2, des_cblock *ivec, int *num, int enc);
+ void des_ede2_ofb64_encrypt(const unsigned char *in,
+        unsigned char *out, long length, des_key_schedule ks1,
+        des_key_schedule ks2, des_cblock *ivec, int *num);
+
+ void des_ede3_cbc_encrypt(const unsigned char *input,
+        unsigned char *output, long length, des_key_schedule ks1,
+        des_key_schedule ks2, des_key_schedule ks3, des_cblock *ivec,
+        int enc);
+ void des_ede3_cbcm_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, des_key_schedule ks1, des_key_schedule ks2, 
+        des_key_schedule ks3, des_cblock *ivec1, des_cblock *ivec2, 
+        int enc);
+ void des_ede3_cfb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, des_key_schedule ks1, des_key_schedule ks2,
+        des_key_schedule ks3, des_cblock *ivec, int *num, int enc);
+ void des_ede3_ofb64_encrypt(const unsigned char *in, unsigned char *out, 
+        long length, des_key_schedule ks1, 
+        des_key_schedule ks2, des_key_schedule ks3, 
+        des_cblock *ivec, int *num);
+
+ int des_read_password(des_cblock *key, const char *prompt, int verify);
+ int des_read_2passwords(des_cblock *key1, des_cblock *key2, 
+        const char *prompt, int verify);
+ int des_read_pw_string(char *buf, int length, const char *prompt,
+        int verify);
+
+ DES_LONG des_cbc_cksum(const unsigned char *input, des_cblock *output, 
+        long length, des_key_schedule schedule, 
+        const_des_cblock *ivec);
+ DES_LONG des_quad_cksum(const unsigned char *input, des_cblock output[], 
+        long length, int out_count, des_cblock *seed);
+ void des_string_to_key(const char *str, des_cblock *key);
+ void des_string_to_2keys(const char *str, des_cblock *key1,
+        des_cblock *key2);
+
+ char *des_fcrypt(const char *buf, const char *salt, char *ret);
+ char *des_crypt(const char *buf, const char *salt);
+ char *crypt(const char *buf, const char *salt);
+
+ int des_enc_read(int fd, void *buf, int len, des_key_schedule sched,
+        des_cblock *iv);
+ int des_enc_write(int fd, const void *buf, int len,
+        des_key_schedule sched, des_cblock *iv);
+
+=head1 DESCRIPTION
+
+This library contains a fast implementation of the DES encryption
+algorithm.
+
+There are two phases to the use of DES encryption.  The first is the
+generation of a I<des_key_schedule> from a key, the second is the
+actual encryption.  A DES key is of type I<des_cblock>. This type is
+consists of 8 bytes with odd parity.  The least significant bit in
+each byte is the parity bit.  The key schedule is an expanded form of
+the key; it is used to speed the encryption process.
+
+des_random_key() generates a random key.  The PRNG must be seeded
+prior to using this function (see L<rand(3)|rand(3)>; for backward
+compatibility the function des_random_seed() is available as well).
+If the PRNG could not generate a secure key, 0 is returned.  In
+earlier versions of the library, des_random_key() did not generate
+secure keys.
+
+Before a DES key can be used, it must be converted into the
+architecture dependant I<des_key_schedule> via the
+des_set_key_checked() or des_set_key_unchecked() function.
+
+des_set_key_checked() will check that the key passed is of odd parity
+and is not a week or semi-weak key.  If the parity is wrong, then -1
+is returned.  If the key is a weak key, then -2 is returned.  If an
+error is returned, the key schedule is not generated.
+
+des_set_key() (called des_key_sched() in the MIT library) works like
+des_set_key_checked() if the I<des_check_key> flag is non-zero,
+otherwise like des_set_key_unchecked().  These functions are available
+for compatibility; it is recommended to use a function that does not
+depend on a global variable.
+
+des_set_odd_parity() (called des_fixup_key_parity() in the MIT
+library) sets the parity of the passed I<key> to odd.
+
+des_is_weak_key() returns 1 is the passed key is a weak key, 0 if it
+is ok.  The probability that a randomly generated key is weak is
+1/2^52, so it is not really worth checking for them.
+
+The following routines mostly operate on an input and output stream of
+I<des_cblock>s.
+
+des_ecb_encrypt() is the basic DES encryption routine that encrypts or
+decrypts a single 8-byte I<des_cblock> in I<electronic code book>
+(ECB) mode.  It always transforms the input data, pointed to by
+I<input>, into the output data, pointed to by the I<output> argument.
+If the I<encrypt> argument is non-zero (DES_ENCRYPT), the I<input>
+(cleartext) is encrypted in to the I<output> (ciphertext) using the
+key_schedule specified by the I<schedule> argument, previously set via
+I<des_set_key>. If I<encrypt> is zero (DES_DECRYPT), the I<input> (now
+ciphertext) is decrypted into the I<output> (now cleartext).  Input
+and output may overlap.  des_ecb_encrypt() does not return a value.
+
+des_ecb3_encrypt() encrypts/decrypts the I<input> block by using
+three-key Triple-DES encryption in ECB mode.  This involves encrypting
+the input with I<ks1>, decrypting with the key schedule I<ks2>, and
+then encrypting with I<ks3>.  This routine greatly reduces the chances
+of brute force breaking of DES and has the advantage of if I<ks1>,
+I<ks2> and I<ks3> are the same, it is equivalent to just encryption
+using ECB mode and I<ks1> as the key.
+
+The macro des_ecb2_encrypt() is provided to perform two-key Triple-DES
+encryption by using I<ks1> for the final encryption.
+
+des_ncbc_encrypt() encrypts/decrypts using the I<cipher-block-chaining>
+(CBC) mode of DES.  If the I<encrypt> argument is non-zero, the
+routine cipher-block-chain encrypts the cleartext data pointed to by
+the I<input> argument into the ciphertext pointed to by the I<output>
+argument, using the key schedule provided by the I<schedule> argument,
+and initialization vector provided by the I<ivec> argument.  If the
+I<length> argument is not an integral multiple of eight bytes, the
+last block is copied to a temporary area and zero filled.  The output
+is always an integral multiple of eight bytes.
+
+des_xcbc_encrypt() is RSA's DESX mode of DES.  It uses I<inw> and
+I<outw> to 'whiten' the encryption.  I<inw> and I<outw> are secret
+(unlike the iv) and are as such, part of the key.  So the key is sort
+of 24 bytes.  This is much better than CBC DES.
+
+des_ede3_cbc_encrypt() implements outer triple CBC DES encryption with
+three keys. This means that each DES operation inside the CBC mode is
+really an C<C=E(ks3,D(ks2,E(ks1,M)))>.  This mode is used by SSL.
+
+The des_ede2_cbc_encrypt() macro implements two-key Triple-DES by
+reusing I<ks1> for the final encryption.  C<C=E(ks1,D(ks2,E(ks1,M)))>.
+This form of Triple-DES is used by the RSAREF library.
+
+des_pcbc_encrypt() encrypt/decrypts using the propagating cipher block
+chaing mode used by Kerberos v4. Its parameters are the same as
+des_ncbc_encrypt().
+
+des_cfb_encrypt() encrypt/decrypts using cipher feedback mode.  This
+method takes an array of characters as input and outputs and array of
+characters.  It does not require any padding to 8 character groups.
+Note: the I<ivec> variable is changed and the new changed value needs to
+be passed to the next call to this function.  Since this function runs
+a complete DES ECB encryption per I<numbits>, this function is only
+suggested for use when sending small numbers of characters.
+
+des_cfb64_encrypt()
+implements CFB mode of DES with 64bit feedback.  Why is this
+useful you ask?  Because this routine will allow you to encrypt an
+arbitrary number of bytes, no 8 byte padding.  Each call to this
+routine will encrypt the input bytes to output and then update ivec
+and num.  num contains 'how far' we are though ivec.  If this does
+not make much sense, read more about cfb mode of DES :-).
+
+des_ede3_cfb64_encrypt() and des_ede2_cfb64_encrypt() is the same as
+des_cfb64_encrypt() except that Triple-DES is used.
+
+des_ofb_encrypt() encrypts using output feedback mode.  This method
+takes an array of characters as input and outputs and array of
+characters.  It does not require any padding to 8 character groups.
+Note: the I<ivec> variable is changed and the new changed value needs to
+be passed to the next call to this function.  Since this function runs
+a complete DES ECB encryption per numbits, this function is only
+suggested for use when sending small numbers of characters.
+
+des_ofb64_encrypt() is the same as des_cfb64_encrypt() using Output
+Feed Back mode.
+
+des_ede3_ofb64_encrypt() and des_ede2_ofb64_encrypt() is the same as
+des_ofb64_encrypt(), using Triple-DES.
+
+The following functions are included in the DES library for
+compatibility with the MIT Kerberos library. des_read_pw_string()
+is also available under the name EVP_read_pw_string().
+
+des_read_pw_string() writes the string specified by I<prompt> to
+standarf output, turns echo off and reads in input string from the
+terminal.  The string is returned in I<buf>, which must have space for
+at least I<length> bytes.  If I<verify> is set, the user is asked for
+the password twice and unless the two copies match, an error is
+returned.  A return code of -1 indicates a system error, 1 failure due
+to use interaction, and 0 is success.
+
+des_read_password() does the same and converts the password to a DES
+key by calling des_string_to_key(); des_read_2password() operates in
+the same way as des_read_password() except that it generates two keys
+by using the des_string_to_2key() function.  des_string_to_key() is
+available for backward compatibility with the MIT library.  New
+applications should use a cryptographic hash function.  The same
+applies for des_string_to_2key().
+
+des_cbc_cksum() produces an 8 byte checksum based on the input stream
+(via CBC encryption).  The last 4 bytes of the checksum are returned
+and the complete 8 bytes are placed in I<output>. This function is
+used by Kerberos v4.  Other applications should use
+L<EVP_DigestInit(3)|EVP_DigestInit(3)> etc. instead.
+
+des_quad_cksum() is a Kerberos v4 function.  It returns a 4 byte
+checksum from the input bytes.  The algorithm can be iterated over the
+input, depending on I<out_count>, 1, 2, 3 or 4 times.  If I<output> is
+non-NULL, the 8 bytes generated by each pass are written into
+I<output>.
+
+The following are DES-based tranformations:
+
+des_fcrypt() is a fast version of the unix crypt(3) function.  This
+version takes only a small amount of space relative to other fast
+crypt() implementations.  This is different to the normal crypt in
+that the third parameter is the buffer that the return value is
+written into.  It needs to be at least 14 bytes long.  This function
+is thread safe, unlike the normal crypt.
+
+des_crypt() is a faster replacement for the normal system crypt().
+This function calls des_fcrypt() with a static array passed as the
+third parameter.  This emulates the normal non-thread safe semantics
+of crypt(3).
+
+des_enc_write() writes I<len> bytes to file descriptor I<fd> from
+buffer I<buf>. The data is encrypted via I<pcbc_encrypt> (default)
+using I<sched> for the key and I<iv> as a starting vector.  The actual
+data send down I<fd> consists of 4 bytes (in network byte order)
+containing the length of the following encrypted data.  The encrypted
+data then follows, padded with random data out to a multiple of 8
+bytes.
+
+des_enc_read() is used to read I<len> bytes from file descriptor
+I<fd> into buffer I<buf>. The data being read from I<fd> is assumed to
+have come from des_enc_write() and is decrypted using I<sched> for
+the key schedule and I<iv> for the initial vector.
+
+B<Warning:> The data format used by des_enc_write() and des_enc_read()
+has a cryptographic weakness: When asked to write more than MAXWRITE
+bytes, des_enc_write() will split the data into several chunks that
+are all encrypted using the same IV.  So don't use these functions
+unless you are sure you know what you do (in which case you might not
+want to use them anyway).  They cannot handle non-blocking sockets.
+des_enc_read() uses an internal state and thus cannot be used on
+multiple files.
+
+I<des_rw_mode> is used to specify the encryption mode to use with
+des_enc_read() and des_end_write().  If set to I<DES_PCBC_MODE> (the
+default), des_pcbc_encrypt is used.  If set to I<DES_CBC_MODE>
+des_cbc_encrypt is used.
+
+=head1 NOTES
+
+Single-key DES is insecure due to its short key size.  ECB mode is
+not suitable for most applications; see L<des_modes(7)|des_modes(7)>.
+
+The L<evp(3)|evp(3)> library provides higher-level encryption functions.
+
+=head1 BUGS
+
+des_3cbc_encrypt() is flawed and must not be used in applications.
+
+des_cbc_encrypt() does not modify B<ivec>; use des_ncbc_encrypt()
+instead.
+
+des_cfb_encrypt() and des_ofb_encrypt() operates on input of 8 bits.
+What this means is that if you set numbits to 12, and length to 2, the
+first 12 bits will come from the 1st input byte and the low half of
+the second input byte.  The second 12 bits will have the low 8 bits
+taken from the 3rd input byte and the top 4 bits taken from the 4th
+input byte.  The same holds for output.  This function has been
+implemented this way because most people will be using a multiple of 8
+and because once you get into pulling bytes input bytes apart things
+get ugly!
+
+des_read_pw_string() is the most machine/OS dependent function and
+normally generates the most problems when porting this code.
+
+=head1 CONFORMING TO
+
+ANSI X3.106
+
+The B<des> library was written to be source code compatible with
+the MIT Kerberos library.
+
+=head1 SEE ALSO
+
+crypt(3), L<des_modes(3)|des_modes(3)>, L<evp(3)|evp(3)>, L<rand(3)|rand(3)>
+
+=head1 HISTORY
+
+des_cbc_cksum(), des_cbc_encrypt(), des_ecb_encrypt(),
+des_is_weak_key(), des_key_sched(), des_pcbc_encrypt(),
+des_quad_cksum(), des_random_key(), des_read_password() and
+des_string_to_key() are available in the MIT Kerberos library;
+des_check_key_parity(), des_fixup_key_parity() and des_is_weak_key()
+are available in newer versions of that library.
+
+des_set_key_checked() and des_set_key_unchecked() were added in
+OpenSSL 0.9.5.
+
+des_generate_random_block(), des_init_random_number_generator(),
+des_new_random_key(), des_set_random_generator_seed() and
+des_set_sequence_number() and des_rand_data() are used in newer
+versions of Kerberos but are not implemented here.
+
+des_random_key() generated cryptographically weak random data in
+SSLeay and in OpenSSL prior version 0.9.5, as well as in the original
+MIT library.
+
+=head1 AUTHOR
+
+Eric Young (eay@cryptsoft.com). Modified for the OpenSSL project
+(http://www.openssl.org).
+
+=cut
diff --git a/lib/libssl/src/ms/mingw32.bat b/lib/libssl/src/ms/mingw32.bat
new file mode 100644
index 00000000000..1726c55bcda
--- /dev/null
+++ b/lib/libssl/src/ms/mingw32.bat
@@ -0,0 +1,92 @@
+@rem OpenSSL with Mingw32+GNU as

+@rem ---------------------------

+

+perl Configure Mingw32 %1 %2 %3 %4 %5 %6 %7 %8

+

+@echo off

+

+perl -e "exit 1 if '%1' eq 'no-asm'"

+if errorlevel 1 goto noasm

+

+echo Generating x86 for GNU assember

+

+echo Bignum

+cd crypto\bn\asm

+perl x86.pl gaswin > bn-win32.s

+cd ..\..\..

+

+echo DES

+cd crypto\des\asm

+perl des-586.pl gaswin > d-win32.s

+cd ..\..\..

+

+echo crypt

+cd crypto\des\asm

+perl crypt586.pl gaswin > y-win32.s

+cd ..\..\..

+

+echo Blowfish

+cd crypto\bf\asm

+perl bf-586.pl gaswin > b-win32.s

+cd ..\..\..

+

+echo CAST5

+cd crypto\cast\asm

+perl cast-586.pl gaswin > c-win32.s

+cd ..\..\..

+

+echo RC4

+cd crypto\rc4\asm

+perl rc4-586.pl gaswin > r4-win32.s

+cd ..\..\..

+

+echo MD5

+cd crypto\md5\asm

+perl md5-586.pl gaswin > m5-win32.s

+cd ..\..\..

+

+echo SHA1

+cd crypto\sha\asm

+perl sha1-586.pl gaswin > s1-win32.s

+cd ..\..\..

+

+echo RIPEMD160

+cd crypto\ripemd\asm

+perl rmd-586.pl gaswin > rm-win32.s

+cd ..\..\..

+

+echo RC5\32

+cd crypto\rc5\asm

+perl rc5-586.pl gaswin > r5-win32.s

+cd ..\..\..

+

+:noasm

+

+echo Generating makefile

+perl util\mkfiles.pl >MINFO

+perl util\mk1mf.pl gaswin Mingw32 >ms\mingw32a.mak

+perl util\mk1mf.pl gaswin Mingw32-files >ms\mingw32f.mak

+echo Generating DLL definition files

+perl util\mkdef.pl 32 libeay >ms\libeay32.def

+if errorlevel 1 goto end

+perl util\mkdef.pl 32 ssleay >ms\ssleay32.def

+if errorlevel 1 goto end

+

+rem Create files -- this can be skipped if using the GNU file utilities

+make -f ms/mingw32f.mak

+echo You can ignore the error messages above

+

+echo Building the libraries

+make -f ms/mingw32a.mak

+if errorlevel 1 goto end

+

+echo Generating the DLLs and input libraries

+dllwrap --dllname libeay32.dll --output-lib out/libeay32.a --def ms/libeay32.def out/libcrypto.a -lwsock32 -lgdi32

+if errorlevel 1 goto end

+dllwrap --dllname libssl32.dll --output-lib out/libssl32.a --def ms/ssleay32.def out/libssl.a out/libeay32.a

+if errorlevel 1 goto end

+

+echo Done compiling OpenSSL

+

+:end

+

diff --git a/lib/libssl/src/shlib/Makefile.hpux10-cc b/lib/libssl/src/shlib/Makefile.hpux10-cc
new file mode 100644
index 00000000000..4dc62ebd9eb
--- /dev/null
+++ b/lib/libssl/src/shlib/Makefile.hpux10-cc
@@ -0,0 +1,51 @@
+# Makefile.hpux-cc
+
+major=1
+
+slib=libssl
+sh_slib=$(slib).so.$(major)
+
+clib=libcrypto
+sh_clib=$(clib).so.$(major)
+
+all : $(clib).sl $(slib).sl
+
+
+$(clib)_pic.a : $(clib).a
+	echo "Copying $? to $@"
+	cp -p $? $@
+
+$(slib)_pic.a : $(slib).a
+	echo "Copying $? to $@"
+	cp -p $? $@
+
+$(sh_clib) : $(clib)_pic.a
+	echo "collecting all object files for $@"
+	find . -name \*.o -print > allobjs
+	for obj in `ar t $(clib)_pic.a`; \
+	do \
+		grep /$$obj allobjs; \
+	done >objlist
+	echo "linking $@"
+	ld -b -s -z +h $@ -o $@ `cat objlist` -lc 
+	rm allobjs objlist
+
+$(clib).sl : $(sh_clib)
+	rm -f $@
+	ln -s $? $@
+
+$(sh_slib) : $(slib)_pic.a $(clib).sl
+	echo "collecting all object files for $@"
+	find . -name \*.o -print > allobjs
+	for obj in `ar t $(slib)_pic.a`; \
+	do \
+		grep /$$obj allobjs; \
+	done >objlist
+	echo "linking $@"
+	ld -b -s -z +h $@ +b /usr/local/ssl/lib:/usr/lib -o $@ `cat objlist` \
+			-L. -lcrypto -lc
+	rm -f allobjs objlist
+        
+$(slib).sl : $(sh_slib)
+	rm -f $@
+	ln -s $? $@
diff --git a/lib/libssl/src/shlib/hpux10-cc.sh b/lib/libssl/src/shlib/hpux10-cc.sh
new file mode 100644
index 00000000000..903baaa4e7e
--- /dev/null
+++ b/lib/libssl/src/shlib/hpux10-cc.sh
@@ -0,0 +1,90 @@
+#!/usr/bin/sh
+#
+# Run this script from the OpenSSL root directory:
+# sh shlib/hpux10-cc.sh
+# 
+# HP-UX (10.20) shared library installation:
+# Compile and install OpenSSL with best possible optimization:
+# - shared libraries are compiled and installed with +O4 optimization
+# - executable(s) are compiled and installed with +O4 optimization
+# - static libraries are compiled and installed with +O3 optimization,
+#   to avoid the time consuming +O4 link-time optimization when using
+#   these libraries. (The shared libs are already optimized during build
+#   at +O4.)
+#
+# This script must be run with appropriate privileges to install into
+# /usr/local/ssl. HP-UX prevents used executables and shared libraries
+# from being deleted or overwritten. Stop all processes using already
+# installed items of OpenSSL.
+#
+# WARNING: At high optimization levels, HP's ANSI-C compiler can chew up
+#          large amounts of memory and CPU time. Make sure to have at least
+#          128MB of RAM available and that your kernel is configured to allow
+#          at least 128MB data size (maxdsiz parameter).
+#          The installation process can take several hours, even on fast
+#          machines. +O4 optimization of the libcrypto.sl shared library may
+#          take 1 hour on a C200 (200MHz PA8200 CPU), +O3 compilation of
+#          fcrypt_b.c can take 20 minutes on this machine. Stay patient.
+#
+# SITEFLAGS: site specific flags. I do use +DAportable, since I have to
+# support older PA1.1-type CPUs. Your mileage may vary.
+# +w1 enables enhanced warnings, useful when working with snaphots.
+#
+SITEFLAGS="+DAportable +w1"
+#
+# Set the default additions to build with HP-UX.
+# -D_REENTRANT must/should be defined on HP-UX manually, since we do call
+# Configure directly.
+# +Oall increases the optimization done.
+#
+MYFLAGS="-D_REENTRANT +Oall $SITEFLAGS"
+
+# Configure for pic and build the static pic libraries
+perl5 Configure hpux-parisc-cc-o4 +z ${MYFLAGS}
+make clean
+make DIRS="crypto ssl"
+# Rename the static pic libs and build dynamic libraries from them
+# Be prepared to see a lot of warnings about shared libraries being built
+# with optimizations higher than +O2. When using these libraries, it is
+# not possible to replace internal library functions with functions from
+# the program to be linked.
+#
+make -f shlib/Makefile.hpux10-cc
+
+# Copy the libraries to /usr/local/ssl/lib (they have to be in their
+# final location when linking applications).
+# If the directories are still there, no problem.
+mkdir /usr/local
+mkdir /usr/local/ssl
+mkdir /usr/local/ssl/lib
+chmod 444 lib*_pic.a
+chmod 555 lib*.so.1
+cp -p lib*_pic.a lib*.so.1 /usr/local/ssl/lib
+(cd /usr/local/ssl/lib ; ln -sf libcrypto.so.1 libcrypto.sl ; ln -sf libssl.so.1 libssl.sl)
+
+# Reconfigure without pic to compile the executables. Unfortunately, while
+# performing this task we have to recompile the library components, even
+# though we use the already installed shared libs anyway.
+#
+perl5 Configure hpux-parisc-cc-o4 ${MYFLAGS}
+
+make clean
+
+# Hack the Makefiles to pick up the dynamic libraries during linking
+#
+sed 's/^PEX_LIBS=.*$/PEX_LIBS=-L\/usr\/local\/ssl\/lib -Wl,+b,\/usr\/local\/ssl\/lib:\/usr\/lib/' Makefile.ssl >xxx; mv xxx Makefile.ssl
+sed 's/-L\.\.//' apps/Makefile.ssl >xxx; mv xxx apps/Makefile.ssl
+sed 's/-L\.\.//' test/Makefile.ssl >xxx; mv xxx test/Makefile.ssl
+# Build the static libs and the executables in one make.
+make
+# Install everything
+make install
+
+# Finally build the static libs with +O3. This time we only need the libraries,
+# once created, they are simply copied into place.
+#
+perl5 Configure hpux-parisc-cc ${MYFLAGS}
+make clean
+make DIRS="crypto ssl"
+chmod 644 libcrypto.a libssl.a
+cp -p libcrypto.a libssl.a /usr/local/ssl/lib