diff options
author | Bob Beck <beck@cvs.openbsd.org> | 2000-04-15 06:18:50 +0000 |
---|---|---|
committer | Bob Beck <beck@cvs.openbsd.org> | 2000-04-15 06:18:50 +0000 |
commit | a9ff8ce9034eced578b0cca36eee3367841b4dd4 (patch) | |
tree | 6ef6f6b4874fbfc51f5630dd0dfed2be032d031c | |
parent | eca4b7c7cae34bc02a5b3f67795bcffa97e9aae5 (diff) |
import openssl-0.9.7-beta1
-rw-r--r-- | lib/libssl/src/MacOS/Randomizer.cpp | 476 | ||||
-rw-r--r-- | lib/libssl/src/MacOS/Randomizer.h | 43 | ||||
-rw-r--r-- | lib/libssl/src/apps/rand.c | 140 | ||||
-rw-r--r-- | lib/libssl/src/apps/winrand.c | 149 | ||||
-rw-r--r-- | lib/libssl/src/crypto/des/des.pod | 217 | ||||
-rw-r--r-- | lib/libssl/src/doc/apps/rand.pod | 50 | ||||
-rw-r--r-- | lib/libssl/src/doc/crypto/EVP_OpenInit.pod | 51 | ||||
-rw-r--r-- | lib/libssl/src/doc/crypto/EVP_SealInit.pod | 70 | ||||
-rw-r--r-- | lib/libssl/src/doc/crypto/EVP_SignInit.pod | 85 | ||||
-rw-r--r-- | lib/libssl/src/doc/crypto/EVP_VerifyInit.pod | 71 | ||||
-rw-r--r-- | lib/libssl/src/doc/crypto/des.pod | 376 | ||||
-rw-r--r-- | lib/libssl/src/ms/mingw32.bat | 92 | ||||
-rw-r--r-- | lib/libssl/src/shlib/Makefile.hpux10-cc | 51 | ||||
-rw-r--r-- | lib/libssl/src/shlib/hpux10-cc.sh | 90 |
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 |